Topic starter
09/06/2026 11:24 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “Gitea Container Registry Exposes Private Images to Unauthenticated Attackers”.
By the numbers:
- Approximately 52% of affected instances run on major cloud platforms.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: The vulnerability shows that a private label is not enough when registry APIs can still serve content to unauthenticated callers.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
10/06/2026 1:43 am
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.
A few things that frame the scale:
- 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.
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Gitea private container registry exposure widens NHI risk
11/06/2026 12:47 am
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.
A few things that frame the scale:
- 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.
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Gitea private container registry exposure widens NHI risk
12/06/2026 2:21 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Gitea private container registry exposure widens NHI risk
This post was modified 1 day ago by NHI Mgmt Group