A critical flaw in Gitea’s container registry has been quietly exposing private container images to anyone on the internet for close to four years. The vulnerability, tracked as CVE-2026-27771 with a CVSS score of 8.2, affects all Gitea versions prior to 1.26.2 and was disclosed publicly this week after a patch was made available.
What went wrong
Gitea’s registry API has a logic flaw that causes the endpoint to respond normally to standard Docker and OCI pull requests even when no credentials are provided. In practice, this means that anyone who knows or can guess the image path on a Gitea instance can download the complete contents of a private container image without needing an account, a token, or any other form of authentication.
The private setting on a container repository gave operators a false sense of protection. The access control logic was applied at the web interface level but not consistently enforced at the API layer that container runtimes and CI systems actually use to pull images.
Scale of exposure
Researchers at Noscope estimate that more than 30,000 Gitea deployments across over 30 countries were affected. The largest concentrations are in China, the United States, Germany, France, and the United Kingdom. The affected organizations span healthcare providers, aerospace manufacturers, retail infrastructure, and internet service providers.
Because container images often contain application binaries, configuration files, embedded secrets, and dependency trees, unauthenticated access to private images can give an attacker a significant head start on understanding a target’s infrastructure and identifying further attack paths.
Any fork of Gitea should be treated as potentially vulnerable until independently verified. Forgejo has been confirmed to be affected.
What to do
The immediate fix is to upgrade to Gitea 1.26.2. For deployments that cannot upgrade right away, setting REQUIRE_SIGNIN_VIEW=true in the [service] section of the Gitea configuration disables all anonymous access to the instance, including the registry endpoint.
After patching, teams should audit their registry access logs for unexpected pulls against private repositories, particularly over the past 90 days. Any credentials, API keys, or configuration values embedded in affected container images should be rotated and treated as compromised.
Broader context for self-hosted DevOps
This vulnerability highlights a recurring issue with self-hosted DevOps tooling: the attack surface is broader than the web interface, and access controls must be enforced at every layer, including the API endpoints that CI/CD systems, container runtimes, and automated tooling use to interact with the platform. Periodic security reviews of the full API surface of internally hosted platforms are not optional.
For teams running self-hosted Gitea, Forgejo, GitLab, Gogs, or similar platforms, understanding what each API endpoint exposes and to whom is a basic security requirement that often falls between the responsibilities of the infrastructure team and the development team.
If you need help reviewing the security posture of your self-hosted DevOps tooling, auditing container registries and CI/CD pipelines, or implementing consistent access controls across your development infrastructure, contact Excello Digital. We work with engineering teams to close the gaps that automated updates miss.