A critical access control vulnerability (CVE-2026-27771) has been disclosed in Gitea’s built-in container registry, allowing any unauthenticated remote attacker to pull container images marked as private, without credentials, tokens, or prior access of any kind. Due to the potential for full exposure of application source code, embedded secrets, and production infrastructure details, immediate patching is required.

Technical Overview

The issue originates from Gitea’s container registry access control model, where the “private” designation on container repositories failed to enforce the expected authentication requirements. When a repository was marked private, the container registry endpoint still served image layers and manifests to anonymous requests. By sending standard Docker/OCI pull requests to the registry API, attackers could retrieve complete private container images, potentially exposing application code, API keys, database credentials, and internal infrastructure configurations embedded within those images. No authentication was required to exploit this issue.

Affected Products and Exposure

The following components are affected: Gitea’s built-in container (OCI) registry in all versions prior to 1.26.2. Forgejo, the prominent community fork of Gitea that shares the same container registry implementation, has been independently confirmed as vulnerable through testing by the discovering researchers. Other Gitea forks should be independently verified.

These components are widely deployed across self-hosted Git and CI/CD environments. An estimated 31,750 internet-facing Gitea instances were identified as likely affected, spanning 30+ countries with the highest concentrations in China, the United States, and Germany. Approximately 52% of affected instances run on major cloud platforms. Impacted sectors include healthcare providers, aerospace manufacturers, retail infrastructure operators, internet service providers, and enterprise software development teams.

Users should upgrade to Gitea v1.26.2 immediately. Forgejo users should monitor their project’s release channels for a corresponding patch. Organizations unable to upgrade immediately should set [service].REQUIRE_SIGNIN_VIEW=true in their Gitea configuration as a temporary workaround, though this prevents all anonymous access to the instance including intentionally public repositories and container images.

Current Threat Status

The vulnerability was discovered by NoScope’s autonomous penetration testing agent in April 2026 and responsibly disclosed to the Gitea maintainer team, who assigned CVE-2026-27771 and credited NoScope in the v1.26.2 release notes. The flaw had persisted undetected for approximately four years since the container registry feature was introduced. At the time of writing, no public proof-of-concept exploit has been released, and there are no confirmed reports of active exploitation in the wild. Regardless, the severity and ease of exploitation make this vulnerability high risk, especially for internet-facing deployments where private container images may contain sensitive intellectual property, credentials, or infrastructure details.

Potential Impact

Successful exploitation could allow attackers to exfiltrate proprietary application source code and business logic, harvest embedded secrets such as API keys, database passwords, and cloud provider credentials, and map internal infrastructure through exposed configuration files and deployment manifests, leading to further compromise, lateral movement, data breaches, or full infrastructure takeover.

How can Orca help?

Orca enables customers to quickly identify assets running vulnerable Gitea versions, understand their exposure in context, including internet accessibility, runtime reachability, and asset criticality, and prioritize remediation based on real risk rather than CVSS alone. Orca’s platform highlights affected assets directly in the inventory view, helping security teams focus on the most critical remediation paths first. Organizations using Gitea’s container registry for CI/CD pipelines should audit whether any private images were accessed by unauthorized parties and rotate any credentials that may have been embedded in exposed images.