By ByteBot
On July 10, 2026, the US Cybersecurity and Infrastructure Security Agency published the post-mortem from its May credential leak — and the admission buried in it tells you everything. When a Nightwing contractor’s personal GitHub account exposed 844 MB of CISA’s AWS GovCloud admin keys, plaintext passwords, and infrastructure secrets for six months straight, CISA’s post-mortem confirms the agency had no incident response playbook for it. Staff built one during the active breach.
Let that land. The agency whose job is to write federal cybersecurity guidance — the same agency that publishes incident response frameworks for the rest of government — improvised its own response because nobody had written one down ahead of time. ByteIota covered the original leak in May; this week’s post-mortem is a different story.
What Was Actually in the Repository
From November 13, 2025 to May 18, 2026, a public GitHub repository named “Private-CISA” sat on a Nightwing contractor’s personal account — used, apparently, as a file sync tool between work laptop and home computer. The contents included AWS GovCloud admin keys, GitHub personal access tokens, Entra ID SAML certificates, Kubernetes manifests, Terraform configurations, CI/CD build logs, and a spreadsheet the contractor named “AWS-Workspace-Firefox-Passwords.csv”. There was also a file called “Important AWS Tokens.txt”.
GitGuardian’s Public Monitoring system surfaced the leak on May 14. Researchers initially thought it was a hoax — the file names were so explicit they seemed staged. They confirmed it was real, contacted the contractor directly (no response), and eventually reached journalist Brian Krebs. Krebs contacted CISA on May 18. The repository came down within hours. Credential revocation took considerably longer.
Three Failures, One Post-Mortem
CISA’s July 10 post-mortem documented three process failures that made this incident worse than it needed to be.
First, no incident playbook. The agency acknowledged staff “had to spend time building [a playbook] during the early stages of the incident.” They were making containment and communication decisions while the breach was live.
Second, no clear reporting channel. The post-mortem noted that reporting mechanisms “were not well defined.” This is why GitGuardian had to contact a journalist. A security researcher trying to report a critical vulnerability to the US government’s cybersecurity authority could not find a direct path in.
Third, no repository controls. Nothing prevented a contractor with privileged access from pushing 844 MB of production credentials to a public personal account over six months. No monitoring, no DLP, no visibility into contractor repository activity.
The Safeguard That Was Turned Off
The most damning detail is not what was uploaded. It is that the contractor had deliberately disabled GitHub’s built-in push protection — the feature designed to flag or block credentials before they are committed to a repository. Push protection is enabled by default on public repositories. Someone turned it off. The result: six months of commits, no automated alert.
CISA’s forensic analysis confirmed no external actor exploited the exposed credentials. The damage was contained. However, that is about as much comfort as discovering your front door was unlocked for six months and nobody tried the handle. It does not mean leaving it unlocked was defensible.
What the Post-Mortem Recommends (and What It Misses)
CISA’s recommendations cover the detection layer: enable push protection, add pre-commit hooks, implement continuous secret scanning, rotate credentials faster, and document incident response playbooks for all anticipated scenarios. These are worth implementing. Moreover, they are the minimum — not the finish line.
Security researchers point out that detection-focused controls address the symptom, not the architecture. The root cause is static, long-lived credentials. An AWS GovCloud admin key does not expire on its own. An RSA private key committed in November 2025 remains valid in May 2026 unless someone manually revokes it. The architectural fix is eliminating static credentials entirely: OIDC federation for GitHub Actions, IAM role assumption via AWS STS, Workload Identity Federation on GCP. With these patterns, a leaked file contains a token that expired hours ago. There is nothing actionable for an attacker.
Key Takeaways
- Do not disable GitHub push protection. It exists by default for a reason. Turning it off trades security for convenience in the worst possible way.
- Write your incident response playbooks before you need them. CISA built one during an active breach. That is the worst time to be deciding what to do.
- Static, long-lived credentials are the root problem. Pre-commit hooks and secret scanning are useful layers; eliminating static secrets via OIDC and short-lived tokens is the actual architectural fix.
- Your vulnerability reporting channels need to be discoverable. If a researcher cannot find how to contact you, they will find a journalist who can.
