Gitea Container Registry Flaw Exposed Private Images to Unauthenticated Attackers

A newly disclosed Gitea vulnerability allowed unauthenticated attackers to pull container images that users had marked as private. The flaw, tracked as CVE-2026-27771, affects Gitea’s built-in container registry and is fixed in Gitea 1.26.2.

The issue matters because container images often contain much more than application binaries. They can include source code, internal service names, configuration files, API keys, database credentials, cloud tokens, and other deployment details that attackers can use for follow-on attacks.

NoScope, which discovered and disclosed the issue, said the bug allowed anyone on the internet to access private container images without an account, password, token, or prior access. The company estimated that more than 30,000 deployments may have been affected.

What CVE-2026-27771 Exposed

Gitea is widely used by teams that want a self-hosted alternative for Git repositories, issue tracking, package hosting, and CI/CD workflows. Its built-in container registry lets teams store Docker and OCI images next to their code.

On affected versions, the private label on a container repository did not enforce the expected registry-level access control. That means a container image could appear private in the interface while the registry still served image manifests and layers to anonymous requests.

The Orca Security analysis says attackers could send standard Docker or OCI pull requests to affected registry endpoints and retrieve complete private container images with no authentication.

Gitea Vulnerability at a Glance

Item	Details
CVE	CVE-2026-27771
Affected product	Gitea built-in container registry
Affected versions	All Gitea versions before 1.26.2
Fixed version	Gitea 1.26.2
Reported CVSS score	8.2
Attack requirement	No authentication required against reachable vulnerable registry endpoints
Main impact	Exposure of private container images, code, secrets, and infrastructure details

Why Private Container Images Are High-Value Targets

Private container images often act like snapshots of production systems. They may include compiled application code, dependency lists, startup scripts, environment variables, certificates, private package references, and configuration files that reveal how services connect to each other.

If developers accidentally bake secrets into images, a registry access control bug can turn that mistake into a much larger breach. Attackers who pull a private image can inspect layers, read old build artifacts, search for hardcoded secrets, and map internal infrastructure.

The Hacker News reported that NoScope intentionally withheld deeper technical details to give Gitea users and related forks time to patch. The same report says Forgejo, a Gitea fork that shares the container registry implementation, was confirmed affected in testing.

How Many Deployments May Be Affected

NoScope used a conservative Shodan-based approach to estimate exposure. The company found 34,144 internet-facing Gitea hosts that matched the platform’s default identifier, then tested a 100-host sample without accessing private image content.

According to NoScope, 93 of those 100 sampled hosts returned responses consistent with the issue. Applied to the visible Shodan population, that produced a conservative floor of about 31,750 likely affected internet-facing instances.

The NoScope disclosure says affected systems appeared across more than 30 countries, with China, the United States, and Germany making up a large share of the enumerated exposure.

Exposure by Environment

Exposure Signal	What Researchers Reported
Visible Gitea hosts in Shodan query	34,144 matching hosts
Likely affected hosts from conservative estimate	About 31,750 internet-facing instances
Countries represented	More than 30 countries
Cloud or VPS hosting share	About 52% of reviewed hosts
Default port usage	About 68% of reviewed hosts
Example sectors	Healthcare, aerospace, retail, internet services, software development, and enterprise systems

Gitea Released a Fix in Version 1.26.2

Gitea’s 1.26.2 release notes credit NoScope for reporting CVE-2026-27771 and list the package-related fix among several security fixes in the update. Administrators running older Gitea versions should update as soon as possible.

The fix does not erase past exposure. Any container image stored in a vulnerable registry before patching should be treated as potentially exposed if the instance was reachable by untrusted users or the public internet.

That means security teams should not stop after upgrading. They should also review registry access logs, identify private images that may have been reachable, and rotate secrets that appeared in images, layers, build histories, or configuration files.

Forgejo and Other Forks Need Review

Forgejo users should also pay attention. Forgejo shares roots with Gitea and offers its own container registry support. Its container registry documentation states that users must authenticate to push images or pull from a private registry.

NoScope and Orca both warned that Forgejo was confirmed affected through testing because it shares the same container registry implementation. Other Gitea-derived forks should not assume they are safe until their maintainers verify the relevant access control path.

For operators, the practical step is simple: check the exact product and version in use, review maintainer advisories, and patch or mitigate before assuming private images stayed private.

Temporary Mitigation If You Cannot Patch Immediately

The recommended fix is to upgrade to Gitea 1.26.2. If an immediate upgrade is not possible, administrators can set [service].REQUIRE_SIGNIN_VIEW=true in the Gitea configuration as a temporary stopgap.

Orca Security notes that this workaround forces authentication for all anonymous access to the instance. That can reduce exposure, but it may also break expected public access to repositories, packages, or container images that an organization intentionally publishes.

Administrators should test the setting before deploying it across production. Public-facing open source projects may need a different short-term plan if anonymous access remains a business requirement.

What Security Teams Should Do Now

• Upgrade affected Gitea instances to version 1.26.2 or later.
• Check whether the built-in container registry is enabled and reachable from the internet.
• Review Gitea and reverse proxy logs for unauthenticated registry pulls.
• Inventory all private images stored during the possible exposure window.
• Search image layers and build history for API keys, cloud credentials, database passwords, tokens, certificates, and internal endpoints.
• Rotate any secret that appeared in an exposed or possibly exposed image.
• Check Forgejo and other Gitea forks for maintainer guidance and patches.
• Move secrets out of container images and into proper runtime secret stores.

Why Access Logs Matter

Gitea users should treat patching as the first step, not the last one. Registry logs may show whether unknown clients pulled images before the update. Reverse proxies, load balancers, and CDN logs may also help if Gitea’s own logging lacks enough detail.

Teams should look for anonymous requests to container registry endpoints, unusual user agents, unexpected IP addresses, spikes in blob or manifest downloads, and pull activity for repositories that should have remained private.

The Hacker News report says the flaw affects all versions before 1.26.2 and carries a CVSS score of 8.2. While no public technical exploit details were initially released, the lack of authentication makes the risk high for internet-facing deployments.

Container Registry Security Lessons

CVE-2026-27771 is also a reminder that “private” labels need enforcement at every layer. It is not enough for a web interface to hide a package if the API or registry protocol still serves it anonymously.

Security teams should regularly test private registry access from an unauthenticated client, from a low-privilege account, and from a service account with limited permissions. These checks should cover image manifests, blob layers, package metadata, tags, and download endpoints.

The Forgejo container registry documentation shows the expected model for private registry use: authentication should be required before pulling private images. CVE-2026-27771 shows why teams should validate that assumption in practice, especially after upgrades, migrations, and forked deployments.

What Gitea Operators Should Assume

Organizations that used vulnerable Gitea versions for private container hosting should assume that image confidentiality may have failed during the exposure window. That does not prove attackers accessed a specific image, but it changes the risk calculation.

Any embedded secret should be rotated. Any internal endpoint or architecture detail found in the image should be reviewed. Any production image with sensitive configuration should trigger a deeper incident response check.

Gitea 1.26.2 is the immediate upgrade target for Gitea users. The longer-term fix is stronger registry testing, cleaner secret handling, and a policy that treats container images as sensitive artifacts even when they sit behind an access-controlled registry.

FAQ