CISA GitHub Data Leak
Published: May 19, 2026 — 14:30 EST
The headline writes itself: the agency responsible for protecting U.S. government infrastructure from cyberattacks left its own AWS GovCloud credentials, plaintext passwords, and DevSecOps architecture exposed in a public GitHub repository for 183 days.
But the story buried inside the story is this: after the repository was taken offline on May 15, 2026, the exposed AWS credentials remained fully valid and functional for another 48 hours. Security researcher Philippe Caturegli confirmed they still worked after takedown. For two full days, anyone who had already cloned or bookmarked the credentials — during six months of public availability — retained working administrative access to three U.S. government cloud environments.
That detail changes the risk calculus of this incident entirely. And almost no coverage of this story has treated it as the lead.
Here is the complete technical breakdown — what was exposed, what it enables, why every defense layer failed, and what it means for the 43 other federal agencies sharing infrastructure dependencies with CISA.
Table of Contents
The Exact Timeline: 183 Days of Public Exposure
On November 13, 2025, the Public GitHub repository named “Private-CISA” was created by a contractor working for Nightwing, a government services firm based in Dulles, Virginia. The repository remained publicly accessible until May 15, 2026 — a period of approximately 183 days.
GitGuardian’s automated scanning systems detected the exposure on May 14, 2026. The Good Samaritan program had already sent nine automated alert emails to the commit author by May 13 — none received a human response, only an automatic acknowledgment.
GitGuardian reported the leak through the CERT/CC portal on May 14 at 4:14 PM CET. With no response by the morning of May 15, researcher Guillaume Valadon contacted Brian Krebs to use his direct contacts at CISA, and activated additional partners for a direct line. CISA was reached directly around 16:00 CET on May 15. The repository went offline around 6:00 PM EST on May 15, 2026.
The disclosure-to-takedown window was approximately 26 hours from GitGuardian’s direct contact with CISA. That is genuinely fast, and credit is due. What is not fast: the credential revocation that should have happened simultaneously did not.
The GitHub account and exposed passwords were taken offline shortly after KrebsOnSecurity and Seralys notified CISA — but Caturegli confirmed the exposed AWS keys inexplicably continued to remain valid for another 48 hours after takedown.
Removing a GitHub repository does not revoke cloud credentials. These are separate actions requiring separate systems. That 48-hour gap is the interval during which anyone who had already extracted the credentials retained full administrative access to CISA’s GovCloud environments. CISA’s public statement — “currently, there is no indication that any sensitive data was compromised” — cannot account for access that occurred during a window the agency itself may not be able to fully audit.
What Was Inside: The Complete Inventory
The repository held 844 MB of data across the working tree and Git history. The working tree was 498 MB; the remainder was Git history and objects.
This is not a leak of a single misconfigured configuration file. It is a comprehensive operational archive. The repository contained CI/CD build logs and deployment workflow documentation; Kubernetes manifests, ArgoCD application files, and secret-related YAML files; Terraform infrastructure code and related bundles; GitHub Actions workflows and GitHub organization automation; internal documentation backups including large OneNote and .docx exports; scripts for GitHub, Kubernetes, ArgoCD, and infrastructure operations; and references to AWS accounts, IAM identities, service accounts, internal service endpoints, registry locations, and secret-management paths.
The file names alone tell the story. Directory names included Backup-April-2026/, All Backups/, LZ-Artifactory/, Kubernetes-Important-Yaml-Files/, and ENTRA ID - SAML Certificates/. File names included external-secret-repo-creds.yaml, CAWS GitHub Token.txt, Important AWS Tokens.txt, AWS-Workspace-Firefox-Passwords.csv, and Kube-Config.txt.
One file titled “importantAWStokens” included administrative credentials to three Amazon AWS GovCloud servers. A file named “AWS-Workspace-Firefox-Passwords.csv” listed plaintext usernames and passwords for dozens of internal CISA systems — including one called “LZ-DSO,” which appears to stand for “Landing Zone DevSecOps,” the agency’s secure code development environment.
The contractor also used easily guessed passwords for a number of internal resources — many credentials used a password consisting of each platform’s name followed by the current year. “Artifactory2026,” “ArgoCD2026,” and similar patterns would be trivially brute-forced in minutes even without public exposure.
The Supply Chain Attack Vector No One Is Covering
Every news report on this incident has focused on the credential exposure. The more dangerous long-term risk is different, and it comes from a single sentence in Philippe Caturegli’s analysis that deserves its own section.
Caturegli confirmed that the archive includes plaintext credentials to CISA’s internal Artifactory — essentially a repository of all the code packages the agency uses to build software. He described this as a prime target for malicious attackers looking for ways to maintain persistent access: “That would be a prime place to move laterally. Backdoor in some software packages, and every time they build something new, they deploy your backdoor left and right.”
To understand why this matters: Artifactory is a universal artifact repository manager. In a typical government DevSecOps environment like CISA’s LZ-DSO, Artifactory is the single source of truth for every code dependency — every library, every build tool, every infrastructure package — that goes into production software. It is the upstream source for everything CISA builds and deploys.
If an attacker gained access to CISA’s Artifactory using the exposed credentials during the 183-day window:
- They could have modified existing packages already in the repository — injecting malicious code that would be pulled and built into production deployments automatically.
- They could have added new malicious packages with names mimicking legitimate dependencies (dependency confusion attack).
- The backdoor would propagate forward on every new build, across every system that pulls from that Artifactory instance.
- Detection would be extremely difficult because the artifact signatures appear legitimate — they come from CISA’s own trusted build system.
This is not a theoretical attack vector. The Solarwinds supply chain attack — which compromised 18,000 organizations including multiple U.S. federal agencies — used exactly this mechanism: injecting malicious code into a legitimate build pipeline such that signed, trusted software deliveries carried the attacker’s payload.
CISA’s Artifactory credentials were publicly exposed for 183 days. Whether those credentials were used is a forensic question the agency has not publicly answered.
The Defense-in-Depth Failure Map
Seven independent security controls existed that could have prevented or detected this incident. All seven failed. Understanding the failure sequence is the analytical framework that transforms this from an embarrassing anecdote into a systemic lesson.
Layer 1 — GitHub Secret Scanning (DISABLED DELIBERATELY)
GitHub’s default setting blocks users from publishing SSH keys or other secrets in public code repositories. The commit logs show the contractor explicitly disabled this protection before pushing sensitive data. This is not a misconfiguration. It is an intentional override of a default-on safety control.
Guillaume Valadon: “Passwords stored in plain text in a CSV, backups in git, explicit commands to disable GitHub secrets detection feature. I honestly believed that it was all fake before analyzing the content deeper. This is indeed the worst leak that I’ve witnessed in my career.”
What should have happened: GitHub’s push protection (distinct from secret scanning) would have blocked the push entirely if enabled at the organization level — preventing the upload before it reached public visibility. Organization-level enforcement would have overridden the individual user’s setting change.
Layer 2 — Contractor Repository Governance (ABSENT)
Caturegli observed that “the use of both a CISA-associated email address and a personal email address suggests the repository may have been used across differently configured environments.” The contractor was using a personal GitHub account — created in September 2018 — not a managed organizational account under CISA’s GitHub organization.
What appears to have happened: the contractor was using this GitHub repository to synchronize files between a work laptop and a home computer, with regular commits since November 2025.
What should have happened: Federal contractors handling CUI (Controlled Unclassified Information) or systems access should operate exclusively on government-managed or contractor-managed accounts subject to organizational policy enforcement. Personal GitHub accounts used to sync government credentials should not be possible in a properly governed environment.
Layer 3 — Credential Rotation and Expiry Policies (ABSENT)
Long-lived static credentials are the root condition that made this incident catastrophic rather than merely embarrassing. AWS GovCloud supports IAM roles with temporary credentials (STS tokens that expire in 15 minutes to 12 hours), hardware security keys, and automated credential rotation through AWS Secrets Manager. If the exposed credentials had been short-lived or rotated automatically, they would have been expired and valueless long before the repository was discovered.
Instead: administrative credentials to three GovCloud accounts were valid for at least 183 days of public exposure, plus an additional 48 hours after the repository was removed.
Layer 4 — Continuous Monitoring for Exposed Secrets (ABSENT AT CISA)
GitGuardian — a private security firm — was the entity that discovered this exposure, not CISA’s own monitoring systems. The agency responsible for defending U.S. government cybersecurity had no internal capability that detected its own credentials appearing in a public code repository for over six months.
NIST Special Publication 800-53, Revision 5 — the federal security control framework that CISA itself maintains and promotes — includes control SI-7 (Software, Firmware, and Information Integrity) and AU-6 (Audit Record Review, Analysis, and Reporting), both of which provide the basis for continuous monitoring requirements that this incident demonstrates were not operationally implemented.
Layer 5 — Insider Threat Detection (INEFFECTIVE)
The contractor’s behavioral pattern was anomalous and detectable: regular commits to a public repository containing government system references, from a personal account, over six months. User and Entity Behavior Analytics (UEBA) systems — which CISA recommends to other agencies — should have flagged this pattern.
Layer 6 — Principle of Least Privilege (VIOLATED)
Caturegli confirmed the exposed credentials authenticated to three AWS GovCloud accounts “at a high privilege level.” A contractor performing DevSecOps development work should not hold standing administrative credentials to production GovCloud environments. Just-in-time privilege escalation — temporary elevated access granted only for specific tasks and automatically revoked — is standard security practice and would have limited blast radius even if credentials were exposed.
Layer 7 — Post-Incident Credential Revocation (DELAYED 48 HOURS)
Even after the breach was confirmed and the repository removed, the affected credentials remained active for an additional 48 hours. This is the final defense layer, the last backstop — and it failed. An automated incident response playbook would have initiated credential rotation as the simultaneous first step with repository removal, not a separate action taken days later.
The Institutional Context: CISA’s Diminished Oversight Capacity
This incident does not occur in a vacuum. CISA has shed nearly one-third of its workforce since the beginning of the second Trump administration — from approximately 3,400 employees to around 2,400 by late 2025 — through a combination of forced retirements, voluntary buyouts, and resignations. Its operational budget faces a proposed reduction of over $420 million, with cuts targeting cybersecurity operations, training programs, and the National Risk Management Center.
This incident is not isolated. Earlier in 2026, acting CISA director Madhu Gottumukkala uploaded sensitive documents to the public version of ChatGPT, exposing the agency to potential data risk.
The workforce reduction matters for contractor oversight specifically. Federal agency security is not solely a function of the contractors CISA employs — it is a function of the government employees who supervise, audit, and enforce policy on those contractors. When oversight capacity shrinks by 30%, the probability of supervision gaps increases proportionally.
Nightwing declined to comment, directing all inquiries to CISA. CISA’s official statement: “Currently, there is no indication that any sensitive data was compromised as a result of this incident. While we hold our team members to the highest standards of integrity and operational awareness, we are working to ensure additional safeguards are implemented to prevent future occurrences.”
“No indication of compromise” is not the same as “confirmed no compromise.” It means CISA’s current forensic capability has not found evidence of exploitation. Given that the credentials were live for 183 days and remained valid 48 hours after takedown, the absence of detected exploitation reflects the limits of current visibility — not a clean bill of health.
What “No Evidence of Compromise” Actually Means in Practice
This phrase — deployed in nearly every public breach disclosure — deserves technical unpacking.
Detecting unauthorized access to cloud environments requires comprehensive logging (CloudTrail in AWS), log retention policies long enough to cover the exposure window (183 days minimum), active log analysis for anomalous access patterns, and the analytical capacity to distinguish legitimate from unauthorized activity across all three affected GovCloud accounts.
With CISA operating at approximately 70% of its pre-2025 staffing, the forensic investigation required to definitively rule out compromise over a 183-day window across three administrative-level cloud environments — plus all internal systems whose credentials were exposed — is a substantial undertaking. The preliminary statement does not and cannot constitute a completed investigation.
The 48-hour post-removal credential validity window is particularly difficult to audit. Any access during that period, by an entity that had extracted credentials during the prior 183 days, would look identical in logs to routine administrative activity — because the credentials were legitimate credentials until they were finally revoked.
The 9 Systemic Recommendations (Turned Into Policy Obligations)
This is not a problem solved by firing one contractor and issuing a memo. The failure map above identifies seven control layers that must be rebuilt. These are the specific implementations required:
1. GitHub organization-level push protection, mandatory. CISA’s GitHub organization settings should enforce push protection at the organization level, blocking all secret pushes regardless of individual user settings. This is a one-checkbox administrative change that would have prevented this specific incident entirely.
2. Zero personal accounts for government work. Contractors handling any government credentials or systems should be provisioned with managed accounts under CISA’s GitHub organization — with organization-enforced security policies — not permitted to use personal accounts that fall outside policy governance.
3. Short-lived credentials everywhere. AWS GovCloud supports IAM roles with STS temporary credentials. Standing long-lived administrative keys should be eliminated in favor of role-based temporary access. Credentials that expire in 15 minutes cannot be exploited for 183 days.
4. Automated secrets scanning across all repositories. CISA should deploy continuous scanning of all public and private repositories associated with agency-connected email domains — not rely on third parties like GitGuardian to discover exposures. This capability should have detected this within hours of the first push in November 2025.
5. Artifactory integrity audit, immediately. Given that Artifactory credentials were publicly exposed for 183 days, CISA should conduct an immediate integrity audit of every artifact in every Artifactory repository accessible via the exposed credentials — comparing current artifacts against signed hashes from before November 13, 2025. This is non-negotiable if CISA wants to rule out supply chain compromise.
6. Credential revocation as step zero of incident response. The 48-hour revocation delay should be impossible in a functioning incident response playbook. Credential rotation must be the simultaneous first action upon breach confirmation — not a downstream step.
7. Least-privilege enforcement for all contractor accounts. No contractor should hold standing administrative credentials to production GovCloud environments. All privileged access should be just-in-time, task-scoped, and automatically revoked upon task completion.
8. Contractor oversight capacity. The workforce reductions that diminished CISA’s contractor supervision capacity need to be recognized as a direct contributing factor — not treated as a political observation separate from the technical incident.
9. Mandatory NIST 800-53 Rev 5 compliance audit for credential management. CISA should commission an independent compliance audit against NIST 800-53 Rev 5 controls specifically covering credential management (IA-5), least privilege (AC-6), audit logging (AU-2, AU-6), and configuration management (CM-6, CM-7). This incident suggests multiple controls are documented but not operationally enforced.
Historical Context: Where This Ranks
To contextualize the severity, this incident should be compared against the documented catalog of U.S. government credential exposures. The following assessment uses verified public data only:
| Incident | Year | Exposure Type | Duration | Confirmed Exploitation |
|---|---|---|---|---|
| SolarWinds (SUNBURST) | 2020 | Build pipeline compromise | ~9 months | Yes — 18,000 orgs |
| OPM Data Breach | 2015 | Personnel records exfiltration | ~1 year | Yes — 21.5M records |
| NSA Shadow Brokers | 2016–2017 | Offensive tool theft | Unknown | Yes — EternalBlue |
| Treasury/Commerce (SolarWinds) | 2020 | Email/network access | ~9 months | Yes |
| CISA GitHub / Private-CISA | 2025–2026 | Admin credentials, public GitHub | 183 days | Unknown — under investigation |
| Twilio/Okta supply chain | 2022 | Credential phishing cascade | Weeks | Yes — 130+ orgs |
What distinguishes the CISA incident: the credentials were not extracted through sophisticated tradecraft. They were in a public GitHub repository accessible to any unauthenticated user worldwide, indexed by search engines, for 183 days. No attack was required to obtain them. This is the operational security failure mode that Guillaume Valadon called “the worst leak I’ve witnessed in my career” — and he has spent years scanning the internet for exactly this category of exposure.
FAQ: The Questions Every Security Practitioner Is Asking
Were the exposed credentials actually used by an attacker during the 183-day window?
Unknown. CISA’s preliminary statement says no evidence of compromise has been found. However, completing a full forensic investigation covering 183 days of potential access across three high-privilege GovCloud accounts, plus all internal systems, requires CloudTrail log analysis for the full exposure period. CISA has not stated that this analysis is complete. Given that the AWS credentials remained valid for 48 hours after the repository was removed, the investigation window must include that period as well.
What is Nightwing and what is its relationship with CISA?
Nightwing is a government contractor based in Dulles, Virginia, that was spun off from Raytheon’s intelligence and space division. It holds federal contracts for national security and cybersecurity support services. A Nightwing employee maintained the exposed repository. Nightwing declined to comment and directed all inquiries to CISA when contacted by researchers.
Why were the AWS keys valid for 48 hours after the repository was removed?
Removing a GitHub repository is a content action — it makes files unavailable through GitHub’s interface. Revoking AWS credentials is a separate identity action requiring changes in AWS IAM. These are independent systems. Best practice in incident response is to perform both actions simultaneously. The 48-hour gap suggests credential revocation was not part of CISA’s initial response to the takedown and was actioned separately, potentially after additional assessment time. CISA has not commented on this gap specifically.
What is LZ-DSO and why does it matter?
LZ-DSO appears to stand for “Landing Zone DevSecOps” — CISA’s secure software development environment. A Landing Zone in AWS is a pre-configured, security-hardened multi-account environment. Exposure of the DevSecOps environment is particularly severe because it represents the environment in which CISA’s production software is built and tested. Access to this environment could enable an attacker to intercept, modify, or backdoor software under development before it is deployed to production systems.
What is Artifactory and what is the supply chain risk?
Artifactory is a universal artifact repository that stores and manages software dependencies — libraries, packages, container images — used in building applications. In a CI/CD pipeline, every build pulls dependencies from Artifactory. If an attacker gained write access to CISA’s Artifactory using the exposed credentials, they could inject malicious code into any package in the repository. Every subsequent build that pulled those packages would incorporate the malicious code and deploy it to production. This is the Solarwinds attack pattern. Whether CISA has audited its Artifactory contents for the exposure period is unknown.
Has CISA responded to specific questions about these risks?
CISA’s only public statement is: “Currently, there is no indication that any sensitive data was compromised as a result of this incident. While we hold our team members to the highest standards of integrity and operational awareness, we are working to ensure additional safeguards are implemented to prevent future occurrences.” The agency has not responded to specific questions about credential revocation timing, Artifactory integrity, or the duration of the investigation. This article will be updated when CISA provides additional information.
What should other federal agencies do right now?
Any federal agency sharing infrastructure dependencies with CISA — including agencies using CISA-built or CISA-distributed software packages — should verify the integrity of those packages against pre-November 2025 baselines. Any agency with contractors using personal GitHub accounts for work-adjacent activity should conduct an immediate audit. CISA’s own guidance through its Known Exploited Vulnerabilities catalog and Secure Software Development Framework remain valid reference points regardless of this incident.
Marcus Chen is Axis Intelligence’s cybersecurity editor. This article is based on primary reporting from KrebsOnSecurity (Brian Krebs, May 18, 2026), GitGuardian’s disclosure timeline (Guillaume Valadon, May 19, 2026), and Seralys’ credential validation analysis (Philippe Caturegli). All technical claims are sourced to verified primary accounts.
Marcus Chen is the Cybersecurity & Privacy Editor at Axis Intelligence. With over 12 years of experience in enterprise security, he holds CISSP and CISM certifications and previously served as a SOC analyst at a Fortune 500 financial institution. Marcus personally tests every VPN, antivirus, and security tool he reviews, running them through standardized threat simulations in his home lab. He covers cybersecurity tools, VPN reviews, privacy guides, scam analysis, and enterprise security frameworks.
Voice: Technical but accessible. Speaks like a security analyst explaining things to a non-technical colleague. Uses concrete analogies. Never hypes, always measures risk.