CISA is holding the leak with its hands

A CISA contractor with administrative access to the agency’s code development platform created a public GitHub profile called “Private-CISA” and filled it with plaintext credentials to dozens of internal CISA systems, including AWS GovCloud keys. Experts who reviewed the commit logs said the contractor disabled GitHub’s built-in protection against publishing secrets before pushing them. KrebsOnSecurity reported the leak on May 18. More than a week after the security firm GitGuardian first notified CISA, the agency was still working to invalidate and replace many of the exposed keys.

The repository was created in November 2025 and reads less like a project than a scratchpad. Experts who reviewed the now-defunct archive described a pattern consistent with one operator using the repo to synchronize content between machines rather than to curate a codebase. The most sensitive secrets appear to have landed in late April 2026, according to Truffle Security.

CISA’s public line is that “there is no indication that any sensitive data was compromised as a result of the incident.” What undercuts that is how GitHub works. The platform publishes a live feed of every commit and change to public repositories. Dylan Ayrey, who built the secret-scanning tool TruffleHog and runs Truffle Security, monitors that firehose to warn account owners when their keys leak. He says attackers watch the same feed.

“We monitor that firehose of data for keys, and we have tools to try to figure out whose they are,” Ayrey told KrebsOnSecurity. “We have evidence attackers monitor that firehose as well. Anyone monitoring GitHub events could be sitting on this information.”

What was actually exposed

The contents explain why the exposure window matters. On May 20, Ayrey reported that CISA still had not invalidated an RSA private key granting access to a GitHub app owned by the CISA enterprise account and installed on the CISA-IT organization with full access to every repository.

“An attacker with this key can read source code from every repository in the CISA-IT organization, including private repos, register rogue self-hosted runners to hijack CI/CD pipelines and access repository secrets, and modify repository admin settings including branch protection rules, webhooks, and deploy keys,” Ayrey said. That is read access to all source, a path to hijack build and deploy pipelines and pull their secrets, and write access to the controls that would normally catch a tampered pipeline.

CISA appears to have killed that key sometime after KrebsOnSecurity relayed Ayrey’s finding. Ayrey said credentials tied to other critical security technologies deployed across the agency’s portfolio still had not been rotated. CISA’s statement on that was that it “is actively responding and coordinating with the appropriate parties and vendors to ensure any identified leaked credentials are rotated and rendered invalid.” The agency is clearing the leak one disclosure at a time.

The response on the Hill

Lawmakers in both houses want answers. In a May 19 letter to CISA Acting Director Nick Andersen, Sen. Maggie Hassan (D-NH) wrote that the leak “raises serious concerns regarding CISA’s internal policies and procedures at a time of significant cybersecurity threats against U.S. critical infrastructure.” Hassan noted the incident lands against major internal disruption: CISA lost more than a third of its workforce and almost all of its senior leaders after the Trump administration forced early retirements, buyouts, and resignations across the agency.

Rep. Bennie Thompson (D-MS) and Rep. Delia Ramirez (D-Ill) said the same in their own May 19 letter. “It’s no secret that our adversaries - like China, Russia, and Iran - seek to gain access to and persistence on federal networks,” they wrote. “The files contained in the ‘Private-CISA’ repository provided the information, access, and roadmap to do just that.”

The control that would have helped, and the one that wouldn’t

GitHub lets an organization or enterprise enforce push protection from the top so that individual users cannot turn off secret scanning on commits. James Wilson of the Risky Business podcast pointed out that policy as the available control. It only binds repositories inside the managed org, and this repo was on a personal account.

That is the harder gap to close. “Ultimately, this is a thing you can’t solve with a technical control,” Wilson’s co-host Adam Boileau said. “This is a human problem where you’ve hired a contractor to do this work and they have decided of their own volition to use GitHub to synchronize content from a work machine to a home machine. I don’t know what technical controls you could put in place given that this is being done presumably outside of anything CISA managed or even had visibility on.”

If you run a shop with secrets worth stealing, two things follow. Enforce push protection at the org and enterprise level so nobody on a managed repo can disable it. And monitor the public commit firehose for your own keys the way attackers already do, because once a credential hits that feed, invalidating it by hand is a race you have already started behind.