Authenticated RCE in Gogs Hits CVSS 9.4 — and There's No CVE Yet

A critical flaw in the self-hosted Git service lets any logged-in account execute arbitrary code on the server. The auth bar is low. The blast radius isn't.

ThreatVectr Newsdesk· 2 min read
Authenticated RCE in Gogs Hits CVSS 9.4 — and There's No CVE Yet
Share

Gogs, the lightweight self-hosted Git service that a lot of small teams quietly run instead of GitLab, has a critical remote code execution bug. Rapid7 rates it 9.4 on CVSS v3. There is no CVE identifier assigned at time of writing, which is its own minor scandal.

The condition for exploitation is almost embarrassingly mild: be authenticated.

That's it. Any user account on the instance — and on a lot of Gogs deployments, registration is open by default or only loosely gated — can reach the vulnerable code path and run commands as the Gogs service user. From there, the usual unpleasantness applies: source code exfiltration, secret theft from .git/config and CI tokens, lateral movement into whatever runner or webhook target the server can reach, and persistence via planted hooks.

This is an authorization-shaped problem more than an authentication one. The system correctly verifies who you are. It then fails to restrict what you can do with that identity. RFC 6749 and friends have spent a decade and a half drilling that distinction into OAuth implementations; self-hosted forge software apparently still needs the lecture.

MFA would not have helped here. The attacker is already past the login wall by design.

What would help, in rough order: shut down open registration on internet-facing instances, audit your user table for accounts you don't recognize, and put the Gogs HTTP interface behind an authenticating reverse proxy or SSO gateway that enforces an allowlist. If you can stomach the migration, this is also a reasonable moment to look at Gitea or a managed alternative. Gogs development has been intermittent, and a critical-severity issue floating without a CVE assignment for triage is not a great signal about the disclosure pipeline.

For detection, focus on the post-exploit telemetry rather than the request signature. Look for the Gogs process spawning unexpected children — shells, curl, wget, package managers — and for outbound connections from the host that don't match git or webhook patterns. Repository hook files modified outside of normal admin activity are also worth alerting on.

Full technical details from Rapid7's advisory are the authoritative source for IOCs and the affected version range; check their disclosure page directly rather than trusting secondhand version claims. Until a patched release lands and a CVE is minted, treat every authenticated Gogs user as a potential RCE primitive.

Assume breach if your instance has had open registration and any internet exposure in the last several months. Rotate the deploy keys and CI tokens it held. The auth was working fine. The authz was the part that wasn't.

© 2026 Threat Vectr