Over 10,000 Docker Hub Images Found Leaking Credentials, Auth Keys (bleepingcomputer.com)
(Thursday December 11, 2025 @10:30PM (BeauHD)
from the PSA dept.)
- Reference: 0180365075
- News link: https://yro.slashdot.org/story/25/12/11/2328238/over-10000-docker-hub-images-found-leaking-credentials-auth-keys
- Source link: https://www.bleepingcomputer.com/news/security/over-10-000-docker-hub-images-found-leaking-credentials-auth-keys/
[1]joshuark shares a report from BleepingComputer:
> More than 10,000 Docker Hub container images expose data that should be protected, including live credentials to production systems, CI/CD databases, or LLM model keys. After scanning container images uploaded to Docker Hub in November, security researchers at threat intelligence company Flare [2]found that 10,456 of them exposed one or more keys . The most frequent secrets were access tokens for various AI models (OpenAI, HuggingFace, Anthropic, Gemini, Groq). In total, the researchers found 4,000 such keys. "These multi-secret exposures represent critical risks, as they often provide full access to cloud environments, Git repositories, CI/CD systems, payment integrations, and other core infrastructure components," Flare [3]notes . [...]
>
> Additionally, they found hardcoded API tokens for AI services being hardcoded in Python application files, config.json files, YAML configs, GitHub tokens, and credentials for multiple internal environments. Some of the sensitive data was present in the manifest of Docker images, a file that provides details about the image.Flare notes that roughly 25% of developers who accidentally exposed secrets on Docker Hub realized the mistake and removed the leaked secret from the container or manifest file within 48 hours. However, in 75% of these cases, the leaked key was not revoked, meaning that anyone who stole it during the exposure period could still use it later to mount attacks.
>
> Flare suggests that developers avoid storing secrets in container images, stop using static, long-lived credentials, and centralize their secrets management using a dedicated vault or secrets manager. Organizations should implement active scanning across the entire software development life cycle and revoke exposed secrets and invalidate old sessions immediately.
[1] https://slashdot.org/~joshuark
[2] https://www.bleepingcomputer.com/news/security/over-10-000-docker-hub-images-found-leaking-credentials-auth-keys/
[3] https://flare.io/learn/resources/docker-hub-secrets-exposed/
> More than 10,000 Docker Hub container images expose data that should be protected, including live credentials to production systems, CI/CD databases, or LLM model keys. After scanning container images uploaded to Docker Hub in November, security researchers at threat intelligence company Flare [2]found that 10,456 of them exposed one or more keys . The most frequent secrets were access tokens for various AI models (OpenAI, HuggingFace, Anthropic, Gemini, Groq). In total, the researchers found 4,000 such keys. "These multi-secret exposures represent critical risks, as they often provide full access to cloud environments, Git repositories, CI/CD systems, payment integrations, and other core infrastructure components," Flare [3]notes . [...]
>
> Additionally, they found hardcoded API tokens for AI services being hardcoded in Python application files, config.json files, YAML configs, GitHub tokens, and credentials for multiple internal environments. Some of the sensitive data was present in the manifest of Docker images, a file that provides details about the image.Flare notes that roughly 25% of developers who accidentally exposed secrets on Docker Hub realized the mistake and removed the leaked secret from the container or manifest file within 48 hours. However, in 75% of these cases, the leaked key was not revoked, meaning that anyone who stole it during the exposure period could still use it later to mount attacks.
>
> Flare suggests that developers avoid storing secrets in container images, stop using static, long-lived credentials, and centralize their secrets management using a dedicated vault or secrets manager. Organizations should implement active scanning across the entire software development life cycle and revoke exposed secrets and invalidate old sessions immediately.
[1] https://slashdot.org/~joshuark
[2] https://www.bleepingcomputer.com/news/security/over-10-000-docker-hub-images-found-leaking-credentials-auth-keys/
[3] https://flare.io/learn/resources/docker-hub-secrets-exposed/
Impressive (Score:2)
by gweihir ( 88907 )
And not in a good way. Looks like a rather large number of people seriously do not know what they are doing.
Say it isn't so... (Score:2)
by skogs ( 628589 )
No way. The guys that can't manage to manage a real machine, can't understand how things work, and farming out thought also can't figure out their container shouldn't have hard coded creds?
Demographic stats would be nice (Score:4, Interesting)
It'd be great to know who and why still ends up committing or pushing secrets in containers. As a software professional, I haven't seen anyone do it for a decade now. Am I lucky to just work at places that good code practices or is there some sort of a parallel, underground development universe I don't know about?
It would also be good to know if there are any geographical patterns (yes, I'm looking at you, South Asia), or how much of that code was pushed by security-oblivious AI.
Re: (Score:3)
Yeah... like dudes, go look up "Heroku 12 factor" and memorize it and live it. Its a *really useful* guide to building scalable app without having to degenerate into hellish lambda messes or whatever.
And one central key to it is;- Dont put config in the container! Inject it on deploy!
We knew this at least a decade ago, at least.
Re: (Score:2)
I simply put all sensitive files and even some IDE specific files in .gitignore then I have a folder examplefilesgitignore with the same structure as the root folder where I put example files without anything sensitive into them.
Re: (Score:2)
Honestly? Everybody, including every software team of any significant size. Likely even your own.
I work in big tech, and it wasn’t for pre-commit and pre-receive hooks, a secret would get committed to GitHub every single day. This has been the case at every large tech company I’ve worked at for the last decade.