What are CVE-2026-20896 and CVE-2026-27771?
CVE-2026-20896 is a default-configuration flaw in Gitea’s official Docker images. The images shipped with REVERSE_PROXY_TRUSTED_PROXIES set to *, so once an administrator enabled reverse-proxy authentication, Gitea trusted the X-WEBAUTH-USER header from any source IP address, not just the intended proxy. The vulnerability carries a CVSS v3.1 base score of 9.8 (Critical). Exploitation is pre-authentication: an attacker who can reach the container’s HTTP port directly can impersonate any user whose login name is known or guessable, including default admin accounts.
CVE-2026-27771 is a separate access control failure in Gitea’s built-in container (OCI) registry. Private container repositories were only private in the UI. At the protocol layer, endpoints such as /v2/<name>/manifests/<ref> and /v2/<name>/blobs/<digest> served image manifests and layers to anonymous, unauthenticated requests regardless of the repository’s visibility setting. The vulnerability carries a CVSS v3.1 base score of 8.2 (High). Exploitation is also pre-authentication, using standard Docker or OCI pull tooling against the registry API.
The two flaws are unrelated in mechanism but share a root cause pattern: an authentication boundary that existed on paper but was not enforced at the layer attackers actually reach. CVE-2026-20896 has already seen in-the-wild probing within two weeks of disclosure. CVE-2026-27771 has a public proof-of-concept exploit, though no confirmed active exploitation has been reported.
What assets are affected by CVE-2026-20896 and CVE-2026-27771?
Both vulnerabilities sit in Gitea, a self-hosted, open-source Git service widely used by development teams, smaller organizations, and academic environments that run their own source control rather than relying on a hosted provider. CVE-2026-20896 affects any Gitea Docker deployment running reverse-proxy authentication on an unpatched image. CVE-2026-27771 affects any Gitea instance, containerized or not, that has the built-in container registry feature enabled, in versions prior to 1.26.2.
In practice, an affected asset is a self-hosted Git server exposed directly to the internet, often on a development or staging host that was never intended to carry production traffic but ended up doing so anyway. Forgejo, the prominent community fork of Gitea, shares the same container registry implementation and has been independently confirmed as affected by CVE-2026-27771. Other forks that inherited the same codebase should be treated as affected until their maintainers confirm otherwise.
These deployments tend to be overlooked precisely because they are self-hosted. Unlike a managed SaaS Git provider, a self-hosted Gitea instance has no vendor patch cadence pushing updates automatically, and its exposure often outlives the project or team that originally stood it up.
What does our data show about exposure patterns?

Exposure in this set is led by Health Care at 33.3% of observed assets, with Consumer Discretionary contributing 20.0% and Information Technology adding 13.3%.
Health care’s concentration is consistent with how the sector builds software. Clinical and administrative systems are frequently developed by distributed teams and third-party integrators who stand up their own Git infrastructure rather than routing through a centrally governed platform, and mergers or acquisitions in the sector routinely fold in previously independent development environments without a corresponding audit of what they expose.
The spread across Consumer Discretionary and Information Technology, alongside a large Others bucket, points to a risk driver that is not sector-specific: self-hosted developer tooling gets provisioned quickly, rarely gets decommissioned on schedule, and is easy to lose track of once the original team moves on. That visibility gap, not the industry itself, is what these two vulnerabilities are exploiting.
Are fixes available?
Yes, for both. CVE-2026-27771 was fixed in Gitea 1.26.2, released May 20, 2026. CVE-2026-20896 was fixed in Gitea 1.26.3, released roughly a month later, and carried forward into 1.26.4.
Because the fixes landed in different releases, patch status needs to be checked separately for each. An instance running exactly 1.26.2 is no longer vulnerable to CVE-2026-27771 but remains exposed to CVE-2026-20896 until it is upgraded to 1.26.3 or later. Only 1.26.3 and newer addresses both.
Forgejo and other Gitea forks follow their own release schedules for equivalent fixes. Defenders running a fork should confirm the specific patched version with that project rather than assuming parity with upstream Gitea’s version numbers.
Are there any other recommended actions to take?
Until every instance is confirmed on Gitea 1.26.3 or later, defenders should:
- Inventory all self-hosted Gitea and Forgejo instances, including ones stood up outside central IT
- Restrict direct access to the Gitea HTTP port to only the intended reverse proxy
- Disable
ENABLE_REVERSE_PROXY_AUTHENTICATIONon any instance that does not require it - Set
REQUIRE_SIGNIN_VIEW=trueon affected registries as an interim control before upgrading - Audit container registry contents for secrets that should never have been baked into an image
- Monitor access logs for anonymous OCI pull requests and unexpected
X-WEBAUTH-USERvalues
How can CyCognito help your organization?
CyCognito published Emerging Threat Advisories for CVE-2026-20896 and CVE-2026-27771 in the CyCognito platform and is actively researching enhanced detection capabilities for these vulnerabilities.
To learn how CyCognito can help your organization reduce external exposure and manage emerging threats more effectively, contact us to request a demo.