Gitea Quietly Published a Container Registry That Ignored the "Private" Flag for Nearly Four Years—Any Anonymous Visitor Could Pull Private Container Images From 31,750 Deployments in Healthcare, Aerospace, Retail, and ISPs Worldwide Before Noscope's Autonomous Pentester Found CVE-2026-27771

For close to four years, every Gitea instance that hosted container images for internal use was leaking those images to the public internet. Operators set repositories to "private" and trusted the toggle. The toggle was a lie. UK security firm Noscope, running its autonomous pentester against public Gitea deployments, discovered that the container registry layer of Gitea never enforced the private flag at all. The fix arrived in Gitea 1.26.2 on May 20, 2026. The four year exposure window did not.

Key Takeaways

• CVE-2026-27771 affects every Gitea version prior to 1.26.2 and lets an unauthenticated remote attacker pull container images from repositories marked as private, without an account, password, or token.
• Noscope's autonomous penetration testing platform discovered the bug; the firm published findings on May 25, 2026 after Gitea released the fix on May 20.
• Approximately 31,750 internet exposed Gitea instances were vulnerable when Noscope sampled them—roughly 93% of the deployments it could find.
• Forgejo, the community fork of Gitea, shares the same container registry implementation and is vulnerable to the same flaw.
• Affected organizations span healthcare, aerospace, industrial manufacturing, retail and grocery infrastructure, social media, SaaS, and ISPs, with the largest geographic concentrations in China, the United States, and Germany.

What Is CVE-2026-27771 and How Did the Bug Work?

Gitea is a self hosted Git platform that gives organizations their own GitHub style interface for source code, issues, and—since version 1.17—container images via an OCI compatible registry. A user marks a container repository as private through the same UI used for source repositories. The expectation, reasonably, is that only authenticated users with explicit permission can pull the resulting images.

According to Noscope's disclosure, the access control check that gates source code on Gitea never ran on container manifest and blob requests. Any HTTP client that knew the repository path and asked for the manifest received the manifest. The same was true for image layers. The "private" label appeared in the UI; the registry served the bytes anyway.

The bug was a path of least resistance for attackers. It required no exploitation skill, no authentication, no cookies, and no special tooling beyond a standard docker pull or HTTP client. An attacker who could enumerate or guess organization and repository names could exfiltrate the entire image set.

Why Is This Bug So Bad?

Because container images are not just code. A modern container image is a snapshot of an entire runtime environment, and engineers routinely bake secrets, credentials, internal dependencies, and proprietary application code into the layers. Specifically, a leaked private image typically exposes:

• Application binaries and proprietary source code embedded in build artifacts
• Environment variables baked into intermediate build layers (database passwords, API keys, signing keys)
• Internal dependency versions and software bill of materials data
• Configuration files with internal hostnames, service endpoints, and infrastructure topology
• Cached credentials inside .docker/config.json, .npmrc, .pip/pip.conf, or git config files that the build inherited

Container layer caching makes this worse. A secret added to a Dockerfile and removed in a later instruction usually still exists in the intermediate layer; an attacker who pulls the whole image can reconstruct every transient value. For an organization that used Gitea's container registry to store internal builds for the past four years, the question is not whether something sensitive leaked, but what.

Who Found the Bug?

Noscope is a UK based security firm that operates an autonomous penetration testing platform. Their disclosure framing is unusual: the bug was found not by a human researcher reading source code but by automated probes against public Gitea instances. The same automated tooling that finds open S3 buckets at internet scale found that a sampled population of Gitea registries returned content for repositories marked as private.

This is the second major bug in 2026 to be discovered by automated AI driven scanning rather than human researchers. The first was the NGINX rewrite heap overflow uncovered by DepthFirst AI in a six hour scan. The Exim use after free and the second Linux ptrace flaw published in May also came from AI assisted discovery. The pattern—old code, old bug, new discovery method—is the story of the year for vulnerability research.

Which Deployments Are Affected?

Every Gitea instance running a version prior to 1.26.2 that has the container registry feature enabled is vulnerable. Noscope's Shodan based survey found roughly 31,750 internet exposed Gitea deployments, with 93% running an unpatched version at the time of disclosure. The geographic distribution skews heavily to China, the United States, and Germany; France and the United Kingdom are also among the top affected countries.

Sector breakdown from Noscope's analysis includes:

• Healthcare providers
• Aerospace manufacturers
• Industrial manufacturing operations
• Retail and grocery infrastructure
• Software development organizations
• Social media and messaging platforms
• SaaS providers
• Internet service providers

Forgejo, the community governed Gitea fork that emerged in 2022, ships the same container registry implementation and is vulnerable to the same flaw. Forgejo maintainers have published their own patched version.

How Do I Fix It?

Upgrade to Gitea 1.26.2 or later. The official fix landed on May 20, 2026 and is shipped as a normal version bump. Forgejo users should upgrade to the corresponding patched Forgejo version.

If you cannot patch immediately, the documented workaround is to set [service].REQUIRE_SIGNIN_VIEW=true in the Gitea configuration. This forces authentication for every read request—including container manifest and blob fetches—and closes the bypass at the cost of breaking any container repository intentionally exposed to anonymous users.

Patching is necessary but not sufficient. Any operator running an unpatched Gitea container registry on the public internet should assume their private images were exfiltrated and act accordingly:

1. Rotate every credential that could have been baked into a container image: database passwords, third party API keys, signing keys, internal service tokens.
2. Audit the image manifest for build secrets. Tools like trufflehog docker or gitleaks can scan layers for embedded credentials.
3. Review access logs from your Gitea reverse proxy for unusual manifest or blob requests against private repositories. Most Gitea operators never logged these requests because they never expected anonymous traffic.

Why This Matters for Email Security

Leaked container images often contain SMTP credentials, mail relay configuration, third party email service API keys, and the secrets used to send transactional and marketing email. An attacker who pulled a vulnerable Gitea image is not stopping at running the application—they are using the keys inside to send authenticated email from the victim organization's own domain. That is what makes the next wave of phishing convincing.

Gblock blocks the tracking pixels embedded in those follow on phishing emails, so even when an attacker is sending from a real corporate domain with valid SPF and DKIM, they cannot see which targets read the message, and they cannot tune the next round based on opens. The bug is patched. The credentials inside the images are still out there.