Gitea Bug Exposed Private Container Images for Four Years

CVE-2026-27771: A critical flaw in Gitea’s container registry left approximately 31,750 instances vulnerable for nearly four years. Discovered by an AI pentest…

On May 27, 2026, NoScope security research disclosed CVE-2026-27771, a vulnerability in Gitea’s integrated container registry that rendered the "private" flag ineffective. For approximately four years, the flaw allowed anyone to download private container images without an account, password, or authorization. Discovered in April 2026 by an autonomous AI-based penetration testing agent, the leak highlights a growing paradox: organizations choose self-hosted DevOps infrastructure for control, yet these systems often accumulate silent bugs that escape internal audits.

Gitea is a lightweight, open-source self-hosted Git service widely adopted by teams seeking to keep code and artifacts off public clouds. Its integrated OCI registry—available since version 1.13.0—hosts Docker and OCI images. While a patch is available in version 1.26.2, independent verification by NoScope and Orca Security confirms that the Forgejo fork is also vulnerable.

Key Takeaways

CVE-2026-27771: The "private" flag on container repositories failed to trigger authentication checks at the registry endpoint, allowing full anonymous pulls.
Approximately 34,000 Gitea instances are exposed to the internet, with 31,750 (93%) vulnerable across more than 30 countries, including high concentrations in China, the United States, Germany, France, and the UK.
The bug persisted for roughly four years following the registry feature's introduction; there is no confirmed exploitation at the time of disclosure.
NoScope’s AI agent discovered the flaw in April 2026; the patched version is 1.26.2 (a temporary workaround requires setting REQUIRE_SIGNIN_VIEW=true).

The Mechanism: When "Private" Doesn't Mean Protected

Gitea’s OCI registry exposes standard HTTP endpoints on the /v2/ path for manifests and blobs—the protocol used by Docker and compatible clients for pulls and pushes. Technical documentation from Rescana and research from Orca Security reveal that repositories flagged as "private" in the Gitea web interface did not propagate that restriction to the registry layer. The API responded to anonymous GET requests by serving complete layers and manifests, effectively bypassing all identity verification.

The vulnerability exists within the software's access control logic: the authentication middleware applied to the graphical interface was never replicated at the registry endpoint. The result is a dangerous asymmetry—administrators saw a "private" status on their dashboard and assumed protection, while the internet-facing registry treated every request as public.

The Scope: Production-Grade Exposure

Data collected by NoScope via Shodan identifies approximately 34,000 internet-reachable Gitea instances. Of these, 31,750 (93%) ran versions between 1.13.0 and 1.26.1, making them vulnerable. According to Orca Security, roughly 52% of these instances are hosted on major cloud platforms. SecurityWeek reports that approximately 4,000 systems are production configurations on cloud or VPS environments, rather than isolated developer machines.

Affected sectors include healthcare, aerospace, retail, ISPs, and enterprise software development. These are infrastructures hosting CI/CD pipelines and deployment configurations.

"The data is unequivocal. These are not hobbyist machines. These are organizations that made a deliberate decision to self-host their development infrastructure, running it on production compute for real workloads." — NoScope, quoted by SecurityWeek

Severity Rating Discrepancies

The CVSS score for CVE-2026-27771 varies across sources. The Hacker News reports a score of 8.2, while TechJack Solutions indicates 9.1. The classification CWE-306 (Missing Authentication for Critical Function) reported by TechJack is consistent with the nature of the bug.

Rescana’s 1.13.0–1.26.1 range is the most detailed available. All sources agree that version 1.26.2 is the required patch.

Source Limitations

The technical reconstruction relies on vendor research and coordinated disclosure.

Immediate Mitigation Steps

Security researchers emphasize three immediate priorities for Gitea operators.

First, update to Gitea 1.26.2. The official release notes confirm the fix; users of the Forgejo fork should independently verify the availability of a corresponding patch.

Second, if an immediate update is not possible, set REQUIRE_SIGNIN_VIEW=true in the [service] section of the Gitea configuration. This temporary workaround forces authentication for all requests, mitigating the registry bypass—though it also prevents anonymous users from browsing public content.

Third, administrators should review registry access logs to identify anonymous pulls from private repositories. While no confirmed exploitation was reported prior to disclosure, the nature of the bug—where unauthorized access is indistinguishable from legitimate requests—makes log forensic analysis essential to rule out past data exfiltration.

ANALYSIS — The Self-Hosted Trust Paradox

The CVE-2026-27771 case illustrates a structural tension in self-managed DevOps environments. Organizations choose Gitea to maintain sovereignty over their code and artifacts, avoiding reliance on public clouds. While this is a sound policy for data control, it creates a less-scrutinized attack surface: bugs in integrated components rarely receive the same level of external auditing as those in mainstream cloud services.

The container registry is a secondary component compared to the core Git functionality, yet it shares the same network and storage access levels. Internal artifacts, considered trusted by the organization, were accessible to the outside world without triggering any monitoring alerts. Because the lack of authentication was a software flaw, the risk was difficult for administrators to anticipate.

For the 30,000+ affected instances, the challenge now extends beyond patching. Operators must determine, through rigorous log analysis, if anyone exploited the access that this bug left wide open for four years.

Information has been verified against cited sources and is current as of the time of publication.