How the world’s top cyber authority left its door wide open on GitHub: CISA shares lessons from major blunder

“The worst leak that I’ve witnessed in my career” hit the US Cybersecurity and Infrastructure Security Agency (CISA) in May, with secret keys and blueprints of internal systems found in plain text on GitHub. Hackers could’ve broken in and moved around CISA with ease, yet the agency now says this didn’t happen and sheds more light in the postmortem.

The leak was so severe that the GitGuardian security researcher Guillaume Valadon, who discovered it on May 14th, thought it was “too good to be true.”

A public GitHub repository, ironically named “Private-CISA,” contained 844MB of plaintext passwords, AWS tokens and credentials, CI/CD build logs, Kubernetes manifests, Terraform infrastructure code, GitHub Actions workflows, internal documentation backups, and references to AWS accounts. Everything a potential attacker would need was put on a plate.

What's even worse, the data in the repository had been laid bare for months since November 2025 (most sensitive secrets were added later). And CISA took days to invalidate all tokens after the leak was publicly reported.

Now, CISA has shared lessons learned from the incident caused by a reckless contractor.

“Sharing experiences from incident response activities help other organizations learn from such experiences and enables them to take necessary precautions to prevent similar incidents from happening in their environments,” the released statement reads.

It took a journalist to get CISA's attention

CISA only learned of the incident when the journalist began asking questions on May 15th.

“On Friday, May 15th, CISA began an internal incident response when an investigative reporter inquired about internal CISA Amazon AWS GovCloud Keys and other information being made available in a public repository. The reporter received this information from a security researcher whose company continuously scans public code repositories.”

Brian Krebs, an investigative reporter, was first on the story, tipped by the GitGuardian researcher, who had spent a day trying to get the leak fixed.

They reported the leak through the CERT/CC, a formal vulnerability coordination portal, and nine warning emails went unnoticed by the GitHub repo owner. The researcher hoped Krebs would forward the issue to CISA contacts, and also, around 16:00 CET on May 15th, they reached CISA directly.

The agency reacted immediately with “swift and comprehensive action to mitigate any exposure to CISA’s cloud resources and code repositories.”

This is indeed the worst leak that I’ve witnessed in my career.

Valadon wrote in an email to Brian Krebs.

The watchdog took the reported repository offline, preserving a copy for later analysis, disconnected the affected development environment, reset compromised credentials, and revoked the responsible individual’s system access.

“This repository was not part of CISA’s official GitHub but rather was a personal repository owned by a contractor,” the postmortem reads.

“The individual had uploaded copies of a CISA build and deployment repository to their personal GitHub account for the purpose of creating cloud infrastructure autonomously.”

The report acknowledges that the contractor copied admin and build credentials to their public repository, which also included build code.

However, CISA sees no evidence in the logs that the leaked keys were abused: they weren’t used outside of CISA’s environments, and “No customer or mission data was exposed.”

This somewhat contradicts Krebs’s May 22nd report, which noted that CISA was still struggling to contain the breach days later and was still working to invalidate and replace many of the exposed keys and secrets.

An independent researcher at Truffle Security verified that credentials remained live for two days after public disclosure: a GitHub App key, a master key with write access to the entire CISA’s GitHub organization, alongside over a dozen others across at least six different vendors.

Still, CISA claims it implemented appropriate measures “swiftly.”

“All credentials across all the environments where the individual was an administrator were rotated, not just the exposed credentials,” the statement reads.

Other actions before bringing the development environment back online included tuning the allow and deny lists for its code repositories and limiting users' ability to upload to public code repositories.

So what were the actual lessons learned?

CISA identified six areas that can be strengthened, and tightening control over public repositories is listed as the first. The contractor was able to take a private code and just dump it on GitHub.

CISA says it reviewed Zero Trust tooling and now leverages an endpoint detection and response (EDR) solution to monitor and “manage uploads,” but didn’t specify how the restrictions are enforced.

“This approach enables CISA developers to pull code from public repositories while reducing the risk of uploading intellectual property or sensitive content to public repositories.”

No secrets in any repos

The second lesson – monitor for secrets in repositories, as none of them should ever be exposed there, even private ones. CISA's action plan improves the management of developer secrets and includes enhanced monitoring of exposures going forward.

Third, CISA acknowledges wasting too much time in the early stages of the incident because it had to build a GitHub/Cloud playbook from scratch.

“Build Comprehensive Playbooks. It is important to prepare playbooks for all anticipated needs to ensure a rapid response if an incident occurs. CISA had missed creating a GitHub/Cloud playbook.”

A direct line for researchers

The watchdog also acknowledges it has to simplify incident reporting channels, which sent the security researcher scrambling across multiple avenues: emailing the contractor, submitting a report through CISA’s vulnerability disclosure platform, intended for broader security bugs, and ultimately involving a reporter.

CISA is refining its channels and recommends that others follow suit to ensure similar incidents affecting the organization itself, rather than products or customers, are handled effectively.

“While many researchers rely on the security.txt file, organizations can ensure clarity by publishing reporting instructions in multiple prominent locations.”

The agency patted itself on the back for taking external reporting seriously and thanked the security researcher and the investigative reporter for their collaboration.

Tighter controls and replacement-ready keys

The fifth lesson is stronger development environment guardrails: consolidating them, ensuring consistent security controls, and reducing risk of unmanaged tooling. CISA had been advancing consolidation efforts before the incident, and it only affirmed the direction.

The last one – ensure cryptographic key readiness. CISA admits it was too slow to rotate compromised digital keys and urges every org to maintain mature, well-tested key management capabilities.

Two more things worked well during the incident: zero-trust principles, not only in production, but also in development, and enhanced logging capabilities provided visibility.

“Alerting across all environments was key to CISA’s successful incident response and for detecting any future unusual activity early,” CISA said, urging the adoption of Zero Trust principles.

CISA leans on a well-worn line – it’s not a “if,” but “when” the breach happens – inviting the broader cybersecurity community to be transparent when their turn comes.

Krebs previously reported that the exposed GitHub repo was maintained by a Nightwing employee, a government contractor from Dulles, Virginia.

Under US President Donald Trump, CISA underwent a major reorganization in February 2026, resulting in the loss of approximately one-third of its workforce.