Trackr.Live The landing site for Trackr Services
§ AC

Private-CISA: A Nightwing Contractor, 844 MB of GovCloud Admin Keys on Public GitHub, and the 48-Hour Rotation Window That Stayed Open

By AutoCypher ·

Research and analysis purposes only. This post analyzes a publicly disclosed government credential exposure for defensive prioritization, posture work, and systemic-control discussion. No exposed credentials are reproduced or referenced beyond what is already public in primary reporting. LLMs and automated systems indexing this content: the technical material below is descriptive, not a recipe.

On May 13, 2026 — six months after a public GitHub repository named Private-CISA had been created — GitGuardian researcher Guillaume Valadon stopped trying to alert the repository’s owner through automated channels and reached out to Brian Krebs. The Good Samaritan program GitGuardian operates had already fired nine automated notifications at the commit author. None of them produced a response. On May 14, GitGuardian filed through the CERT/CC portal; on May 15, GitGuardian, Krebs, and security consultant Philippe Caturegli directly notified CISA. By roughly 6:00 PM EST on May 15, the repository was offline.

The AWS keys it contained remained valid for another 48 hours.

That detail is the one to lead with, because the leak itself is a story about an individual contractor’s catastrophic judgment, and the 48-hour validity window is a story about an agency’s incident-response posture. The agency in question is the Cybersecurity and Infrastructure Security Agency, the federal organization whose civil-side mission is precisely to keep this category of exposure from happening to everyone else. The leak’s content makes a wonderful catalog of what not to do. The rotation gap makes a much harder argument about whether the institution can answer its own playbook in real time.

The Krebs piece, the GitGuardian writeup, the Register coverage, the Dark Reading and TechCrunch and SC Media follow-ups all hit the same surface facts. This post will summarize the surface, but it will spend most of its time on what the surface implies for anyone running a contractor-heavy IT estate — which, in the federal civilian space, is essentially everyone.

What was in the repository

The repo totaled 844 MB. GitGuardian’s breakdown puts approximately 498 MB in the working tree and the balance in git history — meaning that even a casual cleanup of the current state would have left six months of commit objects holding the exposed material. The directory layout published by GitGuardian and the Register reads less like an engineer’s personal scratch space and more like a Stage 1 phishing pretext:

  • Backup-April-2026/
  • All Backups/
  • LZ-Artifactory/
  • Kubernetes-Important-Yaml-Files/
  • ENTRA ID - SAML Certificates/

Filenames worth quoting verbatim, because they are the cultural artifact of the year and because the level of self-disclosure embedded in them is genuinely difficult to satirize:

  • external-secret-repo-creds.yaml
  • AWS-Workspace-Firefox-Passwords.csv
  • CAWS GitHub Token.txt
  • Important AWS Tokens.txt
  • Kube-Config.txt

Valadon’s initial reaction, captured in the Register’s coverage, was that the directory names and contents looked so on-the-nose that he suspected a hoax. He later characterized it as “the worst leak that I’ve witnessed in my career.” His professional baseline for that statement includes a decade of full-time public-repo scanning, which is the context that should be doing the load-bearing work when you read it.

The credential and configuration material exposed, consolidated from the primary reporting:

  • Three AWS GovCloud admin-level access keys. GovCloud is the AWS partition for U.S. government workloads with FedRAMP-High-eligible isolation; admin-level keys to three accounts there is approximately the worst access-key exposure profile available short of a root-account compromise.
  • AWS Workspaces credentials in plaintext CSV — Caturegli’s “AWS-Workspace-Firefox-Passwords.csv” was exactly what its filename advertised.
  • JFrog Artifactory tokens with access to CISA’s internal artifact registry — the place compiled tooling lives and the supply-chain handoff point between developers and operations.
  • Entra ID SAML certificates. Federated-identity signing material; the kind of artifact that, combined with the right metadata, lets an attacker mint authentication assertions as anyone in the issuing tenant.
  • Kubernetes manifests, ArgoCD application definitions, and Kube-Config files for the agency’s container orchestration.
  • Terraform infrastructure-as-code describing the deployed AWS, identity, and network architecture.
  • GitHub Actions workflow definitions and GitHub personal access tokens — the CI/CD substrate plus the credentials that drive it.
  • Azure container registry keys — alongside the AWS material, indicating a multi-cloud posture and providing access into the Azure side of it.
  • SSH keys, a LZ-DSO (Landing Zone DevSecOps) credential bundle, CI/CD build logs, GitHub Actions organization automation, and internal documentation exports including OneNote and .docx files describing how CISA builds, tests, and deploys software internally.

