CVE-2026-27771: Gitea Exposes Private Container Images Without Auth

CVE-2026-27771 is a critical access control flaw in Gitea (an open-source, self-hosted Git platform used by organizations worldwide to manage code repositories) that allows any unauthenticated person on the internet — with no account, no password, and no credentials of any kind — to pull private container images from affected deployments. Discovered by security researchers at NoScope in April 2026, the vulnerability affects all versions of Gitea prior to 1.26.2 and has been present in the codebase for approximately four years. An estimated 30,000 or more self-hosted Gitea instances are affected. Forgejo, a popular community-maintained fork of Gitea that shares the same container registry implementation, is also confirmed vulnerable.

// 01 CVE-2026-27771: Technical Details

CVE-2026-27771 does not yet have a published CVSS v3 score at time of writing — NoScope's responsible disclosure process is ongoing and the NVD entry is pending full analysis. The functional severity is Critical: the attack requires no authentication, no user interaction, and no special tooling beyond a standard Docker client.

The root cause lies in Gitea's container registry implementation — the OCI (Open Container Initiative — the industry-standard specification for container image formats and distribution) registry built into Gitea to allow developers to push and pull Docker-compatible container images alongside their code repositories. When an operator marks a repository as private, the expectation is that the registry enforces authentication before serving image layers. CVE-2026-27771 breaks this expectation entirely.

On affected versions, the private designation on a container repository does not deliver the protection operators reasonably expect. The Gitea container registry's authentication logic fails to enforce access control when serving container image blobs — the actual file layers that make up a container image. An attacker who knows (or can guess or enumerate) a Gitea instance's hostname and a repository path can use a standard docker pull command to retrieve the full container image without any credentials:

# CVE-2026-27771 — unauthenticated private image pull
# No account, no token, no prior access required
docker pull gitea.target-org.internal/private-team/production-api:latest
# Returns full image layers including any embedded secrets, credentials, or proprietary code

This is particularly severe because container images frequently contain:

• Application source code and proprietary binaries built into the image
• Hardcoded credentials and API keys embedded during build time
• Database connection strings and internal service endpoints
• Environment-specific configuration files including secrets management agent configuration
• Infrastructure topology information visible in Dockerfiles and image layer history

The vulnerability was discovered by NoScope through responsible disclosure research. The flaw went undetected in Gitea's codebase for approximately four years — since a version that would have introduced the container registry feature — despite the platform being widely adopted for self-hosted Git and container registry hosting.

// 02 Exploitation Status and Threat Landscape

CVE-2026-27771 was responsibly disclosed by NoScope and patched in Gitea 1.26.2. There is no confirmed report of active exploitation in the wild at the time of writing. However, the nature of the vulnerability — requiring no authentication and exploitable with standard tooling — means the barrier to exploitation is extremely low. Any attacker who can enumerate or guess Gitea instance hostnames from DNS records, Certificate Transparency logs, or simple internet scanning can immediately begin pulling private images.

The Hacker News reported the disclosure on May 27, 2026, significantly raising the public profile of the flaw. Given that no credentials or specialized knowledge are required to exploit CVE-2026-27771, organizations running unpatched Gitea instances should assume that private images may already have been accessed.

Forgejo — the community-maintained Gitea fork that is increasingly popular in privacy-focused and self-hosted communities — shares Gitea's container registry codebase and has been confirmed vulnerable by NoScope's testing. Forgejo users should check the project's security advisories for the corresponding patch.

// 03 Who Is Affected

Any organization running a self-hosted Gitea deployment on a version prior to 1.26.2 with an OCI container registry enabled is vulnerable. This includes:

• DevOps and platform engineering teams using Gitea as a combined Git host and private container registry
• Security-conscious organizations that chose Gitea over GitHub/GitLab specifically for self-hosted data control — the irony being that the private registry feature they relied on for confidentiality is the vulnerable component
• Forgejo users who have not yet received a corresponding patch from the Forgejo project

The approximately 30,000 affected deployments include a mix of internet-facing and internal instances. Internet-facing instances are immediately exploitable by any external attacker; internal instances are exploitable by any attacker with network access, including via phishing or supply chain compromise.

// 04 What You Should Do Right Now

• Update to Gitea 1.26.2 or higher immediately: The patch is available now from the official Gitea release page. This is the only complete remediation for CVE-2026-27771.

• Apply the temporary workaround if immediate upgrade is not possible: Set REQUIRE_SIGNIN_VIEW = true in your Gitea configuration file (app.ini). This forces authentication for all content access on the instance, including container registry endpoints.

“ini [service] REQUIRE_SIGNIN_VIEW = true “

Note: This mitigation also makes all repositories read-only to anonymous users, which may affect public-facing projects. Evaluate the operational impact before applying.

• Audit container images for embedded secrets: Assume any private container image hosted on an unpatched Gitea instance may have been accessed by unauthorized parties. Scan image layers for hardcoded credentials using tools like Trufflehog or Gitleaks applied to extracted image layers.

• Rotate credentials embedded in container images: Treat any API keys, database passwords, SSH keys, or cloud provider credentials baked into private images hosted on affected instances as compromised.

• Check Forgejo status: If your organization runs Forgejo, monitor the Forgejo security advisory page for the corresponding patch and apply it as soon as available.

• Review access logs for anonymous pulls: Check Gitea's access logs for GET requests to /v2/<org>/<repo>/blobs/ or /v2/<org>/<repo>/manifests/ originating from unauthenticated sessions, which would indicate exploitation attempts.

// 05 Background: Understanding the Risk

Container registries that are intended to be private are frequently used to store more than just application code. They often contain full build artifacts including intermediate layers with development tooling, debug symbols, and occasionally credentials that developers intended to clean up before final image production but did not. Even a "clean" production image often contains internal service discovery configuration, health check endpoints, and infrastructure-specific settings that provide meaningful intelligence to an attacker.

Gitea's appeal to organizations that want data sovereignty — running their own Git and container infrastructure rather than depending on GitHub, GitLab, or Docker Hub — makes this vulnerability particularly stinging. The explicit value proposition of self-hosting is control over sensitive code and artifacts; CVE-2026-27771 undermines that value proposition entirely for users of the container registry feature.

The four-year detection gap is a reminder that container registry security, unlike core Git authentication, may receive less scrutiny during security reviews, both internally at open-source projects and externally by users who assume that "private" registry permissions work as documented.

// 06 Conclusion

CVE-2026-27771 is a four-year-old access control failure in Gitea's container registry that lets any unauthenticated attacker pull private images from 30,000+ self-hosted deployments. Patch to Gitea 1.26.2 immediately, apply the REQUIRE_SIGNIN_VIEW workaround if you cannot, and treat any credentials stored in private images on unpatched instances as already exposed.