Listen to this Post
A Cloud Security Warning That Is Hard to Ignore
Cloud security failures do not always begin with a sophisticated zero-day or an elaborate ransomware campaign. Sometimes, the most dangerous weakness is much simpler: an access key that someone forgot to delete.
A large-scale investigation by Truffle Security has uncovered 768 publicly exposed, still-active AWS credentials capable of granting full administrative control over business cloud environments. The findings include 526 root access keys and 242 IAM user keys carrying AWS’s AdministratorAccess permission.
The discovery highlights one of the oldest problems in cybersecurity: secrets rarely disappear simply because developers delete the file where they were originally exposed.
A credential committed to Git can be copied into another repository. It can appear inside a Docker image, a package, a dataset, a CI/CD log, an AI-training corpus, or a public archive. Years later, an attacker may still find it—and if the credential remains valid, the original mistake suddenly becomes a live security incident.
The most troubling part of this research is not merely the number 768.
It is the age of some of the credentials, the weakness of rotation practices, and the evidence that certain keys had apparently been known to AWS as compromised while continuing to authenticate.
The 768 Keys That Still Worked
Truffle Security reviewed publicly exposed AWS credentials and re-verified thousands of them on August 10, 2026.
From a broader dataset containing 431,875 publicly identified findings, researchers identified 64,024 unique AWS access-key pairs that had been exposed publicly.
Of those, 10,625 were root credentials, representing approximately 16.6% of the unique key pairs.
The researchers then examined a subset of 10,616 AWS key pairs and found that approximately 88% still authenticated successfully.
That is a remarkable statistic.
It means that public exposure does not necessarily lead to immediate credential invalidation. In many environments, the key remains alive until someone notices the problem and actively rotates or revokes it.
Why Root Keys Are So Dangerous
An AWS root credential is not an ordinary cloud password.
The root user represents the highest level of authority within an AWS account. Unlike an IAM identity, it is not simply another user whose permissions can be narrowed through ordinary IAM policy design.
If an attacker obtains valid root credentials, the consequences can be severe.
They may be able to change security settings, manipulate billing information, create or modify identities, access sensitive infrastructure, delete resources, interfere with logging, and potentially disrupt the entire cloud environment.
In the wrong hands, a root key can turn a single leaked secret into an account-wide compromise.
AdministratorAccess Creates Another Critical Path
The danger does not end with root credentials.
The investigation also identified 242 IAM user keys associated with AWS’s AdministratorAccess permission.
That policy effectively gives an identity extremely broad control across an AWS environment.
For an attacker, such credentials can be almost as valuable as finding a master key.
An adversary who obtains them could potentially deploy virtual machines, access storage, create users, alter networking, modify security controls, extract data, establish persistence, and consume expensive cloud resources.
The distinction between “root” and “administrator” therefore should not create a false sense of safety.
Both represent extremely high-impact credentials.
Public Git History Is Only the Beginning
The credentials did not come from a single source.
Researchers found exposed secrets across publicly accessible Git histories, Hugging Face datasets, Docker images, package registries, and CI/CD logs.
That diversity matters because modern software development creates an enormous number of places where secrets can accidentally travel.
A developer might accidentally commit an .env file.
A build system might print an environment variable into a log.
A container image might preserve a secret inside an earlier layer.
A public dataset might contain a copy of source code that originally contained credentials.
Even after the original repository is cleaned up, copies may continue to exist elsewhere.
Hugging Face Highlights a New Dimension of Secret Exposure
Hugging Face emerged as one of the largest individual sources in the research.
The investigation reportedly identified 8,482 unique live AWS keys across 3,394 public datasets, with root credentials representing approximately 17.9% of those credentials.
The connection to AI development is particularly important.
Public datasets increasingly contain source-code collections, development artifacts, repositories, documentation, logs, and other material used for machine-learning research and software development.
Once a secret becomes part of such a dataset, its distribution can become difficult to control.
A developer may download the dataset.
A researcher may mirror it.
Another dataset may be created from it.
A model-training pipeline may ingest it.
The original repository owner could delete the credential years earlier and still have no practical way of knowing how many copies survived.
Deleted Does Not Mean Destroyed
This is one of the most important lessons from the investigation.
Deleting a secret from a current Git branch does not necessarily remove it from Git history.
Deleting a public repository does not guarantee that someone else did not clone it.
Deleting a dataset does not guarantee that copies do not exist.
Deleting a Docker tag does not mean older image layers vanished.
Deleting a package does not necessarily erase caches and mirrors.
In cybersecurity, the safer assumption is simple:
Once a credential becomes public, treat it as permanently compromised.
The correct response is revocation or rotation—not hoping that nobody noticed.
Some Leaked Keys Were Years Old
The age of the credentials makes the situation even more concerning.
Among 2,903 keys for which researchers could determine creation dates, the median live leaked key was approximately 1,831 days old, or roughly five years.
The oldest identified credential was approximately 17.4 years old.
That finding changes the story.
This is not simply about developers making mistakes yesterday.
It is also about organizations carrying forgotten secrets forward for years.
Old automation accounts, abandoned applications, experimental environments, legacy deployments, and forgotten CI/CD systems can quietly preserve credentials long after the people who created them have moved on.
The Rotation Problem Is Massive
Only 398 of the 2,903 enumerable keys had a newer credential associated with the same IAM user.
That means approximately 86% had apparently never been superseded, rotated, or removed.
Credential rotation is often discussed as a basic security practice, but this research demonstrates why it matters.
A leaked key is dangerous.
A leaked key that remains valid for five years is dramatically worse.
A leaked administrative key that remains valid for five years is effectively a standing invitation for attackers who eventually discover it.
AWS Had Already Flagged Some Credentials
One of the most uncomfortable details is that AWS had apparently identified many of the exposed credentials as compromised.
Researchers found 929 active IAM user keys subject to AWS’s AWSCompromisedKeyQuarantine policy.
That policy is intended to restrict credentials after AWS detects evidence that they have been exposed.
Even more concerning, 112 keys were associated with an older version of the quarantine policy that AWS stopped issuing in 2023.
Those credentials appeared to have been flagged years earlier while still authenticating when researchers tested them.
This raises a critical operational question:
What happens inside an organization after AWS warns that a credential has been compromised?
A detection mechanism is valuable only when somebody acts on the detection.
768 Business Credentials With Administrative Power
The investigation identified 817 active keys linked to businesses.
Of those, 768 reportedly enabled full administrative control.
The affected organizations were concentrated in software, cloud services, and IT consulting.
One global consultancy reportedly had 19 leaked keys distributed across separate AWS accounts.
That demonstrates another important risk: cloud environments are increasingly interconnected.
A single compromised account may not remain an isolated problem.
It can become the starting point for attacks against production systems, development infrastructure, customer environments, third-party services, or organizational cloud networks.
AWS Organizations Raises the Stakes
Researchers also identified 130 live root keys associated with AWS Organizations management accounts.
This deserves special attention.
An AWS Organizations management account can have visibility and authority affecting multiple member accounts.
Consequently, compromising the root credentials of such an account can have consequences far beyond a single workload.
The blast radius could potentially span an entire cloud estate.
That is why organizations should treat management-account credentials as some of their most sensitive secrets.
Cloud-Billing Fraud Is a Realistic Threat
Attackers do not always steal data immediately after obtaining cloud credentials.
Sometimes, they monetize access differently.
Compromised AWS credentials can be used to launch resource-intensive workloads, including cryptocurrency mining.
An attacker may create large numbers of compute instances, consume GPU resources, deploy unfamiliar services, or generate massive amounts of network traffic.
The victim then receives the bill.
Cloud abuse can therefore become both a cybersecurity incident and a financial incident.
Budget alerts and anomaly detection should be considered part of the defensive strategy—not merely an accounting convenience.
The AI Era Makes Credential Persistence Worse
The connection between public datasets and exposed AWS credentials deserves broader attention.
Modern AI systems depend heavily on massive collections of public and semi-public data.
Code repositories, package archives, documentation, configuration files, datasets, container images, and development artifacts can all become part of this ecosystem.
That means a secret leaked today may continue circulating long after its original context disappears.
The problem is not necessarily that an AI model will directly “remember” a particular credential.
The larger issue is that the surrounding data ecosystem creates many additional copies of historical software artifacts.
The more copies exist, the harder it becomes for organizations to guarantee that a deleted secret has truly disappeared.
Deep Analysis: How Attackers Could Exploit an Exposed AWS Key
The most dangerous scenario begins when an attacker discovers a valid access-key pair.
A typical AWS credential consists of an access key ID and a secret access key.
An attacker can test whether a credential is active without immediately modifying infrastructure.
For defensive validation, security teams can inspect the identity associated with credentials using:
aws sts get-caller-identity
This is one of the first commands defenders can use after discovering a potentially compromised AWS credential.
Checking the Current AWS Identity
A security engineer can verify the active identity with:
aws sts get-caller-identity –output json
The response can help determine which AWS account and identity are associated with the configured credentials.
This should be performed in an authorized environment and never against credentials that do not belong to the organization performing the investigation.
Inspecting IAM Access Keys
For an authorized IAM user, defenders can review access keys with:
aws iam list-access-keys –user-name USERNAME
The goal is to identify old credentials, determine which keys remain active, and establish whether a credential should still exist.
Rotating a Compromised Key
Once a credential is confirmed as exposed, the safest response is to disable or remove it and replace it with a properly managed credential.
For an authorized IAM user, a key can be deactivated with:
aws iam update-access-key
–user-name USERNAME
–access-key-id ACCESS_KEY_ID
–status Inactive
Organizations should then replace the credential through their approved secret-management and deployment process.
Searching Repositories for Exposed Secrets
Security teams can also scan their own repositories for AWS credential patterns.
A basic defensive search might include:
git grep -nE 'AKIA[0-9A-Z]{16}'
For historical exposure, however, scanning only the current working tree is insufficient.
Teams should examine Git history, branches, tags, forks, build artifacts, container layers, CI/CD logs, and other locations where historical secrets may remain.
Investigating Suspicious Cloud Activity
After discovering an exposed administrative credential, defenders should assume that unauthorized use is possible until proven otherwise.
CloudTrail should be examined for unusual API activity, unfamiliar IP addresses, unexpected regions, new IAM users, policy changes, security-control modifications, unusual compute launches, and suspicious data-access operations.
A useful investigation question is not simply:
Was this key leaked?
It is:
“Was this key used after it could have been obtained by an attacker?”
That distinction determines the potential severity of the incident.
The Right Response to a Public Secret
Organizations should avoid spending hours debating whether an exposed credential is “probably harmless.”
If a secret is public, treat it as compromised.
The response should generally include:
Disable or revoke the exposed credential.
Issue a replacement where necessary.
Identify the affected AWS account and identity.
Review CloudTrail and other relevant telemetry.
Search for persistence mechanisms created through the credential.
Check for unexpected resources and billing anomalies.
Review IAM changes.
Search repositories and artifacts for additional secrets.
Determine how the credential became public.
Fix the process that allowed the exposure.
The objective is not merely to close the original hole.
It is to prevent the same class of mistake from happening again.
Root Access Keys Should Be Eliminated
AWS root access keys represent an unnecessary and exceptionally dangerous credential type for most organizations.
The better architecture is to avoid using root credentials for routine operations and instead rely on controlled identities, short-lived credentials, strong authentication, and narrowly scoped permissions.
The principle should be straightforward:
The fewer permanent credentials an organization has, the fewer permanent secrets an attacker can steal.
Long-Lived IAM Keys Are Another Weak Point
Permanent access keys should not become the default architecture for modern cloud environments.
Where possible, organizations should use temporary credentials, workload identities, roles, federation, and automated credential issuance.
Short-lived credentials dramatically reduce the useful lifetime of stolen authentication material.
Even if an attacker obtains a credential, its value decreases when the credential expires automatically.
Secret Scanning Must Start Before Deployment
Secret scanning should not be treated as a final-stage security feature.
It belongs inside the developer workflow.
Repositories should be scanned before commits are accepted.
CI/CD pipelines should scan artifacts and configuration.
Container images should be inspected.
Package publication workflows should detect secrets.
Cloud environments should continuously monitor for credential exposure.
The earlier the secret is detected, the smaller the potential blast radius.
Organizations Need Better Credential Inventory
You cannot rotate credentials you do not know exist.
This sounds obvious, yet the age of the leaked keys demonstrates how difficult inventory management remains in large environments.
Security teams should maintain visibility into:
IAM users
Access keys
Root credentials
Service accounts
CI/CD identities
Workload roles
Cloud automation
Third-party integrations
Development accounts
Legacy environments
Every credential should have an owner, purpose, lifecycle, and expiration strategy.
The Five-Year Credential Is a Security Failure
A five-year-old active credential discovered publicly is not merely an individual developer’s mistake.
It is evidence of a lifecycle-management problem.
Organizations need processes that automatically identify unused credentials and force periodic review.
A credential that has not been used for months should not quietly remain privileged forever.
A credential that has been exposed publicly should not require a human to remember to rotate it.
Automation should make the secure action the default action.
What Undercode Say:
The 768 active administrative AWS keys are a warning about identity lifecycle management, not simply a warning about GitHub leaks.
The most disturbing number may actually be the age of the credentials.
A secret surviving for five years tells us that the security problem continued long after the original mistake.
The 17.4-year-old credential is even more revealing.
Modern cloud infrastructure moves at extraordinary speed, but identity systems can remain frozen in the past.
Organizations routinely decommission applications while leaving their credentials behind.
Developers leave teams while their service accounts remain active.
Projects disappear while automation credentials continue functioning.
Cloud accounts grow while nobody maintains a complete inventory of their identities.
This creates what could be called a credential archaeology problem.
Attackers increasingly do not need to break into modern infrastructure directly.
They can search through the digital fossils left behind by organizations.
Public Git history is one fossil layer.
Container registries are another.
Package repositories create another.
Public datasets create another.
Cached CI/CD artifacts create another.
The AI ecosystem adds yet another layer because enormous collections of public software data are being continuously copied, transformed, analyzed, and redistributed.
This means organizations should stop thinking about a secret as a single piece of text.
A secret is a piece of information capable of reproducing itself across digital systems.
Once exposed, it can become part of an ecosystem of copies.
That is why deleting the original file is not remediation.
Revocation is remediation.
Rotation is remediation.
Incident investigation is remediation.
Preventing recurrence is remediation.
Another major concern is the enormous authority attached to the exposed credentials.
An attacker who obtains a low-privilege API key may still face meaningful limitations.
An attacker who obtains AdministratorAccess faces dramatically fewer obstacles.
An attacker who obtains a root key may inherit the highest possible level of control over the account.
This demonstrates why least privilege remains one of the most important principles in cloud security.
A credential should have exactly the permissions required for its job.
Nothing more.
The investigation also reinforces the importance of temporary authentication.
Long-lived secrets are attractive targets because they can remain useful for months or years.
Temporary credentials change the economics.
If the credential expires automatically, the
🕵️📝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: cyberpress.org
Extra Source Hub (Possible Sources for article):
https://www.pinterest.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
