What Happened
For close to four years, every self-hosted Gitea instance with a private container registry had a gaping hole in its access controls: any person on the internet could pull private container images without an account, a password, or any credentials at all. The flaw, tracked as CVE-2026-27771, was disclosed on May 27, 2026, by NoScope, which estimates it affected more than 30,000 deployments across over 30 countries. The Hacker News confirmed the disclosure the same day, noting the vulnerability went undetected for close to four years.
A separate but related vulnerability, CVE-2026-20912 (CVSS 9.1), was disclosed earlier in January 2026. That flaw allowed authenticated users to link attachments from private repositories to public releases, effectively smuggling sensitive files past access controls. CVE Feed scored it 9.1 (CRITICAL). Both were fixed — CVE-2026-20912 in Gitea 1.25.4, CVE-2026-27771 in 1.26.2 — but the window of exposure stretches back years for most instances.
Technical Analysis
The root cause of CVE-2026-27771 is straightforward: when the Gitea container registry was configured to mark a repository as "private," the access control check was never actually enforced against unauthenticated requests. The private designation on a container repository did not deliver the protection operators reasonably expected. An unauthenticated HTTP request to pull an image succeeded exactly as if the repository were public.
This was not a misconfiguration. NoScope reproduced the bug on a default Gitea installation with a typical configuration. There is no evidence of a config toggle that was overlooked. The permission model in the container registry module simply failed to gate image pulls behind authentication.
CVE-2026-20912 is a different class of flaw: Gitea did not validate repository ownership when linking attachments to releases. An attacker with a low-privileged account could link a file uploaded to a private repository into a release on a different, public repository, making the attachment downloadable by anyone. The fix in 1.25.4 added strict ownership checks for release asset linking.
Who's Affected
NoScope's扫描 found the highest concentration of exposed instances in China, the United States, Germany, France, and the United Kingdom. Affected organizations included healthcare providers, aerospace manufacturers, retail infrastructure companies, and internet service providers. Any sector running Gitea with its built-in container registry and marking images as private was potentially exposed.
The impact of a leaked container image extends far beyond source code. A container image is a complete snapshot of a production environment: application code, dependencies, configuration files, and — all too often — hard-coded database credentials, API keys, internal service endpoints, TLS certificates, and environment variables pointing at production infrastructure. In many organizations, the image is effectively a blueprint of how production is wired together.
Forks of Gitea are also at risk: Forgejo has been confirmed vulnerable. Operators of any Gitea derivative should verify with their respective maintainers whether a patch has been backported.
How to Protect Yourself
1. Update Gitea to version 1.26.2 immediately — this patches CVE-2026-27771. If you also need the CVE-2026-20912 fix, ensure you are on at least 1.25.4 (1.26.2 includes both).
2. If you can't patch right now, apply the workaround: set [service].REQUIRE_SIGNIN_VIEW=true in your Gitea configuration file. This forces authentication for all registry access. Note: this is not suitable if you intentionally expose some container images publicly, as it will block all unauthenticated pulls.
3. Audit your container images for embedded secrets. Assume any image hosted on Gitea prior to patching may have been accessed. Rotate database credentials, API keys, TLS certificates, and any other secrets that were baked into images.
4. Scan your container registry pull logs. Look for unexpected anonymous pulls of private images dating back months or years. This is the only way to determine if the flaw was actively exploited before disclosure.
5. Review your secrets management pipeline. No secret should live inside a container image in the first place. Use runtime secret injection (Kubernetes secrets, HashiCorp Vault, cloud-native secret managers) rather than baking credentials into images at build time.
The Sable Angle
This is exactly the class of vulnerability that Sable's offensive team finds during infrastructure assessments — not through automated scanning alone, but by systematically exercising the access model from every angle the surface supports. The Gitea container registry flaw lived in a feature that "behaved exactly as documented" and drew no attention on a casual review. It took a methodology that tests assumptions, not just endpoints.
We have tracked similar registry and supply-chain exposures in our research on multi-ecosystem supply chain attacks and self-propagating npm worms. The pattern is consistent: the weakest link is rarely the encryption or the firewall. It is the access control that everyone assumed was working.
If your team runs Gitea, Forgejo, or any self-hosted container registry, book a pentest and let us find the gaps before someone else does.