AWS Engineer Accidentally Exposed Passwords, API Keys, and Confidential Data on Public GitHub

Originally reported by The Register. Source reporting by UpGuard. Original disclosure date: January 2020.

What Happened

On 13 January 2020, cybersecurity firm UpGuard discovered a 954MB public GitHub repository that appeared to belong to an Amazon Web Services (AWS) engineer. The repository contained a broad range of sensitive material that had no business being in a public location, including system credentials, log files, customer correspondence, and internal company documents.

UpGuard notified AWS security within a couple of hours of discovery. The repository was taken offline shortly after, meaning it was publicly accessible for less than five hours in total. AWS subsequently stated that the repository was used by the engineer in a personal capacity and claimed that no customer data or company systems were exposed.

What Was Exposed

According to UpGuard’s report, the repository contained a wide variety of sensitive data, including:

• System credentials: Passwords, AWS key pairs (including one file named rootkey.csv suggesting root-level account access), and private keys.
• Authentication tokens and API keys: For third-party cloud services and providers, including keys for messaging and email services belonging to at least one insurance company client.
• AWS resource templates: Used to provision cloud infrastructure and services.
• Log files: Generated during the second half of 2019, containing hostnames and other operational data.
• Customer correspondence: Exchanges between the engineer and AWS customers.
• Personal identity documents: Including a driver’s license and bank statements, along with the repository owner’s full name — which UpGuard matched to a LinkedIn profile listing AWS as the employer.
• Internal training materials: Documents marked “Amazon Confidential” and resources intended for AWS personnel.

UpGuard noted that the repository was “structured as general storage rather than application code,” with many files in the top-level directory and no consistent subdirectory convention. This suggests the repository was not being used as a version-controlled codebase, but rather as an informal file store — similar in intent, if not in wisdom, to a cloud storage service like Dropbox.

Why Five Hours Is Long Enough

It might be tempting to view a five-hour exposure window as negligible. It is not. Research from North Carolina State University, referenced by UpGuard in their report, found that automated tooling can discover newly committed files containing secrets on GitHub in near real time — capturing approximately 99% of such files shortly after they are pushed. The same researchers estimated that thousands of unique secrets are leaked to GitHub every day.

This means that any credential pushed to a public repository should be treated as immediately compromised, regardless of how quickly it is removed. Rotation of any exposed key, token, or password must be the first response — not the last.

How Credentials End Up on GitHub

This type of incident is not unique to AWS. It is a widespread and well-documented problem across the industry. Common causes include:

• Hard-coded credentials: Developers embed access keys or passwords directly into scripts or configuration files during development and then commit those files without sanitising them first.
• Forgotten repository visibility: Engineers initialise a repository as public by mistake, or forget that an existing repository is public when pushing sensitive files.
• Misuse of GitHub as file storage: As in this case, some users treat GitHub repositories as a convenient file-sharing or backup mechanism rather than as a code versioning system — without recognising the access control implications.
• Missing pre-commit hooks or secret scanning: Without automated checks in the local development workflow, there is no safety net before a push reaches the remote repository.

GitHub’s Existing Safeguards

GitHub operates a token scanning service that monitors public repositories for known credential formats — such as AWS access key patterns, OAuth tokens, and private keys — and alerts affected service providers to enable rapid revocation. GitHub itself advises that any token it sends an alert about should be considered “public and compromised” and rotated immediately.

However, this scanning occurs after the content is already public. Pre-commit or pre-push scanning, either via GitHub’s own push protection features (introduced later) or via third-party tools integrated into a developer’s local environment, provides an earlier line of defence.

Practical Steps to Prevent Secret Leakage

For DevOps engineers and development teams, the following measures significantly reduce the risk of credential exposure via public repositories:

1. Never hard-code credentials. Use environment variables, secrets managers (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault), or dedicated configuration services instead of embedding keys in code or config files.
2. Use .gitignore aggressively. Ensure files likely to contain secrets — .env, *.pem, *credentials*, rootkey.csv — are listed in .gitignore before any code is committed.
3. Install pre-commit secret scanning hooks. Tools such as git-secrets, detect-secrets, or truffleHog can scan staged files for credential patterns before a commit is recorded locally.
4. Audit repository visibility regularly. Periodically review which repositories in your organisation are public. Default new repositories to private.
5. Rotate immediately if exposure is suspected. Do not wait to confirm whether a credential was accessed. Revoke and replace it as soon as any public exposure is identified.
6. Scrub credentials from logs and support data. Internal log files and support tickets that may be shared or stored outside production environments should have credentials redacted at the point of generation.
7. Enable GitHub’s push protection. For repositories on GitHub Enterprise or organisations using Advanced Security, push protection can block commits containing known secret patterns before they reach the remote.

AWS’s Response

An Amazon spokesperson told The Register that the repository was used by the engineer in a personal capacity and that no customer data or company systems were affected. UpGuard’s own conclusion aligned with this, noting no evidence of malicious intent and crediting the rapid detection and remediation with limiting harm.

Nevertheless, the breadth of material in the repository — credentials, internal training documents marked confidential, customer correspondence, and personal identity documents — illustrates how quickly an individual’s poor security hygiene can create significant organisational risk, even when the outcome is ultimately contained.

Key Takeaway

This incident is a clear illustration that secrets management is not a problem only for large, complex pipelines. A single engineer storing files in the wrong place — or using a public GitHub repository as informal cloud storage — can expose credentials with root-level cloud access, customer data, and confidential employer materials in one push. The tooling to prevent this exists and is widely available. The gap is almost always process and habit, not capability.