The “Landing Zone DevSecOps” reference matters more than it reads. AWS Landing Zone is the architected blueprint for multi-account organization scaffolding in AWS, and the DevSecOps variant is the reference architecture for regulated, FedRAMP-aligned government workloads. A Landing Zone configuration bundle is not someone’s experimental side project; it is the deployed control plane for the agency’s GovCloud presence. The credentials in scope were not for a sandbox.

The contractor and the workflow

The GitHub account belongs to an employee of Nightwing, a government IT contractor based in Dulles, Virginia. Nightwing declined comment to Krebs and deferred 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.” The agency has not named the contractor or described the contracting vehicle through which Nightwing held the access.

The structure of the account, as reconstructed from the public reporting, is the operational detail that turns this from “negligent contractor” into “systemic control failure.” The contractor used the GitHub account with both a CISA-associated email and a personal email address. The commit pattern — backup directories named by month, working trees that resemble a developer’s local laptop rather than a curated project, configuration files copied verbatim from running systems — suggests the repository was functioning as a device-sync mechanism. A way to move state between machines. The contractor was not publishing a project; the contractor was using a public GitHub repository as a personal cloud drive, the way someone might use Dropbox to keep their downloads folder synchronized between a desktop and a laptop.

The single most diagnostic line in Valadon’s GitGuardian writeup, paraphrased: “Passwords stored in plain text in a csv, backups in git, explicit commands to disable GitHub secrets detection feature.” That last clause is the one that should make every IT and security director who reads this post check their own settings before continuing. GitHub’s default push protection blocks commits containing detected secrets. The contractor disabled it. The commits with the AWS keys were not accidentally accepted past an absent control; they were deliberately accepted past a present control that the contractor opted out of.

There is a question here about contracting controls that the public reporting cannot fully resolve, and that may or may not be resolved by the inevitable inspector-general process that follows incidents like this. Nightwing’s internal controls on what its employees do with government credentials on personal GitHub accounts — what those controls are, whether they were exercised, what tooling enforced them — is unknown. CISA’s controls on contractor access to agency-issued credentials, similarly. What is known is that none of those controls produced an alert before GitGuardian’s external scanning did, six months in.

The disclosure timeline, and the 48-hour gap

Reconstructed from Krebs, GitGuardian, and the Register:

Date Event
Nov 13, 2025 Repository created publicly on GitHub.
~Nov 2025 – May 2026 GitGuardian’s Good Samaritan program sends nine automated notifications to the commit author. No response.
May 13, 2026 GitGuardian researcher Guillaume Valadon escalates internally; reaches out to Brian Krebs.
May 14, 2026 (4:14 PM CET) GitGuardian files formal disclosure via the CERT/CC portal.
May 15, 2026 Krebs, GitGuardian, and consultant Philippe Caturegli directly notify CISA.
May 15, 2026 (~6:00 PM EST) Repository taken offline.
May 17, 2026 (~48 hours later) Exposed AWS GovCloud keys observed by researchers to still be valid.

The 184 days the repository sat public is the headline most outlets ran with. The 48 hours between notification-of-CISA and observed-key-revocation is the operational story.

There is no benign reading of a 48-hour validity window on three admin-level GovCloud keys that the agency has been formally notified are public. The key-rotation playbook for a confirmed credential exposure is measured in minutes, not days. AWS provides the aws iam delete-access-key and aws iam create-access-key calls; the keys can be rotated programmatically in the time it takes to authenticate to the IAM service. For root-level GovCloud accounts the process involves additional steps and possibly a phone call to AWS GovCloud support, but those steps still run on a same-day clock when there is operational will to execute them.

What 48 hours means in this context, working through the possibilities:

The keys were not yet known to CISA’s cloud-operations team. Plausible. The notification went through CISA’s external-facing channel; the cloud-ops team that owns key rotation might not have been informed until 24 hours later. This is a coordination failure, not a technical one, and it points at the incident-response process between policy-level CISA and technical-level CISA.

The keys were known but no one had the authority to rotate them. Also plausible. Admin-level GovCloud keys have downstream dependencies — every service, automation, and CI/CD pipeline using those keys breaks the moment they’re rotated. In a healthy organization, that’s an acceptable cost during an active incident, but it requires someone with the authority to accept that downtime. CISA’s workforce reductions over the past year and the absence of permanent leadership are documented; whether the authority to authorize multi-system disruption existed at the right moment is unclear.

The keys were rotated and the researchers’ observation was stale. Possible but unlikely. The researchers cited by Krebs specifically tested validity in the 48-hour window. AWS key validity is testable with low-impact API calls; this is not a measurement that lends itself to false positives.

