CVE-2026-27771: Your 'Private' Container Images Were Never Private. For Four Years.

The word "private" didn't mean what you thought it meant.

For almost four years, Gitea's container registry let anyone pull your "private" container images without authentication. No credentials. No tokens. No anything. Just ask for the image and it hands it over.

CVE-2026-27771. CVSS 8.2. Affects every version of Gitea before 1.26.2. Over 30,000 deployments across 30+ countries. Healthcare providers. Aerospace manufacturers. Retail infrastructure. ISPs.

Four years this was open. Four years of "private" meaning absolutely nothing.

What actually happened.

Gitea's UI lets you mark a container repository as private. You click the button, it says "private," you feel good about it. Your secrets are safe.

Except at the protocol level, where the actual container pulls happen, authentication was never enforced. The OCI registry protocol (the layer Docker and Kubernetes use to pull images) didn't check whether the requester had permission to access private repositories.

The "private" designation was a UI label, not a security control. Like putting a "Do Not Enter" sign on an unlocked door. Polite suggestion. Not a barrier.

Anyone who knew the registry URL and the image name could pull it. No authentication required at all.

Why this is worse than it sounds.

People put things in container images that should never be there. I know this because I see it constantly during assessments. Your container images probably contain:

• Application source code. The actual code your business runs on.
• Database credentials. Usernames and passwords hardcoded in environment variables or config files.
• API keys. Stripe keys. AWS credentials. Third-party service tokens.
• TLS certificates and private keys. The keys to your encrypted communications.
• Internal service endpoints. Exact URLs and ports for your backend infrastructure.

Developers package this stuff into images because it's convenient, because "it's private," because "nobody outside the team has access."

Except for four years on Gitea, everyone had access.

An attacker pulling your container image doesn't just get your application. They get the keys to your entire infrastructure. Database access. Cloud provider credentials. Service mesh topology. Everything baked into that image.

The lesson here is not about Gitea.

Gitea made a specific mistake and they patched it. That's good. But the bigger lesson applies to every business:

You need to verify your security controls, not just assume they work.

Clicking "private" in a UI doesn't mean something is private. Setting a password doesn't mean authentication is enforced. Configuring a firewall rule doesn't mean traffic is blocked. You have to test these things. You have to verify that the control actually does what you think it does.

I see this pattern constantly with small businesses:

• "We have encryption." (Is it actually enabled? On all data? At rest and in transit?)
• "We use MFA." (On every account? Or just the main admin?)
• "Our data is backed up." (When did you last test a restore?)
• "That server is private." (Have you scanned it from outside to confirm?)

The assumption gap between "I configured it" and "it actually works" is where breaches live.

What to do.

If you use Gitea:

Update to version 1.26.2 immediately. If you can't patch right away, set REQUIRE_SIGNIN_VIEW=true in your Gitea config as a temporary workaround.

Then rotate every credential that was ever stored in a container image on your instance. Every API key. Every database password. Every TLS certificate. Assume it was exposed because for four years, it was.

If you use Forgejo (the Gitea fork):

Same vulnerability. Same fix. Patch now.

For every business:

1. Audit what's in your container images. If your team builds and deploys containers, do you know what's baked into them? Credentials, keys, configs? Use tools like Trivy, Grype, or Syft to scan your images for secrets. You will probably not like what you find.

2. Never hardcode credentials in images. Use secret management tools (HashiCorp Vault, AWS Secrets Manager, even environment variables injected at runtime). The image should contain code, not keys.

3. Verify your access controls. Don't trust the UI. Test from the outside. Can an unauthenticated user reach what they shouldn't? The only way to know is to try.

4. Assume breach and rotate. If you had private container images on a Gitea instance at any point in the last four years, treat it as a credential exposure event. Rotate everything. Better to rotate credentials you didn't need to than to leave compromised ones in production.

This vulnerability existed for nearly four years across tens of thousands of deployments. Nobody noticed because nobody checked. The "private" label was enough to make everyone feel safe.

Feeling safe and being safe are not the same thing.

(773) 417-9994 or southsidechisolutions.com