Gitea CVE-2026-27771: Private Container Images Were Never Private

If you run a self-hosted Gitea instance with the container registry enabled, your “private” images were not private. CVE-2026-27771, disclosed this week, reveals that any unauthenticated person on the internet could pull container images marked as private from Gitea deployments — no account, no password, no credentials required. The flaw went undetected for close to four years and likely affects more than 30,000 deployments worldwide. Update to Gitea 1.26.2 now.

The Label Did Nothing

Gitea’s container registry lets users mark repositories as private. The problem: that designation was a UI label, not a security control. At the OCI registry protocol layer — the level that Docker and Kubernetes actually use when pulling images — authentication was never enforced on private repositories. The result was that anyone who knew a Gitea instance existed could pull its container images as if they were public.

The flaw affects all Gitea versions prior to 1.26.2. Security firm Noscope, which discovered and reported the vulnerability, confirmed it went undetected for close to four years. The Gitea maintainer team has acknowledged the issue and released a patch, noting the fix addresses “container auth for public instance” at the API level, though the broader package permissions model remains a work in progress.

Your Container Images Contain More Than Code

This is not a case where the exposed data is low-stakes. Container images are complete runtime snapshots. What developers package into them — often without thinking twice — includes database connection strings, API keys, TLS certificates, hard-coded environment variables pointing at production endpoints, and internal service addresses. Anyone who pulled a private image from an affected Gitea instance likely obtained credentials for everything that image connects to.

The pattern is well-documented. GitGuardian’s State of Secrets Sprawl 2026 report found 29 million new hardcoded secrets in public GitHub commits in 2025 alone — a 34 percent year-over-year increase. Secrets baked into container images follow the same trajectory. The assumption that “it’s behind a private registry” is a substitute for actual secrets hygiene has real consequences when the “private” label doesn’t enforce access.

Forgejo Is Also Affected

If you migrated from Gitea to Forgejo — Gitea’s community fork — do not assume you are safe. Noscope confirmed during its research that Forgejo shares the same container registry implementation and is also vulnerable. Forgejo is publishing its own fix in a parallel release. Check your version and apply the appropriate patch before assuming the migration protected you.

Who Got Hit: 30,000 Deployments Across 30 Countries

Using Shodan to enumerate publicly-accessible Gitea instances — without accessing any private content — Noscope identified more than 30,000 affected deployments across 30-plus countries. The exposure spans healthcare providers, aerospace manufacturers, retail infrastructure, and ISPs. Many of these organizations chose self-hosted Gitea specifically for data sovereignty. That requirement becomes meaningless if the “private” flag on the container registry does not actually restrict access at the network layer.

What to Do Right Now

Update to Gitea 1.26.2. This is the primary fix. If an immediate update is not possible, apply this workaround in your Gitea configuration:

[service]
REQUIRE_SIGNIN_VIEW = true

This forces authentication for all content access. It is a blunt instrument — it will also require login for intentionally public repositories — but it closes the container registry exposure while you prepare a proper upgrade. After patching, audit what your container images contain. If they included credentials, treat those credentials as compromised and rotate them immediately. Assume any instance running a vulnerable version with a public IP was reachable since at least 2022.

For detailed remediation steps, see the full advisory coverage and BleepingComputer’s security patch guidance.

The Actual Lesson

This bug is not technically exotic. It is a failure of interface trust versus enforcement trust. “Private” is a label. It communicates intent. It does not, on its own, enforce anything at the protocol layer. Every team running self-hosted infrastructure carries some version of this assumption: that access labels in the UI translate directly into network-level access controls. Often they do. Sometimes — as with four years of Gitea’s container registry — they do not.

Verify your access controls at the protocol layer, not just the label layer. Gitea’s UI showed “private.” The OCI API said come on in.