A contractor working for the U.S. Cybersecurity and Infrastructure Security Agency left a public GitHub repository named Private-CISA exposed for roughly six months — and it amounted to a near-complete keyring for the agency’s internal infrastructure. Security journalist Brian Krebs broke the story on May 18; follow-up reporting through this week has confirmed the scope, and at least one set of exposed AWS keys reportedly stayed valid for 48 hours after CISA was notified.
If you run cloud infrastructure, this is worth five minutes of attention — not for the irony of it happening to CISA, but because every failure mode here is one you can check for in your own environment before lunch.
What was exposed
The Private-CISA repository was created on November 13, 2025 and remained publicly reachable until mid-May 2026. Despite the name, nothing about it was private. Among the files researchers found:
importantAWStokens— administrative credentials for three AWS GovCloud accounts. The keys reportedly authenticated at a high privilege level.AWS-Workspace-Firefox-Passwords.csv— a browser password export listing plaintext usernames and passwords for dozens of internal CISA systems. One of them,LZ-DSO, appears to be the agency’s “Landing Zone DevSecOps” environment — its secure software build pipeline.- Plaintext credentials to CISA’s internal Artifactory instance, the package repository that feeds the agency’s software builds.
Translated into impact: an attacker who found this repo had administrative cloud access, a path into the DevSecOps landing zone, and the keys to the artifact repository that supplies build dependencies. That last item is the supply-chain nightmare — write access to an internal Artifactory lets an attacker poison packages that every downstream build silently consumes.
How it happened
None of this required a vulnerability. It required a sequence of ordinary mistakes.
The contractor used trivially guessable passwords — many reportedly followed the pattern of the platform’s name plus the current year. The repo’s commit history shows GitHub’s secret scanning push protection was deliberately disabled, which is why dozens of high-entropy strings never tripped an alert on upload. And the credentials were committed in cleartext rather than referenced from a secrets manager.
The 48-hour validity window after disclosure is its own lesson. Detection is only half of incident response: if you cannot revoke a credential within minutes of learning it leaked, the credential is still live for whoever else already has a copy.
What to do right now
Treat this as a prompt to audit your own posture, not someone else’s:
- Enforce GitHub secret scanning and push protection at the organization level so individual developers cannot disable it per-repo. Then verify no repos have slipped through with it off.
- Run a historical secret scan (TruffleHog, Gitleaks) across your org’s entire commit history — not just current
HEAD. Leaked secrets live in old commits and forks long after they’re “deleted.” - Inventory long-lived cloud access keys. Replace static IAM users with short-lived credentials via OIDC or IAM Roles Anywhere, and set a hard rotation policy. Static keys are the asset class that turns a leak into a breach.
- Lock down your artifact repository. Artifactory, Nexus, and internal registries should require SSO-backed, scoped tokens — never shared static passwords — and build-pipeline credentials should be read-only wherever a write path isn’t strictly needed.
- Rehearse credential revocation. Time how long it takes to kill a leaked key end to end. If it’s longer than a few minutes, fix the process before you need it.
CISA had not published a formal statement on the incident as of this writing, and the exposed credentials have reportedly been rotated. The takeaway for everyone else is unglamorous: the worst breaches of 2026 so far have not been exotic zero-days — they’ve been a public repo, a disabled scanner, and a password ending in 2026.