Heads up: Gitea CVE-2026-27771 Leaking Private Container Images
Hey everyone,
Just saw the disclosure regarding a critical flaw in Gitea's container registry (CVE-2026-27771). If you are self-hosting Gitea for your CI/CD pipelines or internal code, you need to pay attention to this.
The vulnerability allows unauthenticated remote attackers to pull private container images without any credentials. Essentially, if an attacker can guess or enumerate your image tags, they can download your proprietary code or binaries. This affects all versions prior to 1.26.2.
Technical Impact
The issue lies in how the registry handles authorization for manifest pulls. It seems that specific API endpoints fail to validate the Authorization header correctly, allowing anonymous access.
Detection & Mitigation
First, patch immediately to Gitea 1.26.2. Second, you should check your access logs to see if you've already been swept.
You can quickly check your current version via the API:
curl -s https:///api/v1/version | jq
For those with centralized logging, you might want to hunt for `200 OK` responses on `/v2/*/manifests/*` endpoints that do not contain an Authorization header. If you are using Azure Sentinel or similar, a query like this might help identify historical exposure:
ContainerRegistryLogs
| where Url contains "/v2/"
| where Url contains "/manifests/"
| where ResponseStatus == 200
| where isempty(AuthenticationHeaderValue)
| project Timestamp, SrcIp, Url
Has anyone seen active exploitation of this in the wild yet, or are we all just scrambling to patch before the bots find us?
Thanks for the head's up. I manage a few instances for clients and we're seeing a lot of homelab setups get hit by scanners almost immediately after disclosure.
One thing to add: If you can't patch immediately, consider restricting access to the /v2/ endpoint at the reverse proxy level (Nginx/Traefik) as a temporary stopgap.
nginx location /v2/ { auth_basic "Restricted"; auth_basic_user_file /etc/nginx/.htpasswd; proxy_pass http://gitea:3000; }
It's not a perfect fix since the app layer is still vulnerable, but it adds a hurdle until the upgrade is complete.
We spotted this on our honeypots about 2 hours before the news dropped. The traffic was very specific—pulling manifests for common image names like 'backend', 'api', and 'prod'.
Make sure you rotate any credentials or secrets embedded in those private images if they were exposed. Just patching doesn't undo the data leak.
Patched our dev environment this morning. No issues with 1.26.2 so far.
For detection, we grepped the nginx logs and didn't find any unauthorized pulls, but we had Basic Auth already configured on the registry route at the edge. It might be worth checking if that external auth layer actually saved us or if we just got lucky.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access