In July 2025, A comprehensive academic study conducted by researchers at RWTH Aachen University in Germany has uncovered a widespread and deeply concerning security issue within the container ecosystem. The research revealed that tens of thousands of Docker container images hosted on Docker Hub contain confidential secrets, including private cryptographic keys and API credentials. These exposures dramatically increase the attack surface for modern applications and the infrastructure that depends on them.
Docker Hub serves as a central distribution point for container images used across development, CI/CD pipelines, and production environments. Because container images often function as reusable deployment templates, any embedded secret is effectively published to the internet once the image becomes public. The findings demonstrate that insecure image creation practices, not platform vulnerabilities, are at the core of this issue.
What Happened
The researchers analyzed 337,171 Docker images sourced from Docker Hub and thousands of private container registries. From these images, they extracted and examined 1,647,300 individual image layers, focusing on the latest available versions wherever possible.
Their analysis found that approximately 8.5% of all examined images contained sensitive secrets. In total, the researchers identified:
- 52,107 valid private cryptographic keys
- 3,158 distinct API secrets
- 28,621 Docker images containing exposed secrets
To ensure accuracy, the dataset was carefully validated by excluding test credentials, example secrets, and invalid matches. The findings therefore represent real, usable secrets rather than theoretical or sample data.
How It Happened
The exposure of secrets stemmed primarily from insecure container image creation practices rather than any flaw in Docker Hub itself.
Inadvertent Inclusion of Secrets
Developers frequently embed sensitive data into container images through:
- Hard-coded credentials in configuration files
- Environment variables copied into images during the build process
- Private keys stored in application directories
- Leftover development artifacts such as .env files
Once included in an image layer, these secrets persist permanently unless the entire image history is rebuilt.
Single-User and Poorly Governed Images
The study found that:
- 95% of exposed private keys
- 90% of exposed API secrets
were located in single-user images, strongly suggesting accidental leakage rather than malicious intent. This points to insufficient security awareness and a lack of automated safeguards during image publishing.
Public vs. Private Registries
Secret exposure was more prevalent on Docker Hub (9.0%) than in private registries (6.3%). This disparity indicates that users managing private registries may apply stronger security controls, while public image publishers often operate without formal review or governance processes.
Possible Impact
The practical implications of these exposures are severe and far-reaching.
Compromised Certificates and Trust Infrastructure
The researchers discovered 22,082 certificates relying on exposed private keys, including:
- 7,546 private CA-signed certificates
- 1,060 public CA-signed certificates
Public CA-signed certificates are particularly dangerous when compromised, as they are trusted across browsers, applications, and systems. Although only 141 public CA-signed certificates remained valid at the time of analysis, the risk persists if attackers harvested keys before expiration.
Internet-Wide Exposure
Using 15 months of internet-wide scanning data from the Censys database, the researchers identified 275,269 active hosts relying on compromised keys. These included:
- IoT and messaging systems (MQTT, AMQP)
- Databases and data services (FTP, PostgreSQL, Elasticsearch, MySQL)
- Communication platforms (SMTP, POP3, IMAP, SIP)
- Infrastructure access points (SSH servers and Kubernetes clusters)
In several scenarios, leaked keys could enable remote access, data exfiltration, service impersonation, or long-term persistence.
API Secrets and Cloud Risk
Most exposed API secrets were associated with cloud providers, particularly Amazon Web Services. Some also belonged to financial service platforms, such as Stripe. While ethical constraints prevented validation of these keys against live services, their exposure alone represents a significant risk of unauthorized access, financial abuse, or service disruption.
Recommendations
Addressing this issue requires both technical controls and cultural change.
Secure Image Build Practices
- Never embed secrets directly in container images.
- Use runtime injection mechanisms for credentials.
- Exclude sensitive files from build contexts.
Centralized Secrets Management
- Store credentials in dedicated secrets management systems.
- Ensure secrets are dynamically injected and rotated.
Automated Detection
- Integrate secret scanning into CI/CD pipelines.
- Block image publication when secrets are detected.
- Continuously monitor public registries for leaked credentials.
Credential Hygiene
- Immediately revoke and rotate exposed keys.
- Audit certificates and API tokens for misuse.
- Enforce short-lived credentials wherever possible.
Developer Awareness and Governance
- Train developers on container security best practices.
- Apply ownership, review, and approval workflows for public images.
- Restrict who can publish images to public registries.
How NHI Mgmt Group Can Help
Incidents like this underscore a critical truth, Non-Human Identities (NHIs) are now at the center of modern cyber risk. OAuth tokens, AWS credentials, service accounts, and AI-driven integrations act as trusted entities inside your environment, yet they’re often the weakest link when it comes to visibility and control.
At NHI Mgmt Group, we specialize in helping organizations understand, secure, and govern their non-human identities across cloud, SaaS, and hybrid environments. Our advisory services are grounded in a risk-based methodology that drives measurable improvements in security, operational alignment, and long-term program sustainability.
We also offer the NHI Foundation Level Training Course, the world’s first structured course dedicated to Non-Human Identity Security. This course gives you the knowledge to detect, prevent, and mitigate NHI risks.
If your organization uses third-party integrations, AI agents, or machine credentials, this training isn’t optional; it’s essential.
Final Thoughts
The RWTH Aachen study exposes a fundamental weakness in how container images are built, shared, and governed. Containers have become a primary vehicle for distributing software and, unintentionally, for distributing secrets.
This is not an isolated issue tied to Docker Hub alone. It reflects a broader industry challenge where speed and convenience routinely outweigh security discipline. As containerization continues to underpin cloud-native infrastructure, organizations must recognize that every container image is an identity-bearing artifact capable of granting access to critical systems.
Failing to secure these artifacts does not just introduce risk, it quietly hands attackers the keys to the environment. Solving this problem requires more than tools; it demands a shift in how teams think about containers, credentials, and responsibility in modern software delivery.
