Gitea Flaw Lets Anyone Pull Private Container Images Without Authentication

Unauthenticated Attackers Can Exfiltrate Your Private Container Images from Gitea

A newly disclosed vulnerability in Gitea — the popular self-hosted Git and container registry platform — allows any unauthenticated remote attacker to pull private container images from an exposed Gitea instance. No account, no password, no credentials of any kind are required.

What Happened

Cybersecurity researchers published details of the flaw affecting Gitea's container registry feature. The bug breaks authentication enforcement on the OCI (Open Container Initiative) registry endpoint, meaning an attacker who can reach your Gitea instance over the network can simply docker pull any image — including those explicitly marked private. Private repositories that contain proprietary code, internal tooling, credentials baked into images, or infrastructure configuration are all exposed.

The attack requires no prior foothold. If your Gitea instance is reachable from the internet, or from an internal network segment an attacker has already pivoted into, every container image you've pushed is potentially readable.

Why It Matters

Container images are frequently treated as a second-tier secret store — teams routinely bake in API keys, service account credentials, internal hostnames, TLS certificates, and compiled proprietary code. A private registry is often the only barrier protecting that material. This vulnerability eliminates that barrier entirely without leaving the kind of authentication noise that would trigger typical alerting.

Gitea is widely deployed by teams who want GitHub-like functionality without the SaaS dependency — small engineering teams, homelab operators, and organizations in regulated industries. Self-hosted instances are common precisely because the data is sensitive. That same self-hosted posture means patches land only when admins apply them; there is no automatic cloud-side mitigation.

Beyond direct credential exposure, an attacker who can pull your images can reconstruct your build pipeline, identify dependency versions for downstream supply-chain attacks, or silently inventory your internal infrastructure before moving laterally.

What To Do

1. Patch immediately. Check the Gitea releases page for the version that addresses this CVE and upgrade. This is not a configuration fix — the authentication bypass is in the application code.

1. Restrict network access now if you cannot patch immediately. Place your Gitea instance behind a VPN or firewall rule that blocks unauthenticated external access to the registry endpoints (/v2/ path). This is a temporary mitigation, not a fix.

1. Audit your registry for sensitive material. Run docker history against your images and review layers for baked-in secrets, credentials, or environment files. If found, rotate those credentials immediately — assume they have been read.

1. Review access logs. Look for unauthenticated or anomalous GET /v2/<repo>/manifests/ and GET /v2/<repo>/blobs/ requests in your Gitea or reverse-proxy logs. Unexpected pulls, especially in bulk or at unusual hours, may indicate the vulnerability has already been exploited against you.

1. Re-evaluate what goes into images. Use build-time secrets (Docker BuildKit --secret) rather than ENV instructions or COPY of credential files. This reduces blast radius for any future registry exposure.