Exposed container registry
When it applies
A Docker/OCI registry is reachable — a self-hosted registry (:5000, /v2/), or a cloud one
(ECR/GCR/ACR/Harbor) with weak auth. Images are goldmines: source, configs, and baked-in secrets.
Why it works
Registries are often deployed without auth ("internal only") or with over-broad pull access. Image
layers preserve everything added at build time — .env files, cloud keys, private source,
tokens — even if a later layer deletes them, earlier layers keep them.
Method
- Detect & enumerate:
curl -s https://registry:5000/v2/_catalog(repo list) and.../v2/<repo>/tags/list.registry:2banner / an unauth/v2/= exposed. - Pull images:
docker pull registry:5000/<repo>:<tag>orcrane pull(no docker daemon). Anonymous pull of private images is the finding. - Mine layers for secrets:
crane export/docker savethen scan withtrufflehog filesystem/ grep for keys,.env, kubeconfig, cloud creds (→ validate withcode-review-secrets-detection). - Push (critical): if anonymous/weak push works, you can poison images (supply-chain) — prove with a harmless tag, don't tamper real images.
- Cloud registries: test misconfigured ECR/GCR/ACR policies; leaked registry creds → pull private images.
Gotchas
- Scan all layers/history, not just the final image — secrets hide in intermediate layers.
- Anonymous push is critical (supply-chain); anonymous pull of private images is high — rate accordingly.
- Only pull what proves the issue; images can be large and contain real data — handle carefully.
Verify success
Anonymous/unauthorized pull of a private image, a live secret extracted from its layers, or a successful (harmless) push proving write access.
References
Docker registry API docs; crane/trufflehog; "hacking Docker registries" write-ups.