Gogs 0.14.3 Patches a Critical RCE Path in Self-Hosted Git Servers

A source-control server is not just a collaboration tool. For many teams it holds private repositories, deployment keys, commit history, release automation, and the trust path into production. That is why the new Gogs patch deserves fast attention from anyone running the self-hosted Git service on the public internet.

What changed in Gogs 0.14.3

Gogs released version 0.14.3 on June 7, 2026, and the release notes include a security fix for argument injection in pull-request rebase merging. Gogs 0.14.3 release notes The associated pull request is titled “security: fix argument injection in pull request merge (rebase)” and was merged on June 6. Gogs pull request #8301

Rapid7, which discovered and reported the issue, describes the bug as a critical argument-injection vulnerability in Gogs that lets an authenticated user reach remote code execution by creating a pull request with a malicious branch name that injects the --exec flag into git rebase during the “Rebase before merging” operation. Rapid7 vulnerability analysis

Why authenticated does not mean low risk

The important operational detail is that the attacker does not need admin privileges. Rapid7 says the exploit can be operated entirely from the attacker’s own account, and default Gogs settings ship with open registration enabled and no repository-creation limit. Rapid7 exploitation notes

In a default-exposed deployment, that means “authenticated” can collapse into “anyone who can register.” Rapid7 notes that DISABLE_REGISTRATION = false and MAX_CREATION_LIMIT = -1 allow an unauthenticated visitor to create an account and repository, then enable rebase merging in that repository’s settings. Rapid7 default-configuration analysis

The blast radius is source-code trust

Rapid7 says successful exploitation results in arbitrary command execution as the Gogs server process user, with possible access to private repositories, stored credentials, API tokens, SSH keys, two-factor secrets, other network-accessible systems, and hosted source code. Rapid7 impact section

BleepingComputer reported the same patch window and highlighted that Internet-facing Gogs instances are common because the project is used as a self-hosted alternative to GitHub Enterprise or GitLab. BleepingComputer coverage

The immediate response path

The clean fix is to upgrade to Gogs 0.14.3. Rapid7 explicitly recommends that all Gogs users upgrade immediately, and the upstream release now includes the security fix. Rapid7 remediation guidance Gogs 0.14.3 release notes

If you cannot patch immediately

Rapid7’s temporary mitigations are to restrict registration with DISABLE_REGISTRATION = true, restrict repository creation with MAX_CREATION_LIMIT = 0, and audit “Rebase before merging” settings. Rapid7 warns, however, that auditing rebase settings is not a complete defense when a malicious user owns or administers a repository because they can re-enable the setting. Rapid7 mitigation section

What to check after upgrading

Teams should not stop at package replacement. Rapid7 says tokens created through the exploit path can persist until manually revoked. In Gogs itself, defenders should review each user’s Applications settings page for unexpected tokens rather than relying on the patch to remove them automatically. Rapid7 indicators and remediation

A practical review should include newly created users, unexpected repositories, repository settings where rebase merging was enabled, unusual branch names or pull requests, application tokens, SSH keys, service credentials available to the Gogs process, and outbound connections from the host during the exposure window.

The larger lesson for self-hosted developer infrastructure

The Gogs issue is another reminder that a self-hosted developer tool can become a production security boundary even when it looks like a small internal service. If registration is public, repository creation is open, and the service can reach internal networks or deployment credentials, an application-level bug can turn into a broader source-code and secrets incident.

For small teams, the durable control set is simple: keep developer infrastructure patched, disable open registration unless it is truly needed, limit who can create repositories, isolate Git hosts from production secrets, and monitor source-control servers as seriously as application servers.