Attack Chain

1. Initial Access: An attacker obtains an authenticated account on the Gogs instance, either through open registration or by compromising existing credentials.
2. Repository Setup: The attacker creates their own repository (or gains write access to one where "Rebase before merging" is enabled) and then enables the "Rebase before merging" option in the repository settings.
3. Malicious Branch Creation: The attacker creates a new branch in their repository with a specially crafted name, such as --exec=touch${IFS}/tmp/rce_proof, which abuses the git rebase --exec argument.
4. Pull Request Submission: The attacker creates a pull request (PR) targeting their own repository's base branch from their malicious branch.
5. Merge Operation Initiation: The attacker initiates the "Rebase before merging" operation for the malicious pull request through the Gogs web interface.
6. Remote Code Execution: During the rebase process, Gogs executes the git rebase command with the attacker's crafted branch name. Git interprets --exec=... as an argument, causing the embedded command (touch /tmp/rce_proof or a base64-encoded payload) to execute on the Gogs server as the Gogs process user (typically git).
7. Server Compromise/Impact: Despite a subsequent git checkout failure leading to an HTTP 500 error in Gogs, the RCE has already successfully completed, giving the attacker full control over the server.

Impact

Successful exploitation of this vulnerability leads to severe consequences, including full server compromise. An attacker gains arbitrary command execution as the Gogs process user, which can lead to cross-tenant data breaches, allowing them to read all repositories on the instance, including other users' private code. This can also facilitate credential theft, providing access to password hashes, API tokens, SSH keys, and 2FA secrets for every user. Furthermore, the attacker can use the compromised server for lateral movement into other internal systems and can conduct supply chain attacks by silently modifying any hosted repository's code. This critical vulnerability affects all Gogs installations regardless of the operating system (Linux, macOS, Windows) or deployment method (binary, Docker, source), posing a significant threat to the integrity and confidentiality of code hosted on Gogs instances.

Recommendation

• Patch Immediately: Upgrade Gogs to a version that contains the fix for GHSA-qf6p-p7ww-cwr9. As of the advisory, a patch was not explicitly mentioned, but the issue is tied to b53d3162 commit. Monitor Gogs releases for official patch availability.
• Implement Process Monitoring: Deploy the Sigma rule in this brief to your SIEM to detect git rebase commands containing the --exec= argument. Ensure your endpoint detection and response (EDR) or Sysmon configuration captures process creation events, including command-line arguments and parent-child relationships, on Gogs server hosts.
• Review Gogs Configuration: If patching is not immediately possible, consider disabling the "Rebase before merging" option globally or restricting user permissions to prevent its enablement on repositories until a patch is applied.
• Monitor Gogs Application Logs: Regularly review Gogs application logs for error messages indicating git checkout '--exec=<...>': exit status 128 - error: unknown option \exec=<...>''`, which signifies a post-RCE attempt to check out the malicious branch.