Gitea CVE-2026-27771: anyone could pull your private container images, no login

Gitea shipped 1.26.2 on 20 May 2026 to close CVE-2026-27771, an access-control flaw in the built-in OCI container registry that let any unauthenticated client pull image layers and manifests for repositories explicitly marked private. UK security firm Noscope, which found the bug in April through its autonomous pentesting agent and is credited in the 1.26.2 release notes, published its writeup and an exposure estimate of ~30,000 internet-reachable instances on 27 May at noscope.com.

CVSS is 8.2. Per Noscope, the bug had been live for roughly four years and was never caught by Gitea's own tests because the private flag controlled the UI visibility of a package without being plumbed into the registry endpoint's auth path.

What the bug does

Gitea's container registry implements the standard OCI distribution API: clients hit /v2/<owner>/<image>/manifests/<tag> and /v2/<owner>/<image>/blobs/<digest> to fetch image data. The endpoint honored the repository's private flag for the web UI but did not enforce a token check for those two API routes. An anonymous docker pull <gitea-host>/<owner>/<private-image>:<tag> succeeded against any affected instance — no account, no Bearer token, no docker login required.

Per Noscope's writeup, organizations whose private registries were readable include healthcare providers, aerospace manufacturers, retail infrastructure, and internet service providers. Container images regularly carry hard-coded secrets, internal API endpoints, CI tokens, and proprietary source — the impact is whatever the operator considered private enough to mark private.

Affected versions

• Gitea: every version of the self-hosted edition prior to 1.26.2.
• Forgejo: Noscope confirmed Forgejo, the community fork, shares Gitea's container registry implementation and is vulnerable. Patch tracking is on the Forgejo project; check the Forgejo release feed before declaring the instance clean.

Exploitation status

No public proof-of-concept and no confirmed in-the-wild exploitation at disclosure. That said, the exploit primitive is docker pull against a known endpoint — trivial to script, trivial to mass-scan. Operators should assume opportunistic enumeration will begin within days of the Noscope writeup landing in feeds.

Action checklist

1. Upgrade to Gitea 1.26.2 on every self-hosted instance. The release notes are at blog.gitea.com/release-of-1.26.2.
2. If you cannot patch immediately, set [service].REQUIRE_SIGNIN_VIEW=true in app.ini. This disables all anonymous access to the instance and forces a login before any endpoint — including /v2/ — answers. It is a hammer; expect to revisit when the patch ships.
3. Patch Forgejo as soon as the maintainer release lands. In the interim, the same REQUIRE_SIGNIN_VIEW workaround applies.
4. Rotate anything that lived in a private image. Treat every image in a private repo on an exposed instance as having been pulled. Static credentials, signing keys, API tokens, internal URLs, and SBOM-visible dependency lists are the high-priority items.
5. Hunt for anonymous pulls. Gitea logs registry requests via the standard access log. Grep the last 12 months — that is how long the bug has been exploitable — for GET /v2/.../manifests/ and GET /v2/.../blobs/ requests that returned 200 with no user attached. The Noscope writeup includes the canonical request shapes.
6. Re-verify private flags. Repositories that were assumed private but pulled successfully without auth should be re-marked, and operators should confirm the patched build actually rejects anonymous /v2/ pulls before declaring victory.

Context

The pattern is one to learn from: a privacy flag at the project layer that never reached the storage layer. The blast radius is amplified by the fact that container registries are a more recent feature on Git platforms than the Git data plane, so the policy enforcement around them tends to be younger, less tested, and less covered by upstream security audits.

Self-hosting Gitea or Forgejo to keep code on-prem is a valid choice, and one we tend to encourage. But the operational cost includes patching not just the Git surface but every adjacent feature — package registries, container registries, Actions runners — at the cadence the upstream sets, not the one your change-management board prefers. Four years of private-that-was-not-private is the reminder.