Notifications
Clear all
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.
NHIMG editorial — based on content published by Orca Security: Gitea private container registry exposure and CVE-2026-27771
By the numbers:
- Approximately 52% of affected instances run on major cloud platforms.
Questions worth separating out
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: 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.
Practitioner guidance
- 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.
- Treat image exposure as a secret disclosure event Assume every private image may contain embedded credentials, certificates, or deployment metadata.
- Audit registry authentication at the API layer Validate that anonymous requests cannot pull manifests or layers from private repositories.
What's in the full article
Orca Security's full analysis covers the operational detail this post intentionally leaves for the source:
- Version-specific exposure guidance for Gitea v1.26.2 and affected forks
- The temporary configuration workaround using REQUIRE_SIGNIN_VIEW=true and its side effects
- Asset inventory and reachability context for identifying internet-facing deployments
- Prioritisation logic for deciding which exposed instances need immediate remediation
👉 Read Orca Security's analysis of CVE-2026-27771 and private registry exposure →
Gitea private registry exposure: what IAM and CI/CD teams need?
Explore further
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
