CISA is the United States federal agency that tells everyone else how to protect their passwords and credentials. For six months, it left 844 MB of its own — passwords, cloud keys, certificates — sitting in a public GitHub repository.
That is not a hack. Nobody broke in. A contractor put it there.
Disclaimer: Not a cybersecurity expert. Just a DBA reading the news.
What happened
On May 14, 2026, researcher Guillaume Valadon at GitGuardian found a public GitHub repository named 'Private-CISA'. Inside was 844 MB of plaintext passwords, AWS GovCloud credentials, API tokens, Entra ID SAML certificates, SSH keys, Kubernetes manifests, Terraform code, and internal documentation backups belonging to the Cybersecurity and Infrastructure Security Agency. The repository had been created on November 13, 2025 — public for six months before anyone outside flagged it.
Valadon reported it. CISA took the repository offline within 26 hours. Some of the exposed AWS keys stayed valid for another 48 hours after that.
The repository was maintained on a personal GitHub account by a contractor, who appears to have used it to sync files between a work machine and a home machine. The commit history shows GitHub's secret scanning was deliberately disabled.
Again — CISA is the agency that writes the rules.
CISA's statement: "Currently, there is no indication that any sensitive data was compromised as a result of this incident."
What was actually in it
The file names tell the whole story.
importantAWStokens — administrative credentials to three AWS GovCloud accounts.
AWS-Workspace-Firefox-Passwords.csv — plaintext usernames and passwords for dozens of internal CISA systems — the kind of list a browser builds when you let it save every login.
Nobody had to decrypt anything. A file called importantAWStokens held exactly that. No exploit. No zero-day. Just a contractor saving passwords to a CSV and pushing it to a public repo.
Valadon, the researcher who found it, put it this way:
"I honestly believed that it was all fake before analyzing the content deeper. This is indeed the worst leak that I've witnessed in my career. It is obviously an individual's mistake, but I believe that it might reveal internal practices."
This is not a federal story. It is a habits story.
It is easy to read this as a government story and move on. Do not. Every failure in this incident is something I find in SQL Server shops.
| The CISA failure | The SQL Server shop equivalent |
|---|---|
| Plaintext passwords in a CSV | Connection strings with embedded sa passwords in .dtsConfig files, deployment scripts, and .publish.xml |
| Backups committed to Git | .bak files and BCP exports sitting in a repo |
| Secret scanning disabled on purpose | The 'make it stop warning me' move, in any repo your team owns |
| AWS keys valid 48 hours after takedown | Can you actually rotate a SQL login or a linked server credential in minutes? |
| Personal repo used to sync work files | Contractors and developers moving work between machines through personal GitHub |
Read that last row again. Work files on a personal account. One of the worst things for any security team to see - and it's everywhere.
Find it in your own estate
You do not need a federal contractor to have this problem. SQL Server credentials hide in source control in predictable places.
SSIS configuration files
A .dtsConfig with a connection string carries whatever was in it, password included, unless the package protection level forced the credential out.
Deployment artifacts
.publish.xml profiles, post-deployment scripts, and .sqlproj files routinely carry connection details.
SQL Agent job scripts
Job step T-SQL scripted out to a repo can carry linked server definitions and the credentials behind them.
BCP exports and format files
A .bak or a BCP dump committed 'temporarily' is a database sitting in your Git history forever.
Two things to do very soon. First, secret scanning — a GitHub feature that watches commits for things that look like credentials, AWS keys, tokens, connection strings, and either warns you or blocks the push outright. Turn it on for every repo your team owns, and confirm nobody has turned it off. The CISA contractor's repo had it disabled on purpose. Then ask the harder question: if a credential leaked today, how fast could you rotate it? If the honest answer is days, that is its own finding — just like the 48-hour CISA window.
The bottom line
I have written a lot about AI governance — agents with elevated credentials, the absence of data discipline, the legal exposure forming around it. This is the same story without the AI. A shop moving fast, skipping the basics, one switched-off setting away from a very bad day.
This leak is an 844 MB reminder of how little it takes. No AI. No attacker. Just plaintext passwords in a repo and a scanning feature switched off on purpose.
Secret scanning on. Secrets out of Git. Revocation you can do in minutes, not days. The boring discipline is still where shops are bleeding.
CISA could not keep its credentials out of a public repository. Can you?
More to Read
Krebs on Security: CISA Admin Leaked AWS GovCloud Keys on Github
GitGuardian: How We Got a CISA GitHub Leak Taken Down in Under a Day
The Register: America's top cyber-defense agency left a GitHub repo open
sqlfingers inc: AI Agent. Nine Seconds. One Production Database. Gone.
No comments:
Post a Comment