CISA's Own AWS Keys Leaked on GitHub for 6 Months

The Cybersecurity and Infrastructure Security Agency, the federal body responsible for telling the rest of the country how to secure its systems, spent six months with its own administrative AWS credentials sitting in a public GitHub repository. According to Krebs on Security's original reporting, an employee at Nightwing, a government security and intelligence contractor based in Dulles, Virginia, created a repository called "Private CISA" on November 13, 2025. It stayed publicly accessible until May 15, 2026, when the security firm GitGuardian finally got the leak in front of someone who could act on it.

CISA has since published its own postmortem of the incident, and the details it discloses about its internal reporting process are almost as concerning as the leak itself.

Key Takeaways

• A Nightwing contractor's public GitHub repository exposed CISA's AWS GovCloud administrative credentials from November 13, 2025 until May 15, 2026, nearly six months.
• The 844 MB repository included a file named "importantAWStokens" with admin credentials to three AWS GovCloud servers, plus a CSV listing plaintext usernames and passwords for internal CISA systems.
• GitGuardian sent nine automated alerts to the repository's owner before all went unanswered, forcing the firm to contact security journalist Brian Krebs directly to reach CISA.
• CISA took more than 48 hours to invalidate the exposed AWS keys after finally being notified, despite the credentials granting administrative access.
• CISA's postmortem, authored by Preston Werntz and Brad Libbey, cited "the complexities of the agency's systems and interconnections with federal and industry partners" and poorly defined reporting channels as root causes.

What Was Actually Exposed?

The "Private CISA" repository held 844 MB of sensitive material, including a file titled "importantAWStokens" containing administrative credentials to three separate AWS GovCloud servers, the isolated cloud region built specifically to meet federal government security and compliance requirements. A second file, "AWS-Workspace-Firefox-Passwords.csv," listed plaintext usernames and passwords for dozens of internal CISA systems. The repository also granted access to CISA's Landing Zone DevSecOps environment and an internal artifactory repository used to store and distribute software packages internally.

GitGuardian researcher Guillaume Valadon summarized what he found bluntly: "Passwords stored in plain text in a csv, backups in git, explicit commands to disable GitHub secrets detection feature." That last detail is the one worth sitting with. GitHub ships a built in feature designed to automatically catch exactly this kind of accidental credential exposure, and someone with access to this repository had deliberately turned it off.

Why Did It Take So Long for Anyone to Notice?

GitGuardian's automated scanning caught the exposed secrets and sent nine separate alerts to the repository's owner. None of the nine got a response. Only after that automated channel failed did GitGuardian escalate to Krebs on Security, and only after Krebs contacted CISA directly did the repository actually come down. CISA's own postmortem acknowledges the breakdown, stating that its reporting channels "were not well defined, leading the security researcher to try multiple avenues" before the leak reached someone able to act on it.

Even after the repository was taken offline, the exposed AWS keys remained valid and usable for more than 48 hours before CISA finished invalidating them. Security researcher Philippe Caturegli of Seralys flagged why that window matters for an environment with this level of access: "That would be a prime place to move laterally. Backdoor in some software packages," referring to the artifactory access that could let an attacker slip malicious code into software CISA distributes internally. CISA has stated that "there is no indication that any sensitive data was compromised" during the exposure window, though that assessment relies on log visibility into activity that occurred over roughly six months on credentials the agency did not know were public.

What Is CISA Doing to Fix It?

CISA's postmortem lists several concrete remediation steps: rotating all exposed secrets, building an action plan for improved developer secrets management, deploying enhanced monitoring for exposed credentials going forward, refining its incident reporting channels, and publishing clearer reporting instructions in multiple locations so external researchers do not have to guess who to contact next time. The agency's own summary of the lesson is understated given the scale of what happened: "Drawing on this experience, CISA encourages others to maintain mature and well-tested key management capabilities."

What Should Every Organization Take From This?

This incident is a useful gut check precisely because it did not happen to an underfunded startup, it happened to the U.S. government's own cybersecurity coordination agency, working with a specialized security contractor. A few practices would have caught this faster at almost any organization:

• Never disable a code hosting platform's built in secret scanning feature, even temporarily, since that control exists precisely to catch the accidental commits every developer eventually makes.
• Publish a single, unambiguous security contact and disclosure process, so an external researcher with a critical finding does not have to try nine alerts and multiple channels before reaching a human who can act.
• Treat credential rotation as immediate, not next business day, once a leak is confirmed; a 48 hour window on administrative cloud keys is more than enough time for an opportunistic attacker to act.
• Audit contractor and vendor repositories with the same scrutiny applied to internal ones, since this leak originated with a partner organization's employee, not a direct CISA hire.
• Store no credentials in plaintext, in a CSV, a config file, or anywhere else, regardless of how internal or short lived the storage location seems at the time.

CISA publishing a detailed postmortem at all is arguably a point in its favor, most breached organizations disclose far less about their own internal failures. But the gap between the agency's public guidance on key management and its own six month exposure window is the kind of irony that undercuts the credibility of security advice coming from the top down. It also echoes a pattern Gblock has covered before: a dormant OAuth token let hackers loot a company's Salesforce environment in 15 minutes earlier this year, a reminder that forgotten credentials are just as dangerous as stolen ones. The lesson holds regardless of who it happened to: automated alerts only work if someone reads them, and a security control that gets quietly disabled protects no one.

Sources: Krebs on Security's original report and Krebs on Security's coverage of CISA's postmortem.