Listen to this Post
Introduction: The Credentials Nobody Remembered to Kill
Cloud security failures rarely begin with a dramatic breach. Sometimes, they begin with something much quieter: an access key committed to a public repository, copied into a dataset, embedded inside a Docker image, or forgotten in an old development project.
The dangerous part is what happens next.
According to research from Truffle Security, thousands of Amazon Web Services (AWS) credentials exposed publicly over a four-year period remain valid. More than 9,300 exposed AWS access keys identified between August 2022 and August 2026 were reportedly still active, creating a massive collection of forgotten digital doors into cloud environments.
This is not simply a story about developers accidentally publishing secrets. It is a story about credential lifecycle management, excessive privileges, cloud governance, automated discovery, and one of the oldest problems in cybersecurity: organizations often discover that a secret is exposed long after they should have revoked it.
The research highlights an uncomfortable reality for modern businesses. A leaked credential does not become harmless merely because the repository is old, the application was retired, or the employee who created the key has moved to another project.
If the key still works, the risk is still alive.
The Numbers Behind the AWS Credential Exposure
Truffle Security reportedly analyzed hundreds of thousands of AWS secrets discovered across public code repositories, Git history, datasets, Docker images, container registries, and continuous-integration logs.
The researchers identified 431,875 AWS secrets, which were reduced to 64,024 unique AWS keys after eliminating duplicates. Those keys were associated with approximately 50,654 AWS accounts.
The researchers then narrowed the dataset to credentials for which they had sufficient information to perform re-verification. That subset contained 10,616 keys.
The most disturbing finding was that approximately 88% of those credentials continued to authenticate as of August 10.
In other words, exposure did not automatically lead to revocation.
That distinction matters enormously. A credential sitting inside a public repository is a security problem. A credential sitting there and still being accepted by AWS years later is a potentially exploitable access path.
Thousands of Keys Are Not Just Technical Artifacts
An AWS access key can represent much more than a forgotten string of characters.
Depending on the identity and permissions attached to it, a valid key may allow an attacker to interact with cloud resources programmatically. The potential consequences range from accessing sensitive information to manipulating infrastructure, changing configurations, creating resources, or establishing additional persistence.
The danger therefore depends on two variables: whether the credential still works and what it is allowed to do.
A low-privilege application credential is concerning.
A credential connected to an administrator is considerably more serious.
A root access key can be even more dangerous because it belongs to the highest-level identity in an AWS account and is not constrained by normal IAM permission policies in the same way ordinary IAM users are.
The Root Account Problem
Truffle Security identified hundreds of exposed keys associated with companies, including a substantial number of AWS root keys.
The researchers reportedly found 817 exposed keys connected to companies, with 526 associated with AWS root accounts.
Another 242 keys were linked to IAM users with the AdministratorAccess policy.
AdministratorAccess effectively represents extremely broad control over AWS resources. An attacker holding such credentials could potentially interact with a vast portion of the organization’s cloud environment.
This is why credential discovery cannot be treated as a simple “secret scanning” problem.
Security teams need to know not only where a secret appeared, but also who owns it, whether it remains active, what permissions it has, where it was used, and what resources could be affected.
The 768 Keys That Could Mean Full Cloud Control
According to the research, 768 live credentials across two high-risk categories effectively provided full control of a company’s AWS account.
That figure should get the attention of every cloud security team.
Full administrative access can transform a simple credential leak into an infrastructure-level incident.
An attacker could potentially access cloud-hosted data, modify infrastructure, interfere with applications, create new identities, alter security configurations, or deploy unauthorized workloads.
And unlike traditional attacks that may require exploiting a software vulnerability, stolen cloud credentials can sometimes provide attackers with something far more convenient: legitimate authentication.
Valid Credentials Can Look Like Normal Activity
This is one of the most dangerous characteristics of cloud credential abuse.
When attackers exploit a software vulnerability, security teams may have recognizable indicators such as malicious payloads, abnormal requests, exploit attempts, or suspicious processes.
When an attacker uses valid AWS credentials, however, the activity may initially resemble legitimate API traffic.
The attacker does not necessarily need to “break into” the account in the traditional sense.
They can authenticate.
That makes identity monitoring, behavioral analytics, logging, and least-privilege controls essential parts of modern cloud defense.
Hugging Face Emerges as a Major Source of Exposed Keys
The research identified Hugging Face as the largest single source of leaked AWS keys in its dataset, accounting for 8,482 unique key exposures.
This should not automatically be interpreted as a security flaw in Hugging Face itself.
Public developer platforms naturally become places where enormous quantities of code, models, datasets, configuration files, and machine-generated artifacts are shared.
The problem is that developers sometimes publish secrets alongside those artifacts.
An AWS credential may accidentally appear in a dataset, a configuration example, a training artifact, a development script, a notebook, or historical Git content.
Removing the visible credential from the latest version does not necessarily remove it from the historical record.
The Git History Problem
One of the most misunderstood aspects of credential leaks is that deleting a secret from the current version of a repository does not necessarily eliminate it.
Git preserves history.
If a developer commits an AWS key and later removes it, the credential may remain inside earlier commits.
That means security teams cannot simply search the latest version of their repositories.
They need to inspect history as well.
This is particularly important because developers often assume that deleting the offending line means the secret is gone.
From a security perspective, that assumption can be dangerously wrong.
Five Years Old Does Not Mean Safe
Truffle Security found that among the credentials for which creation dates were available, the median age was approximately 1,831 days, or roughly five years.
The oldest reported credential had existed for approximately 17.4 years.
That statistic is astonishing because cloud environments have changed dramatically during that period.
Employees leave.
Projects are abandoned.
Applications are rewritten.
Infrastructure is migrated.
Companies are acquired.
Repositories become inactive.
Yet credentials can survive through all of those changes.
A forgotten key can effectively become a piece of digital infrastructure nobody remembers owning.
Credential Rotation Is Still a Major Weakness
The research reportedly found that only 398 of 2,903 entries, or approximately 13.7%, had a newer access key associated with the same user.
That suggests many credentials had not been rotated.
Credential rotation is one of the simplest security controls organizations can implement, but it is also one of the easiest to neglect.
A key created years ago may still be sitting inside an old build system, a forgotten script, or a developer’s local configuration.
If nobody knows where it is being used, security teams may hesitate to disable it.
That hesitation creates a dangerous cycle: the credential stays active because nobody wants to break something, while its continued existence creates an increasingly serious security risk.
Public Exposure Should Mean Immediate Compromise
One of the strongest recommendations from the research is also one of the simplest:
Any credential committed to a public source should be treated as compromised.
There is no reliable way to know whether someone discovered it.
A secret does not need to be publicly discussed or actively exploited to represent a risk.
Automated scanners, search engines, security researchers, criminal groups, and opportunistic attackers can discover exposed credentials without leaving obvious evidence.
The safest assumption is therefore that a publicly exposed credential has already been seen.
Cloud Attackers Have Plenty of Reasons to Steal AWS Credentials
The potential value of compromised AWS access goes far beyond stealing files.
Attackers can target cloud credentials because they may provide access to computing power, databases, storage, secrets, internal services, CI/CD infrastructure, and application environments.
Cloud accounts can also become valuable resources for cryptomining.
Instead of attacking an organization’s physical machines, criminals can use stolen credentials to deploy workloads into the victim’s cloud environment.
The victim then receives the bill.
Cryptomining Can Turn a Credential Leak Into a Financial Attack
Cryptocurrency mining is an especially interesting cloud abuse scenario because attackers do not necessarily need to steal sensitive information.
They can simply consume resources.
A compromised AWS account with sufficiently powerful permissions may allow an attacker to launch large numbers of compute instances.
The attacker receives the computational benefit.
The organization receives the invoice.
Truffle Security reportedly found that only 262 of 2,754 readable accounts had a budget alert configured.
That is a surprisingly important finding.
Security controls should not stop at authentication and authorization. Organizations also need financial monitoring capable of identifying unusual cloud consumption.
A Stolen Key Can Become a Persistence Mechanism
Another major concern is persistence.
If an attacker gains administrative cloud access, they may attempt to create additional identities or credentials that survive after the original compromised key is revoked.
This creates a critical incident-response lesson.
Revoking the leaked credential is necessary, but it may not be sufficient.
After discovering unauthorized access, organizations should investigate what actions were performed and whether additional credentials, identities, policies, roles, or infrastructure were created.
The goal should be to remove the
The AWS Root Key Should Be Treated Differently
AWS root access keys deserve special attention.
For most organizations, root credentials should not be used for everyday automation or application workloads.
The principle is simple: the
Instead, organizations should use appropriately scoped IAM identities and roles, temporary credentials, and modern workload identity mechanisms wherever possible.
The fewer systems that depend on root credentials, the easier it becomes to protect the account’s ultimate authority.
The Principle of Least Privilege Becomes Critical
The research demonstrates why least privilege remains one of cybersecurity’s most important principles.
If an application only needs access to one S3 bucket, it should not receive administrator privileges.
If a deployment pipeline only needs to update a specific service, it should not receive unrestricted permissions across the entire AWS account.
Every additional permission increases the blast radius of credential theft.
A leaked low-privilege credential can still cause problems.
A leaked administrator credential can become an existential cloud-security incident.
Identity Is Becoming the New Security Perimeter
The traditional concept of a network perimeter is becoming less useful as companies move deeper into cloud infrastructure.
Employees work remotely.
Applications communicate through APIs.
CI/CD systems automatically deploy code.
Developers use third-party platforms.
AI systems interact with cloud services.
Containers and serverless workloads constantly create and destroy infrastructure.
In this environment, identity becomes the control plane.
Who is authenticating?
From where?
Using which credential?
What are they allowed to do?
What did they do immediately afterward?
These questions are increasingly important to cloud security.
Deep Analysis: Safely Auditing AWS Credentials
Security teams should never test exposed credentials against systems they do not own or have permission to assess.
For authorized environments, AWS provides tools that can help identify account identity and inspect credential-related configuration without performing destructive actions.
A basic identity check can be performed with:
aws sts get-caller-identity
This returns information about the identity associated with the currently configured AWS credentials.
For authorized IAM auditing, administrators can inspect users with:
aws iam list-users
Access-key metadata can be reviewed with:
aws iam list-access-keys –user-name USERNAME
Organizations can also inspect credential age and status using:
aws iam get-access-key-last-used –access-key-id ACCESS_KEY_ID
These commands should be executed only against accounts and identities the administrator is authorized to manage.
The goal is not to “try” leaked credentials.
The goal is to determine whether an
Searching Repositories for Secrets
Developers should also introduce secret scanning into the software-development lifecycle.
A basic Git investigation can begin by reviewing repository history:
git log --all --oneline
Organizations can then use approved secret-scanning tools to inspect the repository and historical commits.
The important point is that scanning should happen before code reaches a public repository whenever possible.
Pre-commit scanning is considerably better than discovering a credential after publication.
CI/CD Pipelines Need Credential Hygiene
CI/CD systems are another major area of concern.
Build logs, environment variables, deployment scripts, artifacts, and debugging output can accidentally expose credentials.
Organizations should therefore ensure that secrets are stored in dedicated secret-management systems rather than hard-coded into workflows.
Developers should also avoid printing environment variables during troubleshooting.
A single debugging command can accidentally turn a private credential into a permanent log artifact.
Static Secrets Are Becoming an Architectural Liability
Long-lived access keys are increasingly difficult to justify in modern cloud architectures.
Whenever possible, applications should use short-lived credentials, IAM roles, workload identity, or other temporary authentication mechanisms.
The advantage is straightforward.
If a temporary credential leaks, its useful lifetime is limited.
A credential that survives for five years is a dramatically different security problem.
This is one reason cloud security is gradually moving away from permanent secrets and toward identity-based, short-lived authorization.
Logging Is the Safety Net After Prevention Fails
No security system can guarantee that a credential will never leak.
That makes monitoring essential.
AWS environments should have appropriate logging and alerting configured so organizations can investigate unusual authentication and API activity.
Security teams should pay particular attention to sudden privilege changes, unfamiliar regions, unusual resource creation, unexpected compute consumption, new identities, and access to sensitive storage.
Detection is not a replacement for prevention.
But when prevention fails, good telemetry can significantly reduce the time between compromise and containment.
Budget Alerts Are a Security Control Too
Cloud financial monitoring is often treated as an accounting function.
That is a mistake.
A sudden increase in compute consumption can be an early indicator of credential compromise.
An unexpected spike in storage, networking, database usage, or GPU consumption can also signal abuse.
Budget alerts therefore belong inside the broader cloud-security conversation.
They will not stop an attacker from accessing an account, but they can make malicious resource consumption much harder to hide.
The AI Era Makes Cloud Credentials Even More Valuable
The significance of this problem becomes even greater as organizations build increasingly powerful AI infrastructure.
Modern AI applications can depend on object storage, GPU instances, databases, vector stores, APIs, model repositories, secrets managers, queues, serverless functions, and automated deployment pipelines.
A compromised cloud credential can therefore expose much more than a traditional website.
It may provide a path into an entire AI application stack.
For companies building agentic AI systems, this becomes particularly important because autonomous software can itself interact with cloud resources.
A compromised identity could potentially become the bridge between an attacker and automated infrastructure.
Developers Are Not the Only Ones Responsible
It is tempting to blame developers for leaking credentials.
That approach misses the bigger picture.
Human mistakes are inevitable.
The security architecture should assume that someone will eventually commit a secret.
The important question is what happens next.
Does the repository reject the commit?
Does automated scanning detect the credential?
Is the key automatically revoked?
Does security receive an alert?
Does the credential have minimal privileges?
Does the organization know exactly which workload owns it?
Good security turns an inevitable mistake into a manageable event.
Poor security turns the same mistake into a four-year-old ticking time bomb.
What Organizations Should Do Immediately
Organizations should begin by identifying every long-lived AWS access key currently associated with their environments.
They should then determine which keys are still necessary, which users or applications depend on them, and what permissions each key possesses.
Unused credentials should be disabled or removed.
Exposed credentials should be treated as compromised and rotated immediately.
Root access keys should be eliminated wherever possible.
Administrator privileges should be reduced.
Long-lived credentials should be replaced with temporary authentication mechanisms where practical.
Finally, organizations should establish continuous monitoring rather than relying on occasional audits.
What This Research Really Reveals
The most important lesson is not that thousands of AWS keys have leaked.
Secrets will leak.
The deeper problem is that many organizations appear to lack a reliable mechanism for ensuring that exposed credentials die quickly.
A secret should have a lifecycle.
It should be created for a specific purpose.
It should have limited privileges.
Its usage should be monitored.
It should be rotated.
And when its purpose disappears, it should be revoked.
The fact that some credentials reportedly remained valid for years demonstrates what happens when that lifecycle breaks down.
What Undercode Say:
1. The Real Vulnerability Is Credential Longevity
A five-year-old secret that still works is more frightening than a newly leaked secret.
2. Exposure Is Only Half the Problem
The bigger issue is that the exposed credentials apparently remained usable.
3. Cloud Identity Has Become Infrastructure
An AWS identity can effectively control an
4. Root Keys Should Be Extremely Rare
There is little justification for using the most powerful AWS identity as an everyday application credential.
5. AdministratorAccess Is a Massive Blast Radius
One compromised administrator credential can turn a small mistake into a cloud-wide incident.
6. Git Never Really Forgets
Deleting a secret from the latest commit does not automatically remove it from repository history.
7. Public Repositories Are Permanent Attack Surfaces
Anything published publicly should be considered potentially discoverable.
- Five Years Is an Extraordinary Credential Lifetime
Modern cloud architectures should be moving toward temporary access rather than indefinite credentials.
9. Credential Rotation Needs Automation
If rotation depends entirely on humans remembering to do it, it will eventually fail.
10. Secret Scanning Should Start Before Publication
The best leaked credential is the one that never reaches a public repository.
- IAM Permissions Matter as Much as Credential Exposure
A leaked key with almost no privileges is fundamentally different from a leaked administrator key.
12. Root Credentials Change the Risk Equation
Root access can provide capabilities that ordinary IAM policies do not constrain in the same way.
13. Cloud Security Is Also Financial Security
Cryptomining can turn an identity compromise into a large unexpected bill.
14. Budget Alerts Can Become Early-Warning Systems
Unexpected cloud spending may reveal malicious activity before traditional security alerts do.
15. Valid Authentication Can Evade Simple Detection
Attackers using legitimate credentials may not look like attackers at first.
16. Logs Become Critical After Credential Theft
Security teams need enough telemetry to reconstruct what happened after an exposed key was used.
- Revoking One Key May Not End an Attack
Administrators must investigate whether attackers created additional identities or credentials.
18. Persistence Is a Serious Cloud Threat
An attacker who obtains administrative privileges may attempt to establish another route back into the environment.
19. Least Privilege Limits Damage
Reducing permissions reduces the potential consequences of credential theft.
20. Temporary Credentials Reduce Exposure Windows
Short-lived authentication can dramatically reduce the useful lifespan of stolen credentials.
21. CI/CD Pipelines Deserve Special Attention
Build systems frequently handle powerful credentials and can unintentionally expose them through logs or artifacts.
22. Docker Images Can Preserve Secrets
A credential accidentally embedded into an image can remain accessible even after the original source code changes.
23. Datasets Can Leak Infrastructure Secrets
Public data is not automatically safe simply because it is intended for research or AI development.
24. AI Infrastructure Raises the Stakes
Modern AI systems often depend on extensive cloud infrastructure and privileged APIs.
25. AI Developers Need Cloud Security Discipline
A powerful model cannot compensate for poorly managed credentials.
26. Security Teams Should Track Ownership
Every credential should have a clearly identified owner and business purpose.
27. Orphaned Credentials Are Dangerous
When employees leave or projects disappear, their credentials should not remain active indefinitely.
28. Old Infrastructure Is Often Forgotten Infrastructure
Retired applications can leave behind active credentials and cloud resources.
29. Security Reviews Must Include Historical Data
Searching only current repositories will miss credentials buried in old commits.
30. Developers Need Better Guardrails
Security controls should prevent mistakes instead of simply blaming people after mistakes occur.
31. Cloud Governance Must Be Continuous
An annual audit is not enough for infrastructure that changes every day.
32. Identity Monitoring Should Be Behavioral
Knowing that a credential exists is not enough; teams need to understand how it behaves.
- Unusual Regions Can Be a Warning Signal
Unexpected geographic activity can help identify suspicious credential use.
34. Resource Creation Deserves Attention
New compute instances, databases, users, or roles can indicate unauthorized activity.
- Security and FinOps Need to Work Together
Cloud spending anomalies can provide valuable security signals.
- Public Exposure Should Trigger an Incident Process
Organizations should not wait for evidence of exploitation before responding to exposed credentials.
- The Safest Secret Is a Short-Lived Secret
The less time a credential remains valid, the smaller the window available to an attacker.
- Automation Is the Answer to Human Forgetfulness
Automated detection, rotation, expiration, and alerting can eliminate entire classes of mistakes.
- Cloud Breaches Can Begin With One Line of Code
A single accidental commit can eventually expose an entire infrastructure environment.
40. The Biggest Lesson Is Simple
If an AWS credential has been exposed publicly, assume it is compromised, revoke it, investigate its usage, and move on to stronger identity architecture.
✅ More Than 9,300 Exposed AWS Keys Were Reported as Still Active
The central figure comes from Truffle
The important qualification is that this is a research finding based on the credentials the researchers were able to identify and re-verify, not a claim that every AWS credential exposed worldwide remains active.
✅ 88% Authentication Rate in the Re-Verification Dataset
The reported 88% figure applies to the 10,616 keys for which researchers had complete credentials suitable for re-verification.
It should therefore not be interpreted as saying 88% of all AWS secrets ever exposed online remain valid.
✅ AdministratorAccess Represents Extremely Broad Permissions
AWS
A credential attached to such an identity should therefore be considered highly sensitive and capable of producing a severe blast radius if compromised.
✅ Root Credentials Are Highly Sensitive
AWS root credentials represent the highest level of authority within an AWS account.
AWS security guidance strongly favors protecting the root identity and avoiding root access keys for routine workloads.
⚠️ Public Exposure Does Not Prove Exploitation
Finding a valid credential does not automatically demonstrate that criminals used it.
The security risk is created by the possibility of unauthorized use, which is why exposed credentials should be treated as compromised even without confirmed exploitation.
⚠️ The Hugging Face Figure Requires Context
The reported 8,482 key exposures identifies Hugging Face as a major source within Truffle Security’s dataset.
That number should not automatically be interpreted as evidence that Hugging Face itself caused or generated those leaks; public repositories, datasets, and user-uploaded content can contain secrets accidentally introduced by their creators.
⚠️ Full Control Depends on Credential Permissions
A credential does not automatically provide full AWS control simply because it is exposed.
Full control depends on the identity, policies, permissions, account configuration, and services accessible to that credential.
Prediction
(+1) Cloud Security Will Move Further Toward Short-Lived Identity
The direction of modern cloud security strongly favors temporary credentials, workload identities, role-based access, and automated authentication rather than permanent access keys.
As organizations learn how damaging forgotten credentials can become, long-lived static keys should gradually become less common.
(+1) Secret Scanning Will Become Standard Development Infrastructure
Security scanning is likely to move closer to the beginning of the software-development lifecycle.
Developers will increasingly receive immediate warnings when they attempt to commit AWS keys, API tokens, private keys, or other secrets.
(+1) Cloud Financial Monitoring Will Become Part of Security Operations
Security teams will increasingly treat unexplained increases in cloud spending as potential indicators of compromise.
Cryptomining and unauthorized resource deployment make financial telemetry particularly valuable.
(-1) Forgotten Credentials Will Continue to Create Breaches
Despite better security tools, organizations will continue to accumulate abandoned credentials.
Mergers, employee turnover, legacy applications, rapid cloud adoption, and sprawling development environments make credential lifecycle management difficult.
(-1) AI Infrastructure Could Increase the Impact of Credential Theft
As AI applications consume more compute, storage, GPUs, databases, and APIs, compromised cloud identities could become even more valuable to attackers.
The combination of stolen credentials and high-value AI infrastructure could make future cloud compromises substantially more expensive.
The Bigger Warning for the Cloud Industry
The AWS credential problem exposes a fundamental weakness in modern infrastructure: companies can build extraordinary cloud environments while still relying on surprisingly primitive secrets.
A credential created years ago can outlive the developer who created it, the application it was designed for, and even the team that originally owned it.
That should no longer be acceptable.
Cloud security has reached a point where organizations need to stop asking only, “Where are our secrets?”
They also need to ask:
“Which secrets are still alive?”
“Who can use them?”
“What can they access?”
“When were they last used?”
“Why do they still exist?”
And perhaps most importantly:
“If this credential appeared on the internet tomorrow, how much damage could it cause?”
The answer to that final question should determine how aggressively the credential is protected.
Because a secret that can control an entire AWS account is not merely a password.
It is a master key to a company’s digital infrastructure.
And as this research demonstrates, some of those master keys have been left lying in public for years.
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: www.bleepingcomputer.com
Extra Source Hub (Possible Sources for article):
https://www.linkedin.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
