On May 15, 2026, security researcher Guillaume Valadon of GitGuardian flagged a public GitHub repository called “Private-CISA” that had been sitting exposed since November 13, 2025. Inside were administrative credentials to three AWS GovCloud accounts, plaintext passwords for dozens of internal CISA systems, SAML certificates, API tokens, and 844 MB of operational data. Investigative journalist Brian Krebs broke the story publicly on KrebsOnSecurity on May 19.
The repository was maintained by a contractor working for Nightwing, a U.S. government services firm. The contractor had apparently been using the public repo as a personal file-sync tool between work and home machines for six months.
Valadon described it as “the worst leak that I’ve witnessed in my career.” Looking at the details, that’s not hyperbole.
What Was in the Repository
The repository contained exactly the kind of material that should never touch a public surface:
- An
importantAWStokensfile with administrative credentials for three AWS GovCloud environments. - An
AWS-Workspace-Firefox-Passwords.csvcontaining plaintext credentials for internal CISA systems, including the agency’s “Landing Zone DevSecOps” environment. - SSH keys, Entra ID SAML certificates, and API tokens for internal Artifactory and other development infrastructure.
- CI/CD build logs, Kubernetes manifests, ArgoCD application files, and secret-laden YAML files.
- Directory names like
Backup-April-2026/,All Backups/,LZ-Artifactory/, andKubernetes-Important-Yaml-Files/.
Philippe Caturegli of Seralys, who independently verified some of the exposed credentials, confirmed they were still valid and granted high-level access when tested. The repository was taken offline within roughly 24 hours of CISA being notified, but some AWS keys reportedly remained valid for another 48 hours after that.
According to Valadon’s analysis of public GitHub events, the repository was never forked. That’s a weak indicator that the data didn’t circulate widely—but as he noted, external observers can’t detect clones, so an individual download can’t be ruled out.
The Detail That Matters Most
Plenty of breaches happen because of accidents. This wasn’t one of them.
The contractor had deliberately disabled GitHub’s built-in secret scanning, the automated feature that normally blocks pushes containing what look like API keys, passwords, or credentials. The commit history reportedly showed explicit commands to bypass these protections.
This changes how the incident reads. It’s not “someone made a mistake.” It’s “someone hit a guardrail, turned it off, and kept going—for six months, without anyone noticing.” Caturegli observed that this pattern—developers turning off secret scanning under deadline pressure when a push fails—is more common than it should be. The correct response when a secret-scanning tool blocks a push is to remove the secret from the commit, not to remove the detector.
The other detail worth noting: the contractor used both a CISA-issued contractor email and a personal Yahoo account across commits in the same repository, and the GitHub account itself was personal. That mixed-identity pattern, where work credentials and personal infrastructure get tangled together, is one of the hardest surfaces for any security team to monitor. Valadon called it “where the worst leaks happen.”
Weak password practices compounded the problem. Many of the exposed credentials reportedly followed predictable patterns—platform name plus current year—the kind of thing that would constitute a serious risk even on an internal-only network.
The Structural Problem
The real story isn’t a contractor with bad habits. The real story is that the system around the contractor was designed to fail slowly.
Consider what would need to be true for this incident not to happen:
- Secret scanning enforced at the organization level, not toggleable by individual users.
- Detection of contractor accounts pushing CISA material to personal repositories.
- Review processes that flag the appearance of files named
Important AWS Tokens.txtin any commit. - Rotation policies that would have invalidated those credentials long before six months had elapsed.
- Identity controls that prevent mixing of work and personal email addresses on commits touching sensitive code.
None of these are exotic controls. They’re standard hygiene for organizations handling sensitive infrastructure. Their absence here suggests something deeper than individual negligence: a governance gap where the responsibility for enforcing basic controls didn’t actually land on anyone with authority to enforce them.
The agency has also been operating under significant institutional strain. CISA has experienced substantial workforce reductions in recent years—roughly a third of its staff, according to reporting around the incident—alongside budget pressure and leadership instability. None of this excuses the failure, but it provides context for why oversight gaps may have widened.
Why This Connects to Email Privacy
If you’ve read our earlier guide on what to do when your email is in a data breach, you know we’ve been blunt about one point: a breach is a permanent event. Once data is out, it’s out. The CISA incident is a high-profile example of the same principle, applied to government credentials rather than user accounts.
There’s a useful parallel here for anyone thinking about email security.
Email systems and DevOps environments handle credentials differently, but the architectural lesson is the same: when a service requires users to trust the provider with sensitive material, the provider becomes responsible for ensuring that material doesn’t leak through avoidable channels. That responsibility extends to how operations are structured, not just how the cryptography is configured.
What the CISA incident demonstrates is what happens when that responsibility gets distributed across contractors, personal machines, and toggleable controls. Six months of exposure is what failure looks like when no single point in the system has both the visibility and the authority to stop it.
For an email provider, the equivalent question is whether credentials, keys, and authentication tokens can ever end up in places where a single individual’s mistake exposes thousands of users. The architectural answer involves keeping plaintext material out of any system that doesn’t strictly need it, enforcing organizational-level controls on what can be pushed to external services, and minimizing the surface where mixed personal-and-work identities can blur the lines.
Onion Mail’s approach reflects some of these principles. End-to-end encrypted email is encrypted before it reaches our servers—when users employ PGP, we don’t hold plaintext for those messages. PQCServer, the post-quantum messaging platform we maintain, is released under AGPL-3.0, which means the implementation is auditable rather than something users have to take on faith. These aren’t claims that operational mistakes are impossible. They’re choices about where the trust boundaries sit and how much damage a single failure can do.
The Practical Takeaway
The CISA breach is a worst-case version of something that happens at smaller scales constantly. Credentials end up in places they shouldn’t be. Detectors get disabled when they’re inconvenient. Personal and work boundaries blur in ways that nobody notices until someone outside the organization does.
For individuals, the relevant lesson is the same as after any major breach: assume the data is out there, focus on limiting the blast radius, and don’t trust that “the issue has been resolved” actually means what it sounds like. The exposed AWS keys may have been rotated. The fact that they were exposed for six months is permanent.
For organizations, the lesson is harder: controls only work if they’re enforced at a level where individuals can’t bypass them under pressure. A secret scanner that any developer can disable is functionally optional. A policy nobody enforces is functionally absent.
The question raised by the CISA incident isn’t whether one contractor made a mistake. It’s why that mistake was structurally possible for six months inside an agency whose mission is to prevent exactly this kind of failure at scale.
If you want to monitor whether your own email address has appeared in known breaches, Onion Mail includes built-in breach monitoring that checks against the Have I Been Pwned database without exposing your address to third parties. Status remains visible even after you change your password, because a breach—as the CISA incident illustrates—is not something you can really fix. It’s something you incorporate into how you operate going forward.