CISA Releases Postmortem on Major Internal Data Leak Involving Exposed GitHub Credentials and AWS Keys

The Cybersecurity and Infrastructure Security Agency (CISA) has released a comprehensive postmortem report detailing a significant internal data leak that left sensitive administrative credentials exposed to the public internet for nearly half a year. The incident, which originated from a third-party contractor’s error, saw dozens of internal CISA credentials—including Amazon Web Services (AWS) GovCloud keys—published in a public GitHub repository. The agency’s subsequent analysis highlights critical gaps in incident response, key management, and external communication channels, providing what experts describe as a cautionary tale for security organizations worldwide.

The exposure began when a contractor inadvertently created a public repository titled “Private CISA” on GitHub. This repository contained approximately 844 MB of sensitive data related to the agency’s internal operations. Among the most critical files discovered was one titled “importantAWStokens,” which housed administrative credentials for three AWS GovCloud servers—environments specifically designed to host sensitive government data and regulated workloads. Furthermore, a file named “AWS-Workspace-Firefox-Passwords.csv” was found to contain a list of plaintext usernames and passwords for dozens of CISA’s internal systems, suggesting a fundamental lapse in secure credential storage practices.

Chronology of the Exposure and Discovery

The timeline of the leak suggests a protracted period of vulnerability. While the exact date of the repository’s creation was not specified in the initial summary, the data remained accessible to the public for nearly six months before remediation began.

The sequence of events reached a turning point on May 15, 2026, when Guillaume Valadon, a security researcher at the automated secrets-detection firm GitGuardian, identified the repository. GitGuardian’s platform, which continuously monitors public code repositories for leaked secrets, had actually flagged the repository multiple times prior to the agency’s awareness. According to Valadon, GitGuardian sent nine separate automated alerts to the offending account associated with the leak. These alerts went unaddressed, allowing the "Private CISA" repository to remain active.

Frustrated by the lack of response to automated notifications, Valadon sought the assistance of investigative journalist Brian Krebs of KrebsOnSecurity to ensure the gravity of the situation reached the appropriate officials at CISA. Following the notification from Krebs on May 15, CISA initiated its incident response protocol. However, the agency admitted that it took more than 48 hours to fully invalidate the leaked AWS keys and other secrets, a delay that has drawn scrutiny from the cybersecurity community.

Technical Barriers to Rapid Remediation

In its official report, CISA addressed the 48-hour delay in rotating the compromised keys. The agency attributed the slow response to the inherent "complexities of the agency’s systems" and the extensive interconnections between federal infrastructure and industry partners.

Rotating administrative keys in a government environment is rarely a standalone task; it often requires coordinating with various stakeholders to ensure that the revocation of a key does not inadvertently shut down critical services or disrupt inter-agency data flows. CISA noted that this experience underscored the need for "mature and well-tested key management capabilities." The agency’s admission suggests that while it had the technical ability to revoke access, the procedural and dependency-related hurdles were more significant than anticipated.

The report also revealed a gap in CISA’s internal playbooks. While the agency maintained established procedures for a variety of cyber incidents, it lacked a specific, documented strategy for handling exposures involving GitHub or similar third-party cloud services. This oversight contributed to the initial friction in the response process.

Failures in External Reporting Channels

One of the most significant revelations in the CISA postmortem is the difficulty the security researcher faced when trying to report the leak. The report, co-authored by Preston Werntz, CISA’s acting Chief Information Officer, and Brad Libbey, the acting Chief Information Security Officer, admitted that the agency’s external reporting channels were poorly defined for this type of incident.

Valadon attempted several avenues to alert CISA, including:

1. Responding to automated GitGuardian alerts.
2. Directly emailing the contractor responsible for the repository.
3. Submitting a report through CISA’s Vulnerability Disclosure Platform (VDP).

