Docker Hub Secrets Leak 2025: How 10,456 Public Container Images Exposed Cloud, CI and AI Keys

In December 2025, threat intelligence company Flare reported that 10,456 container images published on Docker Hub during November 2025 contained exposed secrets. The leaked values included cloud access keys, database passwords, GitHub and CI/CD tokens, payment integration keys and almost 4,000 API keys for AI model providers such as OpenAI, Anthropic, Hugging Face, Gemini and Groq. After filtering for high and critical severity, Flare tied the exposures to 205 namespaces and 101 identifiable companies, including a Fortune 500 company and a major national bank. There was no attacker and no single victim: the credentials were published by the organisations and developers themselves, often from personal Docker Hub accounts outside corporate control. Flare also found that when developers deleted a leaked secret, the underlying credential was usually left active. The study is a clear example of how non-human identities leak through build artefacts rather than source code.

At a glance

What happened

Flare set out to measure how many secrets were leaking through Docker Hub in a single month. Its researchers looked at container images uploaded from 1 to 30 November 2025 and used what the company describes as a dual approach: indexing image manifests and also unpacking images to inspect the files inside. Flare published the results on 10 December 2025 in a report written by researcher Assaf Morag.

The scan identified 10,456 container images containing exposed keys. Flare then filtered for high and critical severity findings, which left 205 distinct namespaces. It was able to link 101 of those namespaces to identifiable companies. BleepingComputer reported that most of the organisations were in software development, followed by market and industrial firms and AI and intelligent systems companies, with more than ten in finance and banking. Cloud Native Now put the software development group at 28 companies and manufacturing and industrial at 20.

The most common secrets were credentials for AI models. Flare counted "almost 4,000 AI keys", naming variables such as OPENAI_API_KEY, HF_TOKEN, ANTHROPIC_API_KEY, GEMINI_API_KEY and GROQ_API_KEY. Broken down by Docker Hub account, Flare's table shows 191 accounts with AI keys, 157 with API tokens, 127 with cloud credentials, 103 with access or encryption keys, 89 with database credentials, 44 with source control or CI secrets, 31 with communication platform tokens and 21 with payment credentials. It also found 10 npm access keys, three of them linked to medium-sized companies.

Many images leaked more than one secret. Flare says 42% of the leaked images contained five or more sensitive values, and that these exposures can "provide full access to cloud environments, Git repositories, CI/CD systems, payment integrations, and other core infrastructure." The typical routes were familiar: .env files packed into the image, Python files with AI API tokens hardcoded in plain text, secrets written directly into Dockerfiles, and whole project directories copied into the image during the build.

Several findings came from accounts that did not look corporate at all. Flare says it "identified a Fortune 500 company whose secrets were exposed through a personal public Docker Hub account", likely belonging to an employee or contractor, where the manifests held credentials with access to multiple internal environments. The Register quoted Flare as saying there were "no visible identifiers linking the repository to the individual or to the organization." In another case, a registry belonging to the chief software architect of a major national bank held hundreds of images, several with exposed AI API tokens, and Flare says more than 430 images associated with the bank were publicly visible. Another example was an AI model customisation company that leaked a GitHub token with administrative scopes including repo, delete_repo, admin:org and admin:enterprise.

Flare also watched what happened after the leaks. It says "approximately 25% of developers removed the exposed secret from their container or manifest within 1–2 days", but that "in most cases, the associated credential was not revoked." The Register summarised this as roughly 75% of removed secrets remaining active. None of the sources we reviewed reported a response from Docker, and the report does not say whether Flare notified the affected companies.

Timeline

How it happened: the identity attack path

1. Secrets live next to the code. Developers kept API keys, cloud credentials and tokens in .env files, configuration files and source files so that applications would run locally and in test.
2. The build copies everything. Dockerfiles that copy whole project directories, or that set secrets directly, carried those files into image layers and manifests.
3. Images are pushed to public registries. Images went to public Docker Hub repositories, often under personal or contractor accounts that the owning organisation did not know about or monitor.
4. Anyone can pull and unpack them. Public images can be downloaded and their layers inspected by anyone. Assaf Morag told eSecurity Planet that "many threat actors actively scan Docker Hub and other registries."
5. Deleting is not revoking. Removing a secret from an image does not invalidate the key. Where the credential was not revoked, which Flare says was most cases, it stayed usable by anyone who had already copied it.
6. One image, many identities. With five or more secrets in 42% of leaked images, a single pull could expose cloud, source control, CI and AI access together.

Impact

