The US Cybersecurity and Infrastructure Security Agency confirmed in a public postmortem that administrative credentials for its Amazon AWS GovCloud environment, along with plaintext passwords for internal agency systems, sat exposed in a contractor's personal GitHub repository until an investigative reporter alerted the agency on May 15, 2026. CISA's own account, published July 9, 2026 by Acting CIO Preston Werntz and Acting CISO Brad Libbey, states that no customer or mission data was exposed and that log analysis showed the leaked credentials were never used outside CISA's environments. The agency also conceded it had no prepared incident response playbook for an incident against itself and had to write one mid response. This was not an intrusion by an external threat actor. It was a self inflicted exposure, discovered by a third party scanner, and it took a journalist to close the loop.
What Happened
The timeline is consistent across CISA's primary account and the press reporting. On Friday, May 15, 2026, an investigative reporter contacted CISA asking about internal AWS GovCloud keys and other agency material sitting in a public code repository. CISA says the reporter had received the material from a security researcher whose company continuously scans public repositories. KrebsOnSecurity and TechCrunch identify the parties directly: the researcher was from the secrets detection firm GitGuardian, and the reporter was Brian Krebs, who published the original story in May.
CISA's Office of the Chief Information Officer moved the same day. Per the agency's report, it took the public repository offline while preserving a copy for forensic analysis, took its own development environment offline and reset associated credentials, and revoked all system access for the individual responsible. Analysis of the saved repository and supporting telemetry established that the contractor had uploaded copies of a CISA build and deployment repository, including Infrastructure as Code and build code, to a personal GitHub account in order to stand up cloud infrastructure autonomously. Both admin and build credentials went with it. The repository was never part of CISA's official GitHub organization.
Two points where sources diverge are worth stating plainly. First, on the disclosure date of the postmortem: CISA's own blog is dated July 9, 2026, and CyberScoop, TechCrunch and Help Net Security all describe a report released that Thursday. Infosecurity Magazine refers to "an update published on June 9." The primary source date should be treated as authoritative. Second, on the speed of remediation: CISA frames its response as beginning "within moments," while Krebs reports that the agency acknowledged the alert quickly but took more than 48 hours to invalidate the AWS keys and many of the other leaked secrets. CISA's report does not dispute this, attributing the delay to system complexity and interconnections with federal and industry partners, and recommending that others "maintain mature and well-tested key management capabilities." Both accounts can be true: containment was fast, full key rotation was not.
What Was Taken
There is no evidence any adversary took anything. What matters is what was available to take, and here the primary source is deliberately less specific than the press.
CISA describes the exposure as covering a build and deployment repository containing Infrastructure as Code and build code, plus admin and build credentials. KrebsOnSecurity provides the granular inventory and is the only source for these figures: a public repository named "Private CISA" holding 844 MB of sensitive CISA related data; a file titled "importantAWStokens" containing administrative credentials to three Amazon AWS GovCloud servers; and a second file, "AWS-Workspace-Firefox-Passwords.csv," listing plaintext usernames and passwords for dozens of internal CISA systems. Infosecurity Magazine describes the same material in looser terms, as credentials to "several highly privileged AWS GovCloud accounts and a large number of internal CISA systems."
Exposure duration is a single source claim. Krebs reports the credentials were public for almost six months before the agency was notified. CISA's postmortem does not state a dwell time. CyberScoop adds that the researcher who found the leak called it one of the worst he had ever seen, and that the incident drew congressional scrutiny.
CISA's stated impact findings, drawn from SOC logs, are that no customer or mission data was exposed and that none of the leaked credentials were exercised outside CISA's own environments. That conclusion is only as strong as the logging behind it, and CISA specifically credits its logging maturity for making the determination possible.
Why It Matters
The agency responsible for defending federal civilian networks published a report saying it did not have a playbook for defending itself. TechCrunch's coverage centres on this admission: CISA staff "had to spend time building [a playbook] during the early stages of the incident," and the agency declined to say how much that cost in response time. Most organisations that run mature product security programs have the same blind spot, with incident processes built around customer facing issues and nothing written down for the day the organisation itself is the victim.
The disclosure failure is the second structural lesson, and it is arguably worse than the leak. Per CISA's report, the researcher tried the contractor directly, then CISA's vulnerability disclosure platform, which is scoped to vulnerabilities affecting the broader community rather than CISA itself, and finally resorted to a journalist. Highly privileged federal cloud keys stayed live because a researcher acting in good faith could not find a door. Help Net Security notes the sequencing that followed: six days after the postmortem, CISA and four allied cyber authorities published guidance telling software suppliers to build coordinated vulnerability disclosure programs, publish a policy, adopt a security.txt file per RFC 9116, set the widest possible testing scope, acknowledge researcher outreach within two to three business days, and separate disclosure triage from customer support channels. That last recommendation is CISA's own failure rewritten as advice.
Third, the exposure vector sits entirely outside the enterprise perimeter. A contractor's personal GitHub account is not covered by an organisation's repository controls, branch protections, or secret scanning. Credential hygiene inside the build pipeline is what determined the blast radius here, not perimeter defence.
One note on scope for readers cross referencing coverage: Tenable's analysis of the coordinated attacks on US water and wastewater systems and CISA advisory AA26-097A concerns a separate, unrelated campaign against internet exposed PLCs across at least 12 states. No source connects that activity to this credential exposure, and nothing in CISA's postmortem suggests a link.
The Attack Technique
There is no attack technique in the traditional sense, and defenders should resist the pull to frame it as one. The root cause CISA documents is an authorised insider making a convenience decision: a contractor copied an internal build and deployment repository to a personal GitHub account so they could provision cloud infrastructure on their own, and long lived static admin and build credentials were embedded in that code and went public with it.
The realistic threat model is the one GitGuardian's business exists to demonstrate. Public repositories are continuously scanned at scale, by defenders and by adversaries, using the same techniques. In this case a scanning vendor found it first and reported it. If the discovery order had been reversed, an attacker would have held administrative credentials to three GovCloud servers, per Krebs, plus plaintext passwords for dozens of internal systems, with no exploitation required. The relevant MITRE ATT&CK behaviour is unsecured credentials in repositories (T1552.001) leading directly to valid accounts (T1078.004), with the compromise chain skipping initial access entirely.
CISA's remediation set, per its report and CyberScoop's summary, maps to exactly this pattern: rotation of all agency secrets after the incident, a plan to improve secrets management, and use of endpoint detection and response capabilities to monitor and manage uploads to public repositories from agency endpoints.
What Organizations Should Do
Scan for your own secrets in public repositories, continuously and by organisation domain. Do not limit scanning to repositories you own. The exposure here was on a personal account with no organisational link, found only because a third party was scanning everything. Search for your internal hostnames, account IDs, and project code names, not just credential patterns.
Eliminate long lived static cloud credentials in build pipelines. The admin keys in "importantAWStokens" were valuable because they were durable and standing. Move build and deployment to short lived, federated credentials via OIDC or role assumption, so a leaked artifact carries nothing usable an hour later.
Rehearse full secret rotation and measure the clock. CISA acknowledged that rotation took longer than anticipated because of system complexity and partner interconnections, and Krebs puts the delay past 48 hours for the AWS keys. Inventory which secrets you could rotate today, time an exercise, and treat anything you cannot rotate inside a few hours as an open risk.
Publish a disclosure channel for incidents affecting you, distinct from product vulnerability reporting. Follow the joint CVD guidance CISA co authored: a public policy page, a security.txt file per RFC 9116, a stated acknowledgement window of two to three business days, and triage separated from customer support. A researcher should never need a journalist as a fallback.
Write the playbook for the incident where you are the victim. CISA's most quoted admission is that it built its playbook during the incident. Prepare playbooks for all anticipated scenarios in advance, including contractor caused exposure, credential leaks, and third party notification intake.
Extend monitoring and policy to contractor and personal development workflows. Apply EDR based controls on uploads to public repositories from managed endpoints, as CISA has now committed to doing, and pair that with contractual and onboarding controls covering where contractors may store organisational code.
Verify your logging can actually answer the question afterward. CISA's assurance that credentials were never used outside its environments rests entirely on SOC telemetry it happened to have. Confirm you retain cloud control plane and identity logs long enough, and in enough detail, to prove non use across a six month exposure window.
Sources: CISA's Response to Exposed AWS GovCloud Keys: A Deep Dive (2026) | Lessons from CISA's Cyber Incident | Minnesota Water Cyber Attack and CISA Advisory AA26-097A | Lessons Learned from CISA’s Recent GitHub Leak – Krebs on Security | CISA Details Incident Response to Exposed AWS GovCloud Keys - Infos... | US cybersecurity agency CISA had to build its incident playbook dur... | CISA folds its own hard-won lessons into coordinated vulnerability... | CISA credential leak prompts tighter security measures CyberScoop