TL;DR: CVE-2026-27771 allowed unauthenticated access to private container images on Gitea instances. 30,000+ deployments were affected. The flaw went undetected for 4 years. NoScope discovered and responsibly disclosed it. If you run Gitea Update to v1.26.2 immediately.

If you can't update right now, set [service].REQUIRE_SIGNIN_VIEW=true in your Gitea configuration as a temporary stopgap. Note this stopgap isn't suitable if you intentionally expose some containers publicly.

If your team runs Gitea and uses its built-in container registry, there's a question you should be asking right now: has anyone been reading your private images?

Not because you misconfigured something. Not because someone phished your credentials. Because for close to four years, Gitea's container registry has allowed any person on the internet, with no account, no password, and no prior access, to pull what would be considered private container images at first glance from affected instances as if they were public.

In April 2026, NoScope found it.

What container images actually contain

Before we get to the numbers, it's worth being specific about what's at stake.

A container image isn't just a deployable artifact. It's a complete snapshot of a running environment: the application code, its dependencies, its configuration, and very often things that should never have been packaged in the first place: database credentials, API keys, internal service endpoints, TLS certificates, hard-coded environment variables pointing at production infrastructure.

In a lot of organisations, the image is effectively a photograph of how production is wired together. Teams push them to private registries with the expectation that "private" means something. On affected Gitea instances, it didn't.

What NoScope found

The NoScope pentesting agent is an autonomous system that approaches a target with an attacker's mindset. It operates on a carefully curated methodology, refined by in-the-field experience from real pentesters, and applies that methodology systematically and effectively across the full functionality an application exposes.

That systematic coverage is what produced this finding. The flaw lives in a registry feature that, from the outside, behaves exactly as documented. There is nothing about it that draws attention on a casual look. NoScope's methodology exercises the access model from every angle the surface supports, and the gap surfaced from there.

The full impact was then confirmed by our research team in a controlled environment against a Gitea instance configured exactly as a typical maintainer would. The finding reproduced cleanly. The default configuration was sufficient to expose it.

On affected versions, the private designation on a container repository did not deliver the protection operators reasonably expected it to. Specific exploitation details are not published here. Full technical details have been shared with the Gitea maintainer team and are available alongside the official advisory at CVE-2026-27771.

At no point during this research was any private image content accessed, downloaded, or inspected from any third-party host. All research was conducted in a controlled environment.

The reach of it

Finding a vulnerability on one instance is one thing. Understanding how many people it affects is another.

Shodan was used to identify internet-facing Gitea instances carrying the platform's default identifier, a deliberately conservative approach. It only catches instances that haven't customised their public-facing presentation. Instances behind reverse proxies with custom branding, those running Forgejo or other Gitea forks, and anything Shodan hasn't indexed are all invisible to this query. The numbers below are a floor.

Shodan reported 34,144 matching hosts at the time of the work. Across a 100-host sample, 93 returned responses consistent with the issue being present on a non-invasive probe that stops well short of accessing any private content. Applied across the Shodan population, that puts a conservative floor of approximately 31,750 likely-affected instances from this one narrow query alone.

Digging into that population is where the picture gets more concerning.

It's production infrastructure, not hobby machines

A 9,500-host subset of Shodan's results was pulled for a closer look at the metadata Shodan already provides on each entry: country, hosting organisation, port configuration. The picture is unambiguous:

• 52% run on major cloud or VPS platforms: Alibaba Cloud, Tencent Cloud, Hetzner, OVH, DigitalOcean, Akamai. These are provisioned, billed, managed deployments. They are production systems.
• 68% are running on Gitea's default port: no meaningful configuration change from a fresh install.

The data is unambiguous. These aren't hobby machines. These are organisations that made a deliberate decision to self-host their development infrastructure, running it on production-grade compute, for real workloads.

30,000+ Instances Across 30+ Countries

The same Shodan dataset puts the exposure across more than 30 countries:

China, the US, and Germany alone account for nearly two thirds of all enumerated instances. This is not a regionally concentrated finding.

Who's affected and what's exposed

The following table reflects a manually reviewed sample of 10 hosts, cherry-picked from the broader enumeration to illustrate the range of sectors affected. No image content was accessed from any third-party host; repository names alone were sufficient.

Healthcare providers. Aerospace manufacturers. Retail infrastructure. ISPs. These aren't edge cases in Gitea's user base.

Four years. Undetected.

The flaw has been present long enough to ship through many release cycles. Long enough for thousands of operators to push private content into affected versions on the reasonable expectation that the platform's access controls were doing their job. Long enough for the assumption of safety to become deeply embedded.

Comprehensive coverage of a mature platform is genuinely hard. Functionality accrues over years, each release widening the surface, and exercising every angle of every feature with the same rigour is more work than any single engagement can reasonably absorb.

NoScope's methodology is built around that problem. The same attacker mindset is applied systematically across the full surface an application exposes, regardless of how long the platform has been in service or how settled a particular feature looks from the outside. This finding is what that approach produces in practice.

Responsible disclosure

NoScope notified the Gitea maintainer team before publication, following internal validation of the finding and an assessment of the exposure by the research team. The Gitea maintainer team assigned CVE-2026-27771 and officially credited NoScope in the v1.26.2 release.

Operators running Forgejo or other Gitea-derived forks should not assume they are unaffected. Forgejo, which shares Gitea's container registry implementation, has been confirmed as affected through NoScope's testing. Any fork sharing the same implementation should treat itself as affected until its maintainers have independently verified otherwise.

Immediate mitigation: Update to Gitea v1.26.2 immediately. If an immediate update isn't possible, setting [service].REQUIRE_SIGNIN_VIEW=true in the Gitea configuration mitigates this vulnerability by requiring authentication for all content access. Note that this setting is not suitable for instances that intentionally expose some containers publicly, operators in that situation should weigh the trade-off carefully.

On the patch: v1.26.2 introduces UI changes that make package visibility clearer to users. It is worth noting that this addresses visibility at the interface level. The underlying permissions model for packages remains a longer term work in progress per the Gitea maintainer team. Updating to v1.26.2 is still the recommended action. Review the full advisory at CVE-2026-27771 and the v1.26.2 release notes to understand exactly what the release does and does not fix.

About NoScope

CVE-2026-27771 is one example of what NoScope's autonomous pentesting agent finds in practice. A 4-year-old flaw, sitting in plain sight, across 30,000+ production deployments, found by systematically exercising every angle of the attack surface.

If you want to know what an attacker would find before they find it themselves, that's what NoScope is built for.

Get in touch: noscope.com/contact, LinkedIn, X