• Scale: 10,456 images with exposed keys in one month, 205 namespaces with high or critical findings and 101 identifiable companies, according to Flare.
• AI keys: almost 4,000 AI model keys, the most common secret type, drawn from providers including OpenAI, Anthropic, Hugging Face, Gemini and Groq.
• Privileged access: examples include a GitHub token with organisation and enterprise administration scopes, and credentials giving a Fortune 500 company's internal environments to anyone who pulled a personal account's images.
• Persistence of exposure: Flare says about 75% of developers did not revoke or rotate the underlying keys after removing them.
• Confirmed abuse: the sources we reviewed do not report confirmed exploitation of these specific credentials. Flare frames the findings as exposure, and warns that attackers routinely scan public registries.

What this means for NHI governance

Every secret in this study is a non-human identity: a cloud access key, a database account, a CI token, a GitHub token or an AI service key. None of them needed to be stolen from a server. They were packaged into artefacts and published by the teams that owned them. As Morag put it to Cloud Native Now, attackers do not break in, "they authenticate in", using keys that companies publish themselves. Secret scanning that stops at source repositories misses this route entirely, because the leak happens at build time, in image layers that never pass through a pull request.

The shadow IT findings are the governance gap. A personal Docker Hub account holding a Fortune 500 company's credentials is outside the company's inventory, its monitoring and its offboarding process. If the organisation does not know the account exists, it cannot scan it, and it will not revoke the keys when the contractor leaves. Ownership has to follow the credential, not the registry it happens to sit in.

The revocation result matters most. Deleting a leaked key from an image feels like remediation but achieves little: the image may already have been pulled, cached or mirrored. The only effective response is to revoke and reissue, and that is hard when keys are long-lived, shared across services and undocumented. The large share of AI keys also shows how quickly new services add to sprawl: teams wiring LLM APIs into applications are repeating the same mistakes made with cloud keys a decade earlier. This December study follows an earlier Docker Hub study from July 2025, which shows the problem is persistent rather than a one-off.

Recommendations

• Keep secrets out of images. Flare's rule is blunt: "No secret should ever exist inside a container image." Use .dockerignore, multi-stage builds and runtime injection, and scan built images, not just source code, before they are pushed.
• Centralise secrets in a vault. Store credentials in a secrets manager and inject them at runtime so they never appear in files that can be copied into a build. The Secrets Management Guide covers the patterns.
• Replace long-lived keys with short-lived credentials. Use federated, session-based access for cloud and CI, as Flare recommends, so that a leaked value expires quickly.
• Revoke, then rotate, then investigate. When a secret leaks, revoke it at the provider, issue a new one, invalidate sessions and check logs for use. Removing it from the image is not enough. Challenges of Rotating NHIs explains why this is difficult at scale.
• Govern AI API keys like cloud keys. Scope them per application, set spending limits and alerts, and track owners. See the LLM API Key Security and LLMjacking Guide.
• Find shadow registries. Monitor public registries for your domains, image names and known key patterns, including personal and contractor accounts, and require corporate namespaces for any work image.

Frequently asked questions

What did the Docker Hub secrets leak study find?

Flare scanned Docker Hub images uploaded in November 2025 and found 10,456 that exposed secrets, including almost 4,000 AI model API keys, cloud and database credentials and GitHub tokens. It linked high and critical severity findings to 101 companies, including a Fortune 500 company and a major national bank.

How did secrets end up in Docker Hub images?

Mostly through ordinary build habits: .env files and configuration files copied into images, API tokens hardcoded in application code, secrets written into Dockerfiles and whole project folders copied during builds. Many images were pushed from personal or contractor accounts outside corporate oversight.

Is removing a leaked secret from a Docker image enough?

No. Once an image is public, anyone may already have pulled it. Flare found that about a quarter of developers removed leaked secrets within one to two days, but most did not revoke the credential, so it remained usable. Leaked keys must be revoked and replaced.

Related NHI Mgmt Group resources

Docker Hub leaked secrets study, July 2025 · 17,000 secrets in public GitLab repositories · Misconfigured Git servers leaking secrets · The secret sprawl challenge · NHI breaches

How NHI Mgmt Group can help

Leaks like these start with API keys, cloud credentials and tokens that nobody inventories, owns or revokes, and increasingly they include the keys that connect applications to AI services. Our NHI Foundation Level Training Course teaches teams how to find, govern and rotate these non-human identities before a public image hands them to someone else.

References

• Flare: Thousands of Exposed Secrets Found on Docker Hub, Putting Organizations at Risk (10 December 2025)
• BleepingComputer: Over 10,000 Docker Hub images found leaking credentials, auth keys (10 December 2025)
• eSecurity Planet: Flare Finds 10,000 Docker Hub Images Exposing Sensitive Secrets (10 December 2025)
• The Register: 10K Docker images spray live cloud creds across the internet (11 December 2025)
• Techzine: Docker Hub contains treasure trove of 10,000+ images with exposed secrets (11 December 2025)
• Cloud Native Now: Flare Finds 10,000 Docker Hub Images Exposing Secrets (16 December 2025, updated 17 December 2025)