Gitea private container registry exposure widens NHI risk

At a glance

What this is: A Gitea container registry vulnerability allowed anonymous pulls of private images, making embedded code, secrets, and infrastructure details accessible without credentials.

Why it matters: It matters because private build artefacts often carry service-account secrets, API keys, and deployment metadata that expand blast radius across NHI, autonomous, and human-accessed environments.

By the numbers:

• Approximately 52% of affected instances run on major cloud platforms.

👉 Read Orca Security's analysis of CVE-2026-27771 and private registry exposure

Context

A private container registry is supposed to restrict who can pull image layers and manifests, but this issue shows what happens when the access control check is present in name only. In practice, the registry served private images to anonymous requests, which means the control plane protected the label rather than the content. For NHI programmes, that turns build artefacts into an access boundary that can be bypassed without touching the primary application.

The exposure is especially relevant to CI/CD and workload identity governance because container images often contain the hidden credentials and deployment details that other controls depend on. When those artefacts are retrievable without authentication, secrets rotation, least privilege, and internal segmentation all inherit a larger blast radius than teams usually model. That is a familiar NHI failure mode, but the registry context makes it easier to miss until disclosure forces the issue.

Key questions

Q: What breaks when a private container registry can be pulled without authentication?

A: The private label stops being a control and becomes only a description. Attackers can retrieve image layers and manifests anonymously, which exposes source code, embedded secrets, and deployment details. In practice, that means the registry leaks NHI material that can be reused for deeper compromise. Private artefacts must be treated as access-controlled identity assets, not just storage objects.

Q: Why do private container images increase NHI risk in CI/CD environments?

A: Because images often contain the secrets that automate deployment, not just application code. If those images are exposed, attackers may recover API keys, database credentials, certificates, and runtime configuration in one pull. That turns a registry issue into a credential incident and expands the blast radius across build, deploy, and production access paths.

Q: How do security teams know whether registry access controls are actually working?

A: They should test the registry endpoint itself with anonymous Docker and OCI pull requests, then verify that manifests and layers are denied for private repositories. UI permissions are not enough. The real signal is whether unauthenticated retrieval fails at the API layer, because that is where the exploit occurs.

Q: Who is accountable when exposed container images contain secrets and credentials?

A: Accountability usually sits with the team that owns the registry, the image build pipeline, and the secrets management process together. If private images can be pulled anonymously, the control failure spans platform engineering, application owners, and identity governance. Recovery should include patching, credential revocation, and a review of which teams approved the trust model.

Technical breakdown

How private registry access control failed

Gitea’s built-in OCI registry used a private/public designation that should have gated image pulls, but the enforcement path failed for anonymous requests. A standard Docker or OCI pull can request manifests and layers directly from the registry API, so if authentication checks are not applied consistently at that layer, the registry behaves like an open distribution endpoint. The result is not just metadata leakage. It is full retrieval of the image contents that the platform believed were private.

Practical implication: Verify that registry authentication is enforced at the pull endpoint, not only in repository metadata or UI permissions.

Why private images expose NHI material

Container images routinely bundle configuration files, deployment scripts, certificate chains, and sometimes hardcoded secrets used by service accounts or runtime automation. That makes the image itself a non-human identity asset, not just an application package. If an attacker can pull the image anonymously, they may recover API keys, database credentials, cloud tokens, and environment details in one pass. The control failure is therefore broader than source code disclosure. It is a compromise of the identity material embedded in build artefacts.

Practical implication: Inventory which secrets, tokens, and certificates are ever baked into images, then treat image exposure as a credential incident.

Why forked and self-hosted registries amplify the risk

The vulnerability affected Gitea versions before 1.26.2, and Forgejo was independently confirmed vulnerable because it shares the same registry implementation. That pattern is common in self-hosted Git and CI/CD stacks: a shared component quietly becomes the trust anchor for multiple downstream deployments. In those environments, the issue is not limited to one product line. It affects every instance that copied the same access model and assumed private meant protected.

Practical implication: Map shared upstream components across forks and self-hosted instances so a single registry flaw does not become a fleet-wide blind spot.

Threat narrative

Attacker objective: The attacker’s objective is to retrieve private container images at scale and mine them for code, secrets, and infrastructure intelligence that enable deeper compromise.

1. Entry occurred through unauthenticated Docker or OCI pull requests sent directly to the registry API, with no credentials, tokens, or prior access required.
2. Credential access was unnecessary because the flaw bypassed the intended access gate and returned private image layers and manifests to anonymous requests.
3. Impact followed when attackers could extract application source code, embedded secrets, and infrastructure details that support follow-on compromise and lateral movement.

Breaches seen in the wild

• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Private registry access was treated as a label problem, but it is an authentication problem. The registry trusted the repository state more than the requestor identity, which meant the private flag did not enforce the access boundary it implied. That is a governance failure, not just a coding defect, because teams will assume the artefact boundary inherits the same controls as the application boundary. Practitioners should treat image-pull authorization as a first-class identity control.

