CISA leaked AWS GovCloud credentials on GitHub for 6 months

The American agency responsible for defending US critical infrastructure against cyberattacks leaked its own credentials on GitHub — and they stayed publicly accessible for six months. The repository was discovered on 15 May 2026 by Guillaume Valadon, a researcher at the firm GitGuardian, who notified CISA. The story became public via Krebs on Security days later, prompting an immediate reaction from the US Congress.

What was in the repository

The public repository was called “Private-CISA” — the name alone says everything about the level of control applied. It was maintained by an employee of Nightwing, a contractor based in Dulles, Virginia. It had been accessible since 13 November 2025 until it was removed on 18 May 2026: 184 days of exposure.

Across 844 megabytes of data there were:

• Administrator credentials for three AWS GovCloud accounts — the government clouds that host sensitive CISA systems
• Plain-text passwords for dozens of internal systems, stored in a CSV file
• SSH keys and Kubernetes configuration files
• GitHub Actions workflows
• A private RSA key with access to every CISA-IT code repository
• Detailed documentation of internal build and deploy processes

To put that in perspective: CISA coordinates the cyber defence of all American critical infrastructure — power plants, health systems, electoral networks. Anyone with access to that repository had, potentially, access to the pipeline that produces the tools protecting those systems.

The technical mistake behind the leak

It wasn’t a sophisticated exploit or a zero-day. The contractor manually disabled the default GitHub setting that blocks the publication of secrets and keys in public repositories — the secret scanning feature that any account has enabled by default.

The result is what the security community calls static secrets: credentials stored as plain text in versioned files, rather than managed by a dedicated vault. OWASP has listed poor secrets management among the most common failures in software development for years. The difference here is who made the mistake and what the target was.

The response that came late

After receiving GitGuardian’s notification on 15 May, CISA took the repository down three days later. But revoking credentials wasn’t quite so fast:

• Some AWS GovCloud keys carried on working for 48 hours after the repository was removed
• The private RSA key went unrevoked for at least five days after CISA received the first notification

That matters because any actor who had cloned the repository before its removal would still have valid access for days. The exposure doesn’t end when the repository is made private — it ends when each individual credential is revoked and replaced.

Congress asked for explanations

Lawmakers from both chambers of Congress sent formal demands to the agency. The central question isn’t just the contractor’s mistake: it’s how an AWS GovCloud administrator key ended up in a CSV in a public repository without a single detection system raising an alert in the preceding 184 days.

CISA is the same agency that publishes hardening guidance for the rest of the US government. The obvious question the lawmakers are asking is: if you don’t follow it, why should anyone else?

What any team can take from this

This case is instructive because the mistake is simple and the impact is maximal. A few practices that would have prevented the leak:

1. Never store credentials in plain text
Passwords in a CSV, tokens in committed .env files, keys straight in the code — all of that needs to go into a secrets manager. AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, or Bitwarden Secrets Automation for smaller teams. The rule is simple: if it’s a secret, it doesn’t go in the repository.

2. Don’t disable secret scanning
GitHub offers automatic secret detection in public and private repositories. Disabling that function in a government environment is the equivalent of switching off the smoke detector before lighting the fire. In corporate environments, consider complementary tools such as Gitleaks or TruffleHog in the CI pipeline.

3. Rotate credentials regularly
Keys that stay active for months without rotation are a risk even without an active leak. With a leak, they’re an open window. The general rule is: the more privileged the credential, the shorter its lifetime should be.

4. Audit what contractors publish
Nightwing is a third party. A DLP (Data Loss Prevention) policy applied to third-party code would have caught the publication before Valadon found the repository. Contractors with privileged access need controls equivalent to internal staff.

The bigger lesson isn’t that governments are incompetent — it’s that static secrets are a structural problem affecting organisations of any size, from the startup to the federal government. What changes is the cost of the mistake.

If you manage infrastructure, it’s worth understanding how Windows audit logs can detect unauthorised access before the damage spreads. To see how compromised build pipelines become an attack vector, the JDownloader case is a recent and direct example. And if your team uses GitHub as an internal code repository, the VS Code extension attack on GitHub shows how much one slip in a repository can cost.