In 2021, a developer at a mid-size software company in Bengaluru was building a data pipeline late one night. The pipeline needed to connect to Amazon S3, the company’s cloud storage. The fastest way was to hardcode the AWS credentials directly into the script. He would replace them with environment variables in the morning. He pushed the commit.
In the morning, a new feature took priority. The credential replacement never happened.
Two years later, the developer changed jobs. Nobody rotated the AWS keys because nobody remembered they were there. The repository was made private at some point, but doing so does not remove its commit history. The credentials sat in that history, technically inaccessible to the public but never revoked.
In 2024, the company migrated to a new cloud architecture. The old scripts were archived. Nobody audited which credentials were still active.
As of August 10, 2026, that AWS key still authenticated successfully.
This is not a hypothetical. This is the documented pattern behind one of the most significant cloud security research findings of 2026.
Truffle Security has been tracking AWS credential exposure for four years. Their latest research found more than 9,300 Amazon Web Services access keys publicly exposed between August 2022 and August 2026 that are still active and valid. Of the 10,616 keys with complete credentials available for verification, 88% continued to authenticate as of August 10, 2026.
88%. Not a small fraction of careless organisations. 88% of exposed credentials still working, years after they were made public.
What Was Actually Found and Where
The scale of this research is worth reading slowly.
Truffle Security found 431,875 AWS secrets across code repositories, Git history, datasets, Docker images, registries, and CI logs. After removing duplicates, they extracted 64,024 unique AWS keys corresponding to 50,654 AWS accounts.
The locations where credentials are leaking tell a specific story about how cloud security fails in practice. Code repositories are the most obvious, but not the only source. Git history captures commits that were later deleted or made private. Docker images contain environment variables and configuration files that were included during builds. CI and CD logs, the automated build and deployment records from platforms like GitHub Actions and Jenkins, capture environment variables that were printed during pipeline runs. Datasets on AI platforms are an emerging source because data scientists frequently include credentials in notebooks and scripts that they share publicly.
Hugging Face, the popular AI model and dataset sharing platform, was the largest single source of leaked AWS keys, accounting for 8,482 unique key exposures. Of those, 17.9% were root keys, meaning the highest privilege AWS identity with no restrictions.
This is directly connected to the story we told about the OpenAI and Hugging Face breach in July. The same platform that was autonomously attacked by an AI model is also the platform through which thousands of AWS credentials have been publicly exposed by developers sharing AI training scripts and notebooks.
The breakdown of what these keys actually control is what makes this finding exceptional rather than routine.
Of the 817 keys linked to companies, 526 were AWS root keys. 242 keys were associated with IAM users with the AdministratorAccess policy. This role has full permissions to create, modify, delete, and view virtually all AWS services and resources within an account.
Truffle Security notes that each of the 768 live keys in two verified sets gives full control of a company’s AWS account.
Full control means exactly that. The attacker who holds one of these keys can read every file in every S3 bucket. They can access every database. They can shut down every running server. They can create their own administrator accounts for persistent access that persists even after the original exposed key is eventually revoked. They can deploy cryptomining software, generating enormous cloud bills on the victim’s account. They can delete all backups.
The Age of These Keys Is the Most Disturbing Finding
The research does not just show that credentials were exposed. It shows how long they have been sitting there, unrotated and unrevoked.
For the 2,903 keys with available creation dates, the median age was 1,831 days, approximately five years. The oldest key had existed for 17.4 years. Only 398 of those entries, 13.7%, had a newer access key associated with the same user, suggesting most had never been rotated.
A five-year median age means the average exposed credential was created around 2021. It has survived multiple employee tenures. It has survived multiple security audits. It has survived the migration to new cloud architectures. It has survived whatever incident response procedures these companies have. It is still working.
The 17.4-year-old key was created in 2008 or 2009. AWS launched in 2006. Someone created an access key in the earliest days of cloud computing, and that key has been sitting, potentially exposed, for nearly two decades without being rotated.
This is not about negligence in a single moment. It is about the absence of any systematic process for managing the lifecycle of cloud credentials. You cannot leave something unrotated for five years if you have a working key rotation programme. You cannot have a 17-year-old key if anyone is auditing active credentials regularly. These findings represent the cumulative consequence of credential management being treated as something that happens once at provisioning and never revisited.
How AWS Credentials End Up in Public Places
Understanding the exposure vectors is essential for knowing what to audit and what to prevent.
- Hardcoded credentials in source code. A developer needs to test a connection to S3. The fastest approach is to put the key directly in the code. This is so common that AWS’s own documentation explicitly warns against it. The credential gets committed. The repository eventually becomes public, or is shared, or is uploaded to a code-sharing platform. The credential is now publicly accessible.
- Git history that outlives the commit. Developers frequently realise they have committed a credential and delete it in a follow-up commit. But deleting a file in Git does not remove it from history. The credential exists in every prior commit and is accessible to anyone who clones the repository and looks at the history. Making the repository private after this has happened does not help if anyone accessed the repository while it was public. The credential must be revoked.
- Docker images with embedded credentials. AWS credentials are sometimes embedded in Docker images during the build process, whether through environment variables, configuration files, or build arguments. When those images are pushed to public registries like Docker Hub, the credentials travel with them and can be extracted by anyone who pulls the image.
- CI and CD pipeline logs. Automated build systems frequently print environment variables during pipeline runs for debugging purposes. If those logs are accessible, even temporarily, the credentials they contain can be captured. GitHub Actions, Jenkins, CircleCI, and other CI platforms have all been sources of credential leakage through log exposure.
- AI model and dataset repositories. This is the emerging vector that Hugging Face’s position at the top of Truffle Security’s findings reflects. Data scientists sharing model training scripts, Jupyter notebooks, and dataset processing code on AI platforms frequently include cloud credentials for accessing training data stored in S3. The credential is included for convenience and often not removed before sharing.
What an Attacker Does With Full AWS Administrator Access
Full control of a company’s AWS account could allow an attacker to access, exfiltrate, or wipe cloud-hosted data, take control of servers and applications, and create rogue admin accounts for persistent access.
The sequence of a sophisticated attacker who obtains full AWS administrator access through an exposed key follows a predictable pattern.
First, enumeration. Before taking any visible action, the attacker maps what exists in the account. Every S3 bucket and its contents. Every running EC2 instance. Every database. Every Lambda function. Every IAM user and their permissions. This enumeration is quiet and generates logs that look like normal API activity.
Second, data exfiltration. The attacker identifies the most valuable data in the account and copies it to an external location. Customer records. Intellectual property. Financial data. Backup archives. This can be done without disrupting any running services. The victim continues operating normally while their data leaves.
Third, persistence. The attacker creates new IAM users with administrator access under names that look like service accounts. These accounts survive even after the original exposed key is eventually discovered and revoked. The attacker remains inside the account.
Fourth, optional disruption or monetisation. Depending on the attacker’s objective, they may deploy cryptomining software, encrypt resources for ransom, or simply delete backups and critical data to maximise leverage.
Truffle Security found that only 262 of 2,754 readable accounts had a budget alert set up.
This means that in most cases, the cryptomining deployment that generates a ₹40 lakh cloud bill in a single week would not trigger an alert until the bill arrived at the end of the month. By then, the attacker has had weeks of free compute at the victim’s expense.
Why This Is a Specific and Urgent Problem for Indian Companies
Indian companies are among the fastest-growing adopters of AWS globally. The startup ecosystem, the IT services sector, and the enterprise digital transformation wave have all pushed significant Indian workloads onto AWS infrastructure over the past decade.
That adoption curve maps directly onto the credential exposure risk. A company that has been using AWS since 2018 has had eight years during which developers may have committed credentials, shared notebooks, built Docker images, and run CI pipelines. Any credential from any of those activities that ended up in a public location and was never rotated is a potential entry point today.
The five-year median age of exposed keys in Truffle Security’s research means that the keys most at risk were created during the 2019 to 2022 period, which corresponds precisely to the period when many Indian companies were making their most significant moves to cloud infrastructure. Lockdown-era remote development practices, accelerated digital transformation timelines, and the rush to build data science and AI capabilities all increased the likelihood of credential exposure during exactly this window.
The DPDP Act creates a specific additional obligation here. If an attacker uses an exposed AWS key to access an Indian company’s cloud environment and reads or exfiltrates personal data, that is a personal data breach with notification obligations under Indian law. The company whose developer committed a credential to GitHub in 2021 is the Data Fiduciary responsible for notifying the Data Protection Board if that credential enabled access to customer data in 2026.
Eight Actions Every CTO Must Take This Week
These are the specific actions Truffle Security recommends, with additional context for implementation.
1. Delete all AWS root access keys immediately.
AWS root credentials are the master keys to the entire account. There is almost no operational scenario that requires a root access key for programmatic access. AWS best practice has been to delete root access keys and use IAM roles instead since at least 2014. If your organisation still has active root access keys, that is a documented misconfiguration. Delete them. Use the root account only for the specific AWS console tasks that require it, and only with multi-factor authentication enabled.
2. Audit every IAM access key by age.
Pull a full list of all IAM access keys across your AWS accounts using the AWS IAM credential report. For every key, note the last used date and the age. Any key that has not been used in 90 days should be deactivated and scheduled for deletion. Any key older than 90 days that is still in active use should be evaluated for rotation. Any key older than one year with no rotation history is a compliance finding regardless of whether it has been exposed.
3. Search your code repositories and Git history for committed credentials.
Tools like Truffle Security’s own TruffleHog, GitLeaks, and Amazon’s own CodeGuru Secrets are designed specifically for this. Run them against every repository your organisation manages, including archived repositories, and specifically including the complete Git history, not just the current state of the code. Any credential found in history must be treated as compromised and revoked immediately, regardless of whether you can confirm it was ever accessed.
4. Scan Docker images for embedded credentials.
Use credential scanning tools against your Docker image library before pushing images to any registry. Review existing public images for embedded environment variables and configuration files. AWS credentials embedded in a public Docker image have been accessible to anyone who ever pulled that image.
5. Audit CI and CD pipeline log retention and access.
Review whether your CI pipelines are logging environment variables. Check whether those logs are accessible to anyone outside your engineering team. Implement log redaction for credentials in CI pipeline outputs. Review log retention policies to ensure historical logs containing credentials are purged.
6. Implement automated secrets detection in your development workflow.
Pre-commit hooks that scan for credential patterns before code can be committed to a repository catch the most common exposure vector before it happens. Integrate secrets scanning into your CI pipeline as a mandatory step that fails the build if any credential pattern is detected. AWS has published guidance on this, and there are multiple open-source and commercial tools available.
7. Set up AWS budget alerts on every account.
Only 262 of 2,754 readable accounts in the research had a budget alert configured. A cryptomining deployment on your AWS account will generate anomalous charges within hours. A budget alert that notifies you when spend crosses a defined threshold is a detection mechanism for this specific attack type. Set alerts at both a threshold that reflects normal monthly spend and an anomaly threshold that triggers if daily spend suddenly increases.
8. Enable AWS CloudTrail across all regions and review API activity.
CloudTrail logs every API call made to your AWS account. If a credential has been used by an unauthorised party, CloudTrail will show it. Review CloudTrail logs for API calls from unusual IP addresses, at unusual hours, for unusual services, or for the specific actions associated with enumeration and data exfiltration: ListBuckets, GetObject, CreateUser, AttachUserPolicy.
The Connection to Every Other Breach We Have Covered This Year
This research does not exist in isolation. It connects directly to the pattern of incidents we have been documenting across Indian organisations in 2026.
The Bank of Baroda breach came through a compromised email credential. The CDSL breach came through an admin account with a non-expiring password. The Kudankulam contractor breach came through inadequate security controls on a commercial data server. The OpenAI Hugging Face incident came through exposed credentials across four services. Bank of Baroda acknowledged that the same Hugging Face platform that is now confirmed as the largest source of leaked AWS keys was the environment where their OpenAI breach originated.
The thread connecting all of these incidents is the same. Credentials that were created, shared, or exposed in the past are still working in the present. The five-year median age of exposed AWS keys is the cloud security version of the non-expiring password that CDSL created in 2021 and never rotated until the ransomware attack forced the issue.
The lesson from every incident this year is consistent. Credentials accumulate. They outlive the circumstances in which they were created. They outlive the people who created them. They outlive the systems they were created for. And unless there is an active, systematic programme for finding and revoking them, they sit quietly in repositories and history files waiting for the scanner that eventually finds them.
Truffle Security’s scanner found 9,300 of them this month. The question every CTO reading this needs to answer is how many their own scanner would find.
Final Thought
The developer who hardcoded that AWS key in 2021 was not being reckless. They were solving a problem under time pressure with the fastest tool available. This is how most credentials end up in code. Not through negligence but through exactly the kind of pragmatic decision-making that development teams make dozens of times every day.
The failure is not in the individual decision. It is in the absence of the systems that would have caught it. A pre-commit hook that blocks credential commits. A post-commit scanner that would have flagged it the same day. A key rotation policy that would have revoked the credential within 90 days. A quarterly IAM audit that would have identified unused and potentially exposed keys. Any one of these would have changed the outcome.
The 9,300 exposed keys that Truffle Security found represent 9,300 cases where none of those systems existed or worked. Each of them is a company that has given an unknown attacker the same access as their most senior cloud administrator, possibly for years, without knowing it.
The audit starts with a single command. The cost of not running it is somewhere in that list of 9,300.
At Skeletos IT Services, we help Indian companies build the cloud security practices that prevent credential exposure, detect it when it occurs, and respond to it before an attacker acts. From DevSecOps implementation to cloud access key audits to ongoing credential monitoring, we build the programme that makes the individual developer’s pragmatic choice survivable. If you want to understand what your current AWS credential posture looks like and whether any of your keys appear in public exposure databases, we can help you find out.
Note: This blog is based on research published by Truffle Security on August 21, 2026, as reported by BleepingComputer. All statistics are sourced directly from the Truffle Security research report. AWS’s official response to the findings is quoted from the BleepingComputer article. This blog is for awareness and educational purposes. Consult your cloud security team for organisation-specific guidance.
