The U.S. Cybersecurity and Infrastructure Security Agency has confirmed, in its own published after-action write-up, that a contractor copied internal CISA build and deployment code into a personal public GitHub repository, exposing administrative credentials for Amazon AWS GovCloud environments along with plaintext passwords for internal systems. The exposure was surfaced by secrets-scanning firm GitGuardian in mid-May 2026 and reached CISA only after the researchers enlisted journalist Brian Krebs to make contact. Accounts of the data volume differ slightly: GitGuardian's own blog (S7) and Krebs-derived reporting (S1) both cite 844 MB, while Security Management (S6) describes it as "just under 1 gigabyte." Reporting agrees the repository sat publicly accessible for roughly six months before anyone at the agency knew.
What Happened
The timeline is documented across several sources and the dates diverge depending on which clock you use. GitGuardian's automated scanner flagged the repository on 13 May 2026 and fired alerts at the GitHub account owner, nine of which drew only automated responses (S6). GitGuardian's own account dates the find to 14 May and says the repository was taken down within 26 hours (S7). CISA's incident response formally began on Friday, 15 May, when an investigative reporter contacted the agency about internal AWS GovCloud keys visible in a public code repository (S2, S8). The researchers had first tried CERT/CC, personal contacts, and finally a journalist before reaching anyone with authority (S7).
Once notified, CISA's Office of the Chief Information Officer moved on a "stop the bleeding" basis: it pulled the public repository from view while preserving a forensic copy, took the affected development environment offline, reset associated credentials, and revoked the responsible individual's system access (S4, S8). The agency published its lessons-learned blog post on 9 July 2026, authored by Acting CIO Preston Werntz and Acting CISO Brad Libbey (S2).
Accounts differ on how fast containment actually landed. Krebs-derived reporting (S1) says it took CISA over 48 hours to invalidate the compromised AWS keys and other secrets, with CISA attributing the delay to the complexity of its interconnected systems and its relationships with federal and industry partners. GitGuardian (S7) frames the takedown as achieved in under a day. Both can be true if takedown and full credential rotation are counted separately, but the sources do not reconcile this explicitly.
What Was Taken
There is no evidence any adversary took anything. CISA's forensic log analysis concluded the leaked credentials were never used outside CISA's own environments and that no customer or mission data was exposed (S8). What was exposed is a different matter.
The repository, reported as titled "Private CISA" (S1), contained:
- A file named "importantAWStokens" holding administrative credentials for three Amazon AWS GovCloud servers (S1, S6).
- "AWS-Workspace-Firefox-Passwords.csv," listing plaintext usernames and passwords for numerous internal CISA systems (S1).
- Administrator and build credentials for CISA's coding system, plus infrastructure-as-code containing private access keys for AWS and other services (S5, S8).
GitGuardian characterised the material as providing "a detailed view into cloud infrastructure, deployment workflows, software supply-chain tooling, and internal operations practices," and called the repository "a catalogue of unsafe practices: plain text passwords, backups committed to Git, and explicit instruction to disable GitHub's secret scanning" (S6). That last detail is the one that should stop defenders cold. Secret scanning was not merely absent; documentation in the repository reportedly told developers to turn it off.
Why It Matters
CISA is the federal body that tells everyone else how to run incident response, and its most striking admission is that it did not have a playbook for this scenario. TechCrunch, as relayed by TechGrid (S5), reported CISA staff "had to spend time building" a playbook during the early stages of the incident. Cybersecurity Dive, via the same source, noted the agency has spent years urging organisations to build IR playbooks yet had none ready for a cloud secrets leak via GitHub.
The disclosure path is equally instructive. Nine automated notification emails went unanswered. A national CERT was involved. A journalist ultimately made the introduction. Six days after publishing its post-mortem, CISA and four allied cyber authorities issued guidance telling software vendors how to build coordinated vulnerability disclosure programs, including a recommendation to separate vulnerability triage from ordinary customer support channels because shared channels "may lead to overlooked and undervalued reports or accidental disclosure" (S2). Help Net Security read the timing as deliberate: CISA's own failure, written as advice.
The candour is genuinely unusual and worth crediting. GitGuardian's researcher noted this appears to be the first time a national cybersecurity agency has publicly advocated for secrets scanning and for simplifying relations with security researchers (S7). It also lands against a live policy backdrop: CISA is simultaneously trying to finalise the CIRCIA incident-reporting rule, now slipped past an October 2025 deadline and a May 2026 reset to a September target, while industry groups lobby for narrower scope and less disclosure (S3). An agency asking the private sector to report more while publishing its own failure is at least arguing from example.
The Attack Technique
There is no threat actor in this story. The root cause was an insider convenience decision with no malicious intent identified in any source.
Investigators determined the exposed material was not part of CISA's official GitHub presence but a personal repository belonging to a contractor who had copied the agency's build and deployment code, along with admin and build credentials, in order to automate cloud infrastructure creation on their own (S5, S8). This is the classic shadow-IT pattern: a developer needing to move faster than the sanctioned process allows, replicating a working environment somewhere they fully control, and inheriting none of the controls that made the original environment safe.
The compounding failures were structural rather than technical. Plaintext secrets committed to source control. Backups committed to Git. Secret scanning explicitly disabled. No organisational monitoring of public repositories for the agency's own developer secrets. No control preventing an account with administrative access from pushing to a public repo. Any one of those, corrected, would have caught it.
What Organizations Should Do
- Treat every unsolicited external report as signal. Nine unanswered notification emails turned what GitGuardian calls a one-day incident into a six-month exposure (S7). The person reporting a leak to you is not the threat.
- Publish a real disclosure channel and staff it. Follow the CVD guidance CISA co-authored: a public vulnerability disclosure policy, a security.txt file per RFC 9116, the widest practical testing scope, and acknowledgement within two to three business days, routed away from generic customer support queues (S2).
- Scan repositories for secrets continuously, not quarterly. Extend the scanning to private repositories too. No plaintext secret belongs in source control at all, and any internal documentation telling developers to disable secret scanning should be treated as an incident in itself (S6, S7).
- Write the leak-response playbook before you need it. Building process during an active incident cost CISA time it did not have (S5). Cover repository takedown, forensic preservation, environment isolation, and access revocation as pre-agreed steps.
- Test credential rotation under time pressure. CISA cited system interdependencies and partner relationships as the reason rotation took as long as it did (S1). Rehearse mass rotation across environments before an incident proves your dependency graph is untested.
- Rotate wider than the blast radius you can see. CISA reset every credential across all environments where the individual held administrative access, not just the keys that leaked, and tightened allow/deny lists while restricting users' ability to push to public repositories (S8). Assume enumeration you cannot prove and constrain the upload path itself.
Sources: Lessons Learned from CISA’s Recent GitHub Leak – Krebs on Security | CISA folds its own hard-won lessons into coordinated vulnerability... | Industry's message on CIRCIA: Please ask us fewer questions about c... | CISA Shares Cyber Incident Lessons to Strengthen Federal Network De... | CISA GitHub Leak Exposes Incident Response Gaps Inside US Cyber Age... | CISA Shares Lessons Learned from Own Data Breach | CISA GitHub Leak: Incident Response Lessons | CISA Details AWS Credentials Leak