The VDP, however, was designed for researchers to report vulnerabilities in the broader national infrastructure or specific software products, not for reporting internal CISA administrative leaks. Because the report did not fit the standard "product-bug" profile, it struggled to reach the correct internal security team. This led to the eventual involvement of a third-party reporter to bypass the bureaucratic bottleneck.

CISA has since committed to refining these channels, emphasizing that organizations must distinguish between reports involving their products and reports involving their own internal infrastructure. The agency recommended that organizations publish reporting instructions in multiple prominent locations and adopt the "security.txt" standard—a simple text file placed on web servers to give security researchers a clear point of contact.

The Role of Zero-Trust and Logging as a Safety Net

Despite the severity of the credential exposure, CISA’s postmortem offered a "passing grade" to its internal security architecture in terms of impact mitigation. The agency utilized its enhanced logging capabilities and zero-trust principles to verify the extent of the damage.

According to the report, CISA’s detailed logs allowed investigators to confirm that the leaked credentials were not utilized by unauthorized actors outside of CISA’s authorized environments during the six-month window. Furthermore, the agency stated that no customer data or "mission-critical" data was accessed or exfiltrated.

The adoption of zero-trust principles—where access is strictly controlled and verified regardless of whether the user is inside or outside the network perimeter—acted as a secondary layer of defense. Even with administrative keys, an attacker would likely have faced additional hurdles, such as multi-factor authentication (MFA) or IP-based restrictions, which limited the utility of the stolen plaintext passwords. In the wake of the investigation, the contractor responsible for the leak had their system access revoked.

Expert Analysis and Industry Implications

The cybersecurity industry has reacted to the CISA report with a mixture of concern regarding the leak and praise for the agency’s transparency. Guillaume Valadon noted that the incident validates the necessity of continuous, rather than periodic, scanning for exposed secrets.

"Letting nine notification emails go unanswered is how a one-day incident becomes a six-month exposure," Valadon wrote in his analysis. He argued that the incident proves that internal scanning must catch plaintext passwords and backups before they are even committed to a repository, let alone a public one.

The fact that administrative credentials for AWS GovCloud were stored in a way that allowed them to be leaked is a significant point of contention. It highlights a recurring issue in the public sector: the "human element" of security. Even the most sophisticated government agencies remain vulnerable to the errors of third-party contractors and the improper handling of secrets by developers.

However, the decision by CISA to publish a detailed postmortem is being hailed as a major step forward for government accountability. By admitting to its failures—specifically the 48-hour rotation delay and the ignored automated alerts—CISA is setting a precedent for other federal agencies and private corporations. Transparency in the aftermath of a breach is often viewed as a "security best practice" in itself, as it allows the broader community to learn from the specific technical and procedural failures of others.

Lessons for Security Teams

The CISA incident provides several actionable lessons for modern security operations centers (SOCs) and IT leadership:

• Secret Scanning is Non-Negotiable: Organizations must implement automated tools to scan both public and private repositories for API keys, passwords, and tokens. These tools should be integrated into the CI/CD (Continuous Integration/Continuous Deployment) pipeline to prevent secrets from being committed in the first place.
• Defining Reporting Pathways: There must be a clear distinction between a "Bug Bounty" or VDP program and an "Emergency Disclosure" channel. If a researcher finds your internal "crown jewels" on the internet, they should not have to wait in a product-bug queue.
• Testing Key Rotation: Key management is not just about storage; it is about the ability to revoke and replace. Organizations should conduct "fire drills" for key rotation to identify dependencies that could slow down a real-world response.
• Contractor Oversight: Security requirements for contractors must include strict guidelines on the use of public repositories and the handling of internal agency data. Regular audits of contractor-managed codebases are essential.

As CISA continues to refine its "playbook" for cloud and GitHub-related incidents, the agency has vowed to improve its monitoring for developer secrets and to make its reporting channels "easier and faster" for the research community. While the leak was a significant embarrassment for the nation’s lead cybersecurity defender, the resulting postmortem may ultimately strengthen the very infrastructure CISA is tasked with protecting by providing a roadmap for more resilient incident response.