SURIQ
The word "authenticated" is carrying a lot of weight in this advisory, and on a default Gogs install it carries almost none. Gogs, the lightweight self-hosted git service written in Go, ships with open registration switched on, so on a typical internet-facing box "a logged-in user" means anyone who found the sign-up page. That is the context for CVE-2026-52801, a flaw fixed in version 0.14.3 that lets one of those accounts pull repositories off the server's own filesystem and poke at systems the server can reach.
It rates 8.1 on the CVSS scale, high but not critical, and it is not known to be exploited yet. Do not let the score talk you out of patching. Gogs has a track record of being hunted: an unrelated remote code execution bug, CVE-2025-8110, landed on CISA's Known Exploited Vulnerabilities list in January 2026 after attackers picked it up in the wild, as runZero documented. Attackers who already scan for Gogs will find this one too.
What actually broke in Gogs?
Gogs gives users two ways to bring an external repository in: the New Migration page and the Mirror Settings on a repository you already own. New Migration is the careful one. It checks the address you hand it and refuses to import a repository that lives on the server's local disk, which is exactly the kind of request that should never come from an ordinary user.
Mirror Settings skipped that check. The function that saves a mirror's address, named SaveAddress, never ran the validation its sibling did, so a local filesystem path that New Migration would reject sails through the mirror path instead. The advisory classifies it as CWE-20, improper input validation, and a proof of concept with screenshots is published on the GitHub advisory; the same details are mirrored on CIRCL's vulnerability lookup. We are not reprinting the steps here.
This is a pattern worth naming. When one feature validates input and a second feature that does the same job does not, the guard is only as good as the path nobody forgot. Gogs hardened New Migration and left an equivalent door open next to it. We have written before about how a single overlooked path turns an ordinary install into a file-read primitive, in the Budibase symlink case.
Why "authenticated" is a low bar here
The CVSS vector lists privileges-required as low, not none, which sounds reassuring until you remember the default configuration. Gogs sets DISABLE_REGISTRATION to false out of the box, so a fresh instance accepts self-service account creation from anyone. On an internet-facing Gogs server that has not changed that default, the gap between unauthenticated and authenticated is one registration form.
That is the difference between a bug a malicious insider could abuse and a bug a stranger can. If you run Gogs and have never touched the registration setting, treat the privilege requirement as cosmetic and prioritize accordingly. The same default-on-and-forgotten dynamic is what made the Central Dogma default-secret issue so reachable.
What an attacker gets: local repositories and blind requests
The CVSS vector ends in confidentiality high and availability high. The confidentiality half is the obvious prize. On a multi-tenant Gogs host, repositories belonging to other users and teams sit on the same disk under the git account. Importing a local repository as a mirror is a way to read content the account was never granted, which is a direct private-source-code exposure on any shared instance.
The advisory also flags a blind server-side request forgery angle: a mirror address does not have to point at the local disk, it can point at an internal hostname or address the Gogs process can reach but you cannot from outside. That turns a low-privilege account into a probe inside your network, which is the more interesting risk for anyone who placed Gogs behind a perimeter and assumed the perimeter was the boundary. We covered the same class of internal-reach problem in the Squid proxy disclosure.
How to detect attempts in your logs
You do not need the patch to start looking. A mirror whose remote address is a local filesystem path, a file:// scheme, or an internal IP or hostname is the signal. Walk your existing repositories and list every mirror's configured address; any local or internal target on a user-owned repository deserves a question. Going forward, alert on mirror creation or mirror-address changes where the destination is not an expected external git host. Gogs logs repository operations, and a mirror sync against a local path is anomalous enough to flag cheaply.
What to do about it now
Patch first, then close the door behind it.
- Upgrade to Gogs 0.14.3. This is the fixed release and the only step that removes the underlying gap.
- Disable open registration. Set
DISABLE_REGISTRATIONto true unless you have a deliberate reason to accept public sign-ups. This alone turns a stranger's bug back into an insider's bug. - Audit existing mirrors for local or internal addresses, and review accounts created recently on an instance that allowed open sign-up.
- Constrain the git host's outbound reach. Egress filtering on the Gogs server limits the blind request forgery angle to whatever the box legitimately needs to talk to.
None of this is exotic. Update the binary, flip one config default that should arguably never have shipped as it did, and check what your existing mirrors actually point at. The teams that get burned by this will be the ones running an old Gogs on the open internet with sign-ups on, which is a description of more self-hosted instances than anyone would like.