TL;DR: A critical flaw in Gitea’s built-in container registry let unauthenticated attackers pull images marked private, exposing source code, embedded secrets, and infrastructure details across affected self-hosted deployments, according to Orca Security. The issue shows how private registry labels can fail without enforceable authentication, turning CI/CD artefacts into a high-value NHI exposure surface.
At a glance
What this is: This is a disclosure of CVE-2026-27771, where Gitea’s built-in container registry failed to enforce authentication for private images and exposed image contents to anonymous pull requests.
Why it matters: It matters because CI/CD artefacts often carry NHI secrets, credentials, and deployment detail, so a registry access-control failure can become both a secrets exposure issue and a broader infrastructure compromise path.
By the numbers:
- The affected footprint spans 30+ countries, with the highest concentrations in China, the United States, and Germany.
- Approximately 52% of affected instances run on major cloud platforms.
Context
Private container registries are supposed to separate controlled artefacts from anonymous retrieval, but that assumption fails when the registry access model does not actually enforce authentication. In this case, the issue sits squarely in the boundary between CI/CD infrastructure and non-human identity governance, because images often contain secrets, configuration, and deployment context that should never be retrievable by unauthenticated users.
The practical risk is not just image leakage. If private OCI layers expose API keys, database credentials, or cloud credentials, the registry becomes a secrets distribution point instead of a controlled delivery channel. For teams running self-hosted Git and build systems, this is a reminder that repository visibility and image visibility are different control planes and must be governed separately.
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: What are the signs that registry access control is failing in practice?
A: Look for any registry that can return private manifests or layers to unauthenticated requests, especially when documentation or UI labels suggest the content is private. A mismatch between intended visibility and actual API behaviour is the clearest failure signal. If anonymous pull requests succeed, the control is already failing.
Q: When should teams treat exposed container images as a broader compromise scenario?
A: As soon as an image is reachable by unauthorised users and contains any secrets, internal endpoints, or deployment details that could support follow-on access. At that point, the incident is no longer just a registry issue. It becomes a potential source of credential exposure, reconnaissance, and lateral movement.
Technical breakdown
Why private registry labels failed
Gitea’s built-in container registry treated the “private” label as a repository attribute but did not consistently convert that label into an authentication requirement at the registry endpoint. That means standard Docker and OCI pull requests could still return manifests and layers to anonymous callers. The technical failure is an authorization gap at the artefact-serving layer, not a weakness in image format or transport. Once the registry serves layers without checking identity, the supposed privacy boundary is effectively cosmetic. Practical implication: enforce access control at the registry API, not only at the repository metadata layer.
Practical implication: validate that registry requests require enforced authentication before any manifest or layer is returned.
Why container images are an NHI exposure surface
Container images routinely carry machine-readable artefacts that belong to non-human identity programmes: build-time credentials, API keys, database passwords, service endpoints, and deployment manifests. If an attacker can pull a private image, they are not just viewing code. They may also inherit the secrets and trust relationships embedded in the image’s contents and environment files. That makes image protection an NHI control problem as much as a supply chain problem, because the artefact can expose standing credentials or configuration that drive downstream systems. Practical implication: treat private images as credential-bearing assets, not passive binaries.
Practical implication: inventory image contents for embedded secrets and revoke any credential exposure that relies on image privacy alone.
How anonymous pull access becomes infrastructure reconnaissance
When image manifests and layers are exposed, attackers gain a low-noise way to map internal systems. Manifests reveal tags, architecture, and dependency structure, while embedded configuration can expose hostnames, environment variables, and orchestration details. That is enough to support follow-on discovery, targeted credential theft, and later movement into adjacent systems if the image includes privileged configuration material. The core issue is that access to artefacts can collapse the distinction between source code, runtime configuration, and operational topology. Practical implication: assume registry exposure can disclose both identity material and environment intelligence.
Practical implication: review container registries as reconnaissance sources and reduce what images reveal about runtime and infrastructure.
Threat narrative
Attacker objective: The attacker aims to extract private artefacts and embedded secrets that can be reused to compromise adjacent systems and infrastructure.
- Entry occurs through unauthenticated remote access to the container registry API, where standard Docker and OCI pull requests are accepted without credentials.
- Credential access follows because the retrieved private image layers may contain embedded API keys, database passwords, cloud credentials, and deployment configuration.
- Impact emerges when the exposed artefacts enable further compromise, including lateral movement, data breach, or infrastructure takeover.
Breaches seen in the wild
- Uber breach 2016: An AWS key posted to Uber's private GitHub repositories let intruders copy data on 57 million people; Uber paid $100,000 and hid it for a year.
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Private registry labels are not an access-control boundary: This flaw shows what happens when repository metadata is mistaken for enforced authentication. If a registry can serve layers to anonymous requests, the privacy model is already broken at the control plane. Practitioners should treat visibility labels as policy intent, not as proof of access enforcement.
Private container images are credential-bearing NHI assets: The article is not just about code leakage. It is about machine identities, embedded secrets, and deployment trust being packaged into artefacts that are often copied broadly across build and release systems. That makes image governance part of NHI governance, not an adjacent hygiene task.
Image exposure creates trust collapse across CI/CD and runtime: Once internal manifests and layers are readable, the boundary between build-time artefacts and runtime environment details disappears. That widens the blast radius from one registry flaw to whatever systems trusted the image contents to remain private. Practitioners need to assume the artefact itself can become an attack path.
Access control for artefacts must be evaluated at the serving layer: A registry can appear private in a user interface while still exposing content through its API. That is a governance failure because the control users rely on is not the control attackers face. Identity and access programmes should verify enforcement where content is actually delivered, not where it is labelled.
From our research library:
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Identity governance has to move closer to artefact delivery: Access reviews and repository permissions do not help if the registry itself can serve content without authentication. The control point that matters is the layer where artefacts are actually pulled, because that is where anonymous access either succeeds or fails.
Secret exposure in build artefacts changes the programme boundary: Teams that still treat container images as passive deployment objects will miss the NHI risk sitting inside them. If images can hold API keys, cloud credentials, and internal configuration, then image governance belongs in the same conversation as secrets management and workload identity.
For practitioners
- Patch exposed registry platforms immediately Upgrade Gitea to v1.26.2 and verify that any Forgejo deployment or downstream fork has an equivalent fix before leaving the instance internet-facing.
- Audit private images for embedded secrets Inspect image layers, manifests, and build artefacts for API keys, database credentials, cloud credentials, and internal endpoints that should not have been published.
- Rotate credentials exposed through images Treat any credential found in a compromised image as exposed and rotate it, including service tokens, database passwords, and cloud provider keys used by deployment pipelines.
- Restrict anonymous registry behaviour If immediate patching is not possible, enable the temporary sign-in requirement and remove assumptions that private repositories can safely serve content without authentication.
Key takeaways
- The vulnerability shows that a private label is not enough when registry APIs can still serve content to unauthenticated callers.
- The exposure matters because private container images can carry secrets, credentials, and infrastructure detail, not just application code.
- The control gap is at the serving layer, so remediation must combine patching, secret rotation, and verification that registry authentication is enforced.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Private images exposed embedded keys and credentials, making secret leakage the central failure mode. |
| NHI-04 — Insecure Authentication | The registry failed to enforce authentication before serving private content. | |
| NHI-05 — Overprivileged NHI | Exposed images can carry credentials with more scope than the artefact should ever reveal. | |
| Recommendation — Scan image layers and manifests for exposed secrets and revoke any credentials found in published artefacts. Require authenticated access before any private registry manifest or layer can be retrieved. Reduce credential scope in build artefacts and remove any standing access that private images expose. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Embedded credentials in private images point directly to authenticator lifecycle control. |
| Recommendation — Apply IA-5 to manage, rotate, and revoke authenticators that appear in build and registry artefacts. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack path centers on credential exposure followed by movement into adjacent systems. |
| Recommendation — Map exposed-image findings to credential access and lateral movement detections in your pipeline. | ||
Key terms
- Container Registry Security: Container registry security is the set of controls that govern how images are stored, trusted, scanned, and promoted. It matters because registries sit between code and runtime, so access permissions, provenance, and validation determine whether unsafe artefacts can reach production.
- 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.
- Image Layer Exposure: A supply chain risk where secrets, credentials, configuration files, or source fragments remain inside saved container layers even after they appear deleted in the final image. Attackers who can pull or export layers may recover information that was never meant to ship with the application.
- Artefact Serving Layer: The API or service endpoint that delivers build artefacts, container images, or packaged software to clients. It is a distinct control point from repository metadata, and it must enforce its own authentication and authorisation checks rather than inheriting them implicitly.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org