Container images are now credential-bearing NHI objects, not passive build outputs. When service-account keys, cloud credentials, or deployment certificates are embedded in private images, the image becomes a reusable access container for attackers. OWASP NHI Top 10 thinking applies here because the leak surface is the secret-bearing artefact, not only the runtime identity. The implication is that image handling must sit inside the NHI programme, not only inside DevSecOps.

Self-hosted Git and CI/CD stacks create a shared trust chain that fails uniformly when one registry component is wrong. Forgejo inheriting the same registry behaviour shows how fork ecosystems can propagate an access-control mistake across many deployments. That widens the identity blast radius because a single design assumption is duplicated into multiple operating environments. Practitioners should assume component reuse means shared exposure until each implementation is independently validated.

Identity blast radius is the right concept for private artefact leakage. The breach path is not just “someone downloaded a file”. It is that one anonymous pull can surface multiple identities worth of material, from API keys to cloud credentials to internal topology. That creates a compounded recovery problem because revocation, redeployment, and code review all become necessary once artefacts have been exposed. The practical conclusion is to measure exposure in credential count and privilege scope, not file count alone.

Access controls that fail open at the registry layer invalidate downstream trust assumptions. Teams often rely on private registries to protect build provenance, but once image retrieval is unauthenticated the provenance chain no longer protects secrets or deployment logic. That undermines both NHI governance and human-access review because the artefact can leak before any review cycle detects it. Practitioners should rethink private registry status as an assurance claim that must be continuously validated.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to Guide to the Secret Sprawl Challenge.
• From our research: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to OWASP NHI Top 10.
• For practitioners: use the 52 NHI Breaches Report to benchmark how exposed artefacts turn into credential theft, lateral movement, and repeat compromise.

What this signals

Identity blast radius is now a build-time problem as much as a runtime problem. Once private images can be pulled anonymously, the control that failed is not just registry authentication but the trust model for everything embedded in the artefact. Teams should expect incident response to include secret revocation, image rebuilds, and provenance review, not only patching. For broader governance context, the OWASP Non-Human Identity Top 10 remains the right lens for how artefacts become credential carriers.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the industry pattern is clear: identity material leaks wherever toolchains persist trust state. Private registries, MCP configs, CI logs, and issue trackers all carry the same underlying risk, which is persistent secrets outside intended control boundaries. Practitioners should track these surfaces together instead of managing them as separate point problems.

Private artefact leakage accelerates the need for continuous entitlement validation across NHI estates. If a registry or pipeline can expose credentials without authentication, then downstream access reviews cannot be the only assurance mechanism. Teams should pair secret scanning, image attestation, and registry endpoint testing so that build-time controls are validated before a production trust decision is made.

For practitioners

• Patch Gitea and forked registries immediately Upgrade to Gitea v1.26.2 and verify whether any Forgejo or other forked deployment is using the same registry implementation. Confirm the patch in every self-hosted instance, especially internet-facing environments that expose container pulls.
• Treat image exposure as a secret disclosure event Assume every private image may contain embedded credentials, certificates, or deployment metadata. Rebuild impacted images, revoke any secrets found in those artefacts, and rotate dependent cloud tokens and service-account credentials.
• Audit registry authentication at the API layer Validate that anonymous requests cannot pull manifests or layers from private repositories. Test the actual registry endpoint with standard Docker and OCI pull requests, not just the web UI or repository permission model.
• Map shared upstream components across self-hosted fleets Identify every deployment that inherits the same container registry code path, including forks and internally customised builds. Shared components should be tracked as a single control family so one access-control defect does not stay hidden across multiple platforms.

Key takeaways

• The core failure is not that a private registry was visible, but that access control did not hold at the retrieval point.
• The exposure risk is amplified because container images can carry source code, secrets, and infrastructure details in one compromised artefact.
• Immediate patching must be paired with secret revocation, image rebuilds, and validation of registry authentication at the API layer.

Key terms

• Private Container Registry: A private container registry stores image layers and manifests behind access controls so only authorised identities can pull them. In practice, it becomes part of the identity boundary for CI/CD and runtime delivery, because images often carry source code, certificates, and embedded secrets that should never be retrievable anonymously.
• Embedded Secret: An embedded secret is a credential, token, API key, or certificate that has been placed inside an image, file, or configuration bundle. Once exposed, it can outlive the original control that created it, so revocation and rebuilds become necessary even if the underlying system is later patched.
• Identity Blast Radius: Identity blast radius is the amount of access, data, and downstream trust that can be reached after one identity or artefact is exposed. For container registries, it is shaped by what the image contains, which systems trust it, and how quickly credentials and deployments can be rotated after exposure.
• Registry Authentication Layer: The registry authentication layer is the control point that decides whether a manifest or image layer can be returned to a requester. If it fails open, private status loses meaning and the registry can leak both artefacts and the identity material embedded within them.

Deepen your knowledge

Container registry exposure and embedded secret risk are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your teams rely on private images for CI/CD or production delivery, this is a practical place to start.

This post draws on content published by Orca Security: Gitea private container registry exposure and CVE-2026-27771. Read the original.