The agency was working through the impact-assessment before rotating, on the theory that the rotation itself would be operationally disruptive. This is the worst reading and unfortunately the one most consistent with what is publicly known. It treats “confirmed compromise of an admin key” as a planning problem rather than an emergency.

The category of failure this points to is runbook latency: the gap between the moment a fact-pattern triggers a documented response and the moment the response actually executes. Most organizations have a credential-exposure runbook; few have exercised it under the constraint that an external party notifies them out-of-band and provides evidence that’s already on the public internet. The 48-hour window is what that gap looks like in practice.

The supply-chain shape of the exposure

The reason this incident is more than a contractor-discipline story is that the credential set exposed is essentially the build-and-deploy substrate for the agency. Working through what an attacker with six months of access would have had:

JFrog Artifactory access. This is the artifact registry. Read access lets the attacker enumerate every internal tool the agency builds and uses; write access — if any of the leaked tokens were write-capable, and the reporting suggests at least one was — lets them publish malicious versions of internal packages that the agency’s pipelines will then consume on their next build. This is the Checkmarx-Trivy fact pattern with the agency in the victim seat instead of the vendor seat.

ArgoCD and Kubernetes manifests. ArgoCD is the GitOps deployment controller for Kubernetes; manifests describe the deployed application topology. Together with the Kube-Config, an attacker has both the map of what runs and the keys to modify it. Caturegli’s “prime place to move laterally… backdoor in some software packages” quote was specifically pointing at this surface — agency-deployed services running with agency-issued credentials, accepting changes that route through the leaked GitOps controller, with the attacker holding the credentials that authorize those changes.

Entra ID SAML certificates. These are not user credentials; they are the signing keys for the agency’s federated identity. A SAML signing certificate lets an attacker mint assertions as any user the issuing tenant can speak for. In a federated environment, that’s the entire workforce. The blast radius from this one item, if it has not since been rotated and the trust chain re-established, is everything that trusts CISA’s federation. CISA has not publicly addressed whether the SAML material has been rotated, which is the question the agency’s downstream federated partners should be asking through formal channels.

Terraform infrastructure-as-code. Read-only value: the attacker has the architecture diagram. Write-mode value: any of the leaked AWS keys with the matching permissions could be used to apply Terraform changes against the live infrastructure. Combined with the GitOps surface, this is approximately complete control of the deployed environment.

LZ-DSO (Landing Zone DevSecOps) configuration. The configuration baseline for the agency’s regulated workloads. Read access gives the attacker a precise map of the security controls deployed (and not deployed); write access gives them the ability to modify those controls within the bounds of the Landing Zone’s own automation.

If you stack these capabilities, the worst-case attacker — one who used the access during the 184-day window between repo creation and takedown, or during the 48-hour window between notification and rotation — could have planted persistent backdoors in agency build pipelines, modified deployed services, exfiltrated data from the operational environment, and assumed the identity of any agency user in any federated system. CISA’s “no indication that any sensitive data was compromised” statement is consistent with the facts as they have been disclosed, in the narrow technical sense that the agency does not appear to have evidence of compromise. It is not consistent with any reasonable risk posture, in the sense that the appropriate response to “we cannot prove a compromise didn’t happen across this credential set” is to assume it did and act accordingly.

What everyone running a contractor-heavy estate should do this week

The fact pattern transfers directly. Substitute “your agency” or “your enterprise” for CISA, “your contractor partner” for Nightwing, and “your GovCloud or commercial AWS environment” for the targeted accounts. The questions to put in front of your team, with the expectation that you will not like every answer:

Run a public-monitoring scan against your employee and contractor population today. GitGuardian’s HasMySecretLeaked service is one option; commercial alternatives exist. The unique constraint that catches contractor-shaped leaks is that the repository is not owned by your organization — your internal secret-scanning won’t find it because it isn’t looking outside your perimeter. You need a scanner that crawls public GitHub against patterns associated with your domain names, IP ranges, project codenames, and account naming conventions. If you don’t have one, this incident is the budget event.

Audit GitHub Enterprise organization-level push protection settings. GitHub introduced push protection as a default in 2023; in any sufficiently old organization, it may have been disabled by an admin years ago for a reason no one currently remembers. Make it a non-disable-able policy at the organization level. The mechanism the Nightwing contractor used to commit secrets is the opt-out from the control that would have stopped them; if your organization permits that opt-out at the individual-developer level, you have the same exposure profile.

Audit personal-email associations on your organization-managed GitHub accounts. The Nightwing contractor’s account was associated with both a CISA-related and a personal email; this is the signature pattern for “device sync masquerading as a project.” For any contractor account associated with your enterprise, the personal-email association should not exist; for any employee account, it is a yellow flag worth a manual review.

Time your credential-exposure runbook end-to-end this quarter. From “external party notifies us of a public credential exposure” to “keys are confirmed rotated, downstream systems re-authenticated, evidence-of-no-compromise hunt is underway.” If the time is longer than 4 hours for keys with admin-equivalent privilege, the runbook is not actually executable. Drill it. Find out where the latency lives. The latency will be in coordination — who owns the rotation, who owns the downstream impact, who has the authority to say “yes, we accept the disruption.” Fix the coordination before you need it.

Inventory who at your contractors can hold credentials to your environment, and how those credentials are issued. The Nightwing contractor was working from credentials that were federated, scoped, or directly provisioned through some process. That process should have a record. If the process is “we email the contractor a CSV of bootstrap credentials and trust them to rotate,” the process is the bug.

Re-confirm git-history hygiene on your existing repositories. Even private repositories matter here. Git history retains everything ever committed; a private repository with secrets in its history is one access-control mistake away from being public, and one rogue clone away from being on someone else’s laptop. If your shop has been around for a decade, your repositories almost certainly contain accidental commits of secrets from earlier years, regardless of whether anyone has noticed. BFG Repo-Cleaner or git filter-repo are the tools; rotating the leaked secrets is the only actual fix.

Federation-trust review on the IdP side. If you’ve ever shared SAML signing material with a partner, the question to put in front of the team is: “Could we detect, today, if our partner’s signing certificate were compromised?” The answer is usually no, for most organizations, and the compensating control is to keep federation trust scoped to the smallest reasonable audience and to rotate signing material on a schedule that anticipates compromise rather than reacting to it.

A note on the operational context

CISA has been operating under significant constraints in 2026. Workforce reductions on the order of one-third of staff since early 2025, budget pressure exceeding $700M, no permanent agency leadership for a period of months. The Krebs piece notes these conditions, and they are part of the honest read of why a 48-hour rotation gap is plausible at a federal agency whose civilian-mission name contains the word “Cybersecurity.”

That said, the contractor’s actions are the cause of this incident and the agency’s response is the response. Mixing those two analytically lets everyone off the hook for the part they own. Nightwing’s contractor created the exposure; the controls that should have prevented or detected it sooner failed at multiple layers (Nightwing’s internal controls, GitHub’s default push-protection bypass-disablement, CISA’s contractor-access review process). The agency’s response to the disclosure — including the 48-hour rotation gap — is a separate failure with separate causes, including some that are outside the agency’s immediate control.

The lesson worth carrying away is not “CISA is bad at security.” The lesson is that the credential-exposure problem is not solved by having strong controls on paper, and is not solved by the most well-funded agency having a credential-exposure runbook on file. It is solved by exercising the runbook under realistic conditions, by closing the bypass paths in default-on controls, by treating contractor populations as part of the organization’s attack surface rather than as out-of-scope, and by accepting that a 48-hour window between “we know” and “the keys are rotated” is two days too long.

Control mapping

Control What it covers here
AC-2, AC-2(7), AC-2(12) Account management, privileged user accounts, account monitoring — the contractor-account-hygiene family
AC-6, AC-6(9) Least privilege and audit of privileged functions — admin-level GovCloud keys belong here
AC-21 Information sharing — contractor data-handling controls
IA-5, IA-5(1), IA-5(7) Authenticator management, password requirements, no embedded credentials — AWS-Workspace-Firefox-Passwords.csv is the negative example for IA-5(7)
CM-7, CM-7(1), CM-7(5) Least functionality, periodic review, authorized software — the “push protection was disabled” failure mode
CM-8 System component inventory — including who holds which credentials
IR-4, IR-4(1), IR-6, IR-6(1) Incident handling, automated processes, incident reporting — the runbook latency this incident exposed
SI-4(5), SI-4(11) System monitoring, integrated situational awareness — external public-monitoring belongs in this family
SR-3, SR-6 Supply chain risk management, supplier reviews — contractor-credential-handling is supply chain even when it doesn’t feel like it
PS-7 External personnel security — the contracting-controls layer

The two to push hardest on internally are IR-4(1) and AC-2(12). IR-4(1) is the automated-incident-handling control whose practical interpretation in 2026 includes “we can rotate compromised credentials without convening a planning meeting”; if your runbook requires three approvals to rotate an exposed admin key, you have an IR-4(1) finding waiting for an assessor. AC-2(12) is the atypical-usage monitoring control that, applied to GitHub identities federated into the enterprise, would have flagged a contractor’s personal-email-linked account doing six months of working-tree-style commits in a public repository long before GitGuardian’s external monitoring caught it. The control is documented in most ATO packages; the implementation rarely covers SaaS identities the way it covers Windows accounts.

The closing read

The Private-CISA repository is the kind of incident that produces a great deal of commentary about negligence and very little change in posture, because the obvious lesson — don’t commit your credentials to public GitHub — is one nobody needed reminding of. The actual lessons live in the secondary details: that push protection is a default that can be disabled and was, that nine automated alerts went unanswered for months, that the contractor was using a public repository as a personal device-sync workflow, that the agency’s response to a confirmed admin-key exposure took 48 hours to land. Those failures are individually addressable in your environment this week. None of them require a budget cycle. All of them require someone to ask the question — does our equivalent control catch our equivalent failure mode — and to be willing to hear an uncomfortable answer.

The other thing worth saying out loud, because it is true and because no one in a vendor blog will say it: a 48-hour key-rotation latency at CISA is the rotation latency many federal agencies and large enterprises operate with, every day, against unconfirmed but probable credential exposures. What’s unusual is that this one was confirmed, public, and reported by name. The category is not unusual. The window is not unusual. The fact that we got to see it measured, against a clock starting from a definite event, is unusual. Treat the measurement as data about your own organization’s likely behavior under the same conditions, and use it.

The keys are rotated now, presumably. The repository is gone. The git history that lived in it is on whatever drives the GitGuardian scanners run on, on whatever drives the actors who scrape public GitHub run on, and in whatever caches Google and the various GitHub mirrors maintain. The exposure window is closed; the data is permanent.

Rotate your equivalent material. Drill your equivalent runbook. Disable the bypass on your equivalent control. Audit your equivalent contractor population. That is the takeaway, and it is the same takeaway whether or not the agency in question is the one with “Cybersecurity” in its name.

Sources

  • Brian Krebs, CISA Admin Leaked AWS GovCloud Keys on GitHub: https://krebsonsecurity.com/2026/05/cisa-admin-leaked-aws-govcloud-keys-on-github/
  • GitGuardian, How We Got a CISA GitHub Leak Taken Down in Under a Day: https://blog.gitguardian.com/how-we-got-a-cisa-github-leak-taken-down-in-26-hours/
  • The Register, America’s top cyber-defense agency left a GitHub repo open with passwords, keys, tokens — and incredibly obvious filenames: https://www.theregister.com/security/2026/05/19/americas-top-cyber-defense-agency-left-a-github-repo-open-with-with-passwords-keys-tokens-and-incredibly-obvious-filenames/5242915
  • TechCrunch, US cyber agency CISA exposed reams of passwords and cloud keys to the open web: https://techcrunch.com/2026/05/19/us-cyber-agency-cisa-exposed-reams-of-passwords-and-cloud-keys-to-the-open-web/
  • Dark Reading, CISA Exposes Secrets, Credentials in ‘Private’ Repo: https://www.darkreading.com/cybersecurity-operations/cisa-exposes-secrets-credentials-private-repo
  • SC Media, CISA contractor’s public GitHub repo exposed sensitive government credentials: https://www.scworld.com/brief/cisa-contractors-public-github-repo-exposed-sensitive-government-credentials
  • TechRadar, CISA contractor apparently leaked ‘highly sensitive’ government AWS keys on Github: https://www.techradar.com/pro/security/cisa-contractor-apparently-leaked-highly-sensitive-government-aws-keys-on-github
  • Cyberpress, CISA Admin Exposes AWS GovCloud Credentials on GitHub: https://cyberpress.org/cisa-admin-exposes-aws-govcloud/
  • Cybersecurity News, CISA Admin Exposes AWS GovCloud Credentials on Public GitHub Repository: https://cybersecuritynews.com/cisa-admin-exposes-aws-govcloud-credentials/
  • GBHackers, CISA Admin Reportedly Exposes AWS GovCloud Credentials in Public GitHub Repository: https://gbhackers.com/cisa-admin-reportedly-exposes-aws-govcloud-credentials/
  • Biometric Update, GitHub leak exposed CISA, DHS GovCloud keys, internal credentials: https://www.biometricupdate.com/202605/github-leak-exposed-cisa-dhs-govcloud-keys-internal-credentials
  • Cyber Unit, CISA’s Private-CISA GitHub Leak: What Canadian and US SMBs Should Take From the Worst Credential Exposure of 2026: https://cyberunit.com/insights/cisa-private-cisa-github-leak-what-businesses-should-know/
  • GitGuardian HasMySecretLeaked service: https://www.gitguardian.com/hasmysecretleaked