Gogs built-in SSH server argument injection RCE

This repository is a small standalone Python exploit PoC consisting of one executable script (CVE-2025-81110.py), a README, and a license. The script uses the requests library plus local git subprocess calls to exploit a Gogs content-update symlink handling flaw. The workflow is: authenticate with valid credentials, create an API token, create an empty repository, initialize a temporary local Git repo, push a symlink named evil_link that points to the server-side pre-receive hook path, query the repository contents API to recover the symlink SHA, then use the PutContents API to overwrite the symlink target with a base64-encoded shell script. A final Git push triggers the modified hook and executes the payload on the server. The exploit has two built-in capabilities: (1) 'suid' mode copies /bin/bash to /tmp/rootbash and sets mode 4755 for local privilege escalation, and (2) 'rev' mode writes a bash reverse shell that connects back to an attacker-supplied host and port. The exploit is operational rather than a simple detector because it performs the full attack chain and includes working payloads, though payload customization is limited to the reverse-shell callback parameters. Notable fingerprintable targets include multiple Gogs API endpoints under /api/v1/, the Git remote path for the created repository, the internal hook path /root/gogs-repositories/<user>/<repo>.git/hooks/pre-receive, and the payload artifact /tmp/rootbash. The README states the target is Gogs prior to 0.13.0 and describes the issue as improper symbolic link handling in the PutContents API. There is a naming inconsistency: the script banner references CVE-2024-39930 while the repository and filename reference CVE-2025-81110, but the code clearly implements an authenticated Gogs symlink-to-hook overwrite leading to server-side command execution.

This repository contains a working exploit for CVE-2024-39930, a critical remote code execution vulnerability in Gogs (<= 0.13.0). The exploit is implemented in Python (exploit.py) and leverages both the Gogs HTTP API and SSH access to achieve arbitrary command execution on the target server. The attack chain involves authenticating to the Gogs API with valid user credentials, creating an API token, generating a temporary repository, clearing and uploading a malicious SSH key, and finally connecting via SSH to inject and execute arbitrary shell commands using argument injection. The exploit requires the attacker to have valid credentials and the ability to upload SSH keys. The code is operational and automates the full exploitation process, including API interaction and SSH command execution. The README.md provides a brief description of the vulnerability. No hardcoded endpoints are present; the target is specified at runtime. The main entry point is exploit.py, which is well-structured and modular, with clear separation of API interaction and SSH exploitation logic.

This repository provides a working exploit for CVE-2024-39930, a remote command execution (RCE) vulnerability in Gogs (<=0.13.0) via its SSH server. The repository contains three files: a README.md describing the exploit, 'exploit.py' (the main exploit script), and 'gogs_install.sh' (a helper script to set up a vulnerable Gogs instance). The exploit works by leveraging the Gogs API to authenticate as a user, create a repository, and add an attacker-controlled SSH key. It then connects to the Gogs SSH server using the provided private key and abuses argument injection to execute arbitrary shell commands on the server. The exploit requires valid Gogs credentials and access to the SSH server (default port 2222 as per the install script, but configurable). The 'exploit.py' script is written in Python and automates the entire attack chain: API token acquisition, repository creation, SSH key management, and command execution via SSH. The payload is any shell command supplied by the attacker. The 'gogs_install.sh' script sets up a Gogs instance with PostgreSQL and configures it to run the vulnerable version with SSH enabled for testing purposes. Key endpoints include the Gogs web API (e.g., http://gogs.local:3000/api/v1), the SSH server (default localhost:2222), and several file paths used in the installation and configuration process. The exploit is operational and demonstrates full RCE capability against vulnerable Gogs instances.