A CISA contractor accidentally published 844 MB of sensitive internal data, including administrative credentials for three AWS GovCloud servers, to a public GitHub repository that sat exposed for nearly six months. The leak only ended after KrebsOnSecurity and GitGuardian researcher Eric Fourrier intervened on May 15, 2026, forcing the agency to rotate keys it had left active for more than 48 hours after first being alerted.
The repository, ironically named "Private CISA," contained plaintext usernames and passwords for dozens of internal systems stored in a file called "AWS-Workspace-Firefox-Passwords.csv." Another file, bluntly titled "importantAWStokens," held the administrative keys to federal cloud infrastructure. CISA has since revoked the contractor's access and published a postmortem that security professionals are already treating as required reading.
Why the Keys Stayed Live for Two Days
CISA acknowledged the external alert quickly, but key rotation dragged past the 48-hour mark. The agency blamed the delay on the complexity of its systems and their interconnections with federal and industry partners. In plain terms: rotating one credential required touching multiple environments, and the playbook for doing so under pressure was not as mature as the agency's public posture suggests.
The postmortem, authored by CISA's acting CIO and acting CISO, concedes that "mature and well-tested key management capabilities" are non-negotiable. That line reads less like advice to the private sector and more like an admission that CISA's own capabilities fell short when it mattered.
Nine Warnings That Nobody Answered
The most damning detail in the entire report is not what CISA did after discovery. It is what it failed to do before.
GitGuardian's automated scanning tools flagged the exposed credentials to the offending GitHub account nine separate times in the months leading up to May 15. Every alert went unanswered. As Fourrier noted in his own analysis, letting nine notification emails pile up is how a one-day mistake becomes a six-month exposure. The researcher eventually escalated through KrebsOnSecurity because CISA's own reporting channels were so poorly defined that a leak affecting the agency's own infrastructure was routed like a product vulnerability report.
"Make it trivial to report a leak about you, not just about your products. The person reporting a leak to you is not the threat."
Eric Fourrier, GitGuardian researcher
CISA is now refining those channels and urging other organizations to publish reporting instructions in multiple prominent locations, not just a security.txt file.
The Playbook Gap
CISA had an incident response playbook. What it did not have was a chapter on what to do when secrets leak through GitHub or other cloud services. That blind spot is not unique to CISA. Government agencies and large enterprises often build elaborate defenses around perimeter security while treating developer workflows, code repositories, and secrets management as secondary concerns.
The incident also highlights a broader tension in federal cybersecurity. CISA has championed zero-trust architecture and aggressive logging, both of which helped the agency demonstrate that no customer or mission data was accessed externally. But zero trust does not help if the credentials themselves are sitting in a public repo with a filename that screams "steal me."
What CISA Got Right, and What It Cost
The agency deserves credit for one thing: transparency. Publishing a detailed postmortem, naming its own failures, and explicitly endorsing continuous secrets scanning and researcher-friendly disclosure channels is practically unheard of for a national cybersecurity agency. Fourrier called it the first time a federal body of CISA's stature has publicly advocated for both practices.
That transparency, however, does not erase the operational failures. The leak persisted because of a chain of small breakdowns: a contractor who committed sensitive files, an organization that ignored automated alerts, a reporting structure that forced a researcher to go through a journalist, and a key rotation process that took two days to execute. Any single link in that chain, fixed proactively, would have shrunk the window of exposure from months to hours.
What Organizations Should Take Away
CISA's own recommendations are a decent starting point: maintain well-tested key management, scan public repositories continuously, and make it dead simple for outsiders to report leaks about your infrastructure. But the real lesson is operational, not technical. Security teams need to treat secrets leaks with the same urgency as active intrusions, because in a world where developers push code to public repos daily, a leaked credential is an active intrusion waiting to happen.
The agency says it has rotated all secrets and built an action plan for better developer secrets management. Whether that plan includes penalties for contractors who store plaintext passwords in CSV files, or automated blocking of commits containing patterns that look like AWS keys, will determine if this postmortem is a turning point or just a well-written apology.
Watch for CISA's updated vulnerability disclosure guidelines in the coming weeks. If the agency follows its own advice, those guidelines should make reporting an internal leak as straightforward as reporting a phishing site.