On May 19, 2026, TechCrunch reported that a contractor working for the US Cybersecurity and Infrastructure Security Agency (CISA) — the agency that publishes federal guidance on how to not do exactly this — had left a public GitHub repository named Private-CISA exposed to the open internet for roughly six months. The repository contained administrative AWS GovCloud keys, plaintext usernames and passwords for dozens of internal CISA systems, SSH keys, Entra ID SAML certificates, API tokens, and internal log files. Independent security firm GitGuardian first detected the repository on May 14, 2026; researcher Guillaume Valadon escalated it on May 15 after the account owner did not respond to automated exposure alerts.

The contractor has been identified by KrebsOnSecurity as an employee of Nightwing, a government services firm based in Dulles, Virginia. The "Private-CISA" repository was created on November 13, 2025 and remained publicly accessible until mid-May 2026 — about six months in the open. Philippe Caturegli, founder of Swiss security consultancy Seralys, who independently confirmed the keys were live, called it "the worst leak that I've witnessed in my career."

For Canadian and US small and mid-sized business (SMB) leaders, this is not an "Uncle Sam problem." It is a near-perfect, publicly documented case study of the five most common ways credentials leave organizations every week — disabled secret scanning, personal sync repos, files literally named importantAWStokens, plaintext password CSVs, and slow credential revocation after exposure. Every one of those failures is more common in SMBs than in federal agencies, not less.

What Actually Happened With the Private-CISA Repository

A CISA contractor created a personal GitHub repository called "Private-CISA" on November 13, 2025, set it to public, disabled GitHub's built-in secret-scanning push protection, and used it as a personal sync point between work and home machines. Over the next six months it accumulated roughly 844 MB of CISA internal data, including AWS GovCloud administrative credentials, plaintext passwords, SAML signing certificates, and SSH keys, all of which remained openly searchable on the internet until May 15, 2026.

Two files made the leak especially damaging:

  • importantAWStokens — a file containing administrative credentials for three CISA AWS GovCloud environments. GovCloud is the dedicated US-government-only region of Amazon Web Services used for sensitive federal workloads. Administrative keys there grant the holder broad control over the agency's cloud footprint.
  • AWS-Workspace-Firefox-Passwords.csv — a comma-separated file containing plaintext usernames and passwords for dozens of internal CISA systems, exported from a Firefox profile inside an AWS WorkSpaces virtual desktop. According to Caturegli, the file referenced an internal system called LZ-DSO, short for "Landing Zone DevSecOps" — the secure code development environment used to build CISA's tooling. The development environment that was supposed to protect the agency's code was protected by a password sitting in a public CSV.

GitGuardian's automated scanning flagged the repository on May 14, 2026, and the platform attempted to alert the account owner directly. When that produced no response, Valadon escalated publicly on May 15, and KrebsOnSecurity and Seralys notified CISA. The repository was taken offline within roughly 26 hours of public escalation. Even then, the exposed AWS keys remained valid for another 48 hours after the repository disappeared — a credential-revocation failure that is itself a security incident.

CISA's public statement, in full operational tone: "Currently, there is no indication that any sensitive data was compromised as a result of this incident." The agency added that it is working to ensure "additional safeguards are implemented to prevent future occurrences." Nightwing declined to comment and directed inquiries to CISA.

Who Was Actually at Risk

The direct blast radius is CISA's own internal cloud environments and any downstream system whose credentials sat in that CSV. There is no current evidence that a third party — beyond GitGuardian, Seralys, and KrebsOnSecurity — accessed and exploited the keys before takedown. But "no current evidence" is not the same thing as "no exposure." A repository public for six months is fully indexable, fully cloneable, and almost certainly mirrored to private collections by anyone running broad credential-harvesting infrastructure, which is now standard tooling for both criminal and state-aligned actors.

For Canadian and US SMBs, the direct risk is not that your AWS account was in that CSV. The risk is twofold:

  • Vendor and supply-chain exposure. If your business relies on services, software, or assessments delivered by federal contractors, CISA itself, or any agency whose tooling is built in environments like LZ-DSO, the integrity of that supply chain is a live question — the same question we raised after the SolarWinds breach and the axios npm supply-chain attack.
  • The pattern is universal. Every failure that produced the Private-CISA leak is a failure SMBs make routinely, usually without anyone noticing until it shows up in a breach notification. The agency that publishes hardening guidance for the rest of the country could not enforce its own. That tells you exactly how easy it is for a 25-person company to be in the same position right now.

Why This Leak Is Different From Most Credential Exposures

Public GitHub repositories full of secrets are not new — GitGuardian's annual research has tracked roughly 20+ million exposed secrets per year for several years running. What makes Private-CISA different is the combination of institutional authority, deliberate control disablement, and time.

Three things separate this from a routine "developer accidentally committed an API key" story:

  • The platform's safety net was switched off on purpose. GitHub has shipped push protection as a default for personal accounts since 2024. It scans for known secret patterns (AWS access keys, GitHub tokens, Stripe keys, SAML certificates) at the moment of git push and refuses the push by default. Per commit-log analysis cited by Krebs, the Private-CISA owner explicitly disabled that protection. This was not a "the tool missed it" failure. It was a "the tool said no, and the user said yes anyway" failure.
  • The repository's purpose was personal convenience. The commit pattern — small, regular updates over six months — is consistent with someone using a public Git repository as a free, always-available sync mechanism between machines. This is exactly the workflow personal cloud drives, encrypted backup tools, and zero-trust device-to-device sync exist to replace.
  • Time amplified the damage. A secret leaked for an hour and rotated is an incident. A secret leaked for six months is a posture. By the time the repository was found, any reasonable threat actor would assume it had been scraped.

The same three failures — silenced controls, shadow workflows, and unmonitored repositories — drive a large share of SMB breaches. We covered the broader collapse of credential hygiene in our recent piece on why business password audits keep failing, and the underlying control gaps in password security and what SMBs get wrong.

What Canadian and US Business Leaders Should Take From This

The Private-CISA leak is most useful as a diagnostic mirror. Run each of the following questions past your IT lead, your managed IT provider, or your security partner. If any answer is "I'm not sure," that is the answer.

  • Is GitHub push protection (or your platform's equivalent secret scanning) on, by default, and locked? For organizations using GitHub, Bitbucket, or GitLab, secret scanning at push time is free or near-free, and the meaningful question is not whether it exists but whether anyone in your organization can turn it off without a record. The Private-CISA contractor could; that is the failure to design out.
  • Do your developers or contractors use personal Git accounts to move company work between machines? If the answer is yes, your work-from-home and BYOD policies have a gap. We covered the broader pattern in BYOD risks for SMBs.
  • Are any of your business passwords still being stored in browser profiles or spreadsheets? The exposed CSV in the CISA leak was a Firefox password export — a feature every major browser supports. Browser-stored passwords are not encrypted at rest in a way that survives a single compromised laptop, and exporting them produces exactly the kind of plaintext file that ends up in the wrong repository. A proper zero-knowledge password manager like Bitwarden, 1Password, or Keeper is the baseline alternative.
  • How fast can you revoke a cloud access key? The 48-hour validity window on the leaked CISA keys, after takedown and public reporting, is the part of this incident most directly applicable to SMBs. If your business uses AWS, Azure, or Google Cloud — even just for backups, accounting integrations, or a single SaaS platform — your team should be able to disable an access key in minutes, not days. CCCS's Baseline Cyber Security Controls for Small and Medium Organizations in Canada and the FTC Safeguards Rule and NIST SP 800-171 in the United States all assume a working credential-revocation process. Many SMBs do not have one written down.
  • Do you scan your own public footprint for leaked secrets? Free tools — including GitGuardian's public dashboard and GitHub's own secret-scanning alerts for organization-owned repositories — can catch most of the easy cases. A quarterly external review by your security partner catches the rest.

Practical Next Steps for SMBs This Week

Treat the Private-CISA story as a free, no-consequence drill. Five concrete actions, all of which a competent IT lead or managed IT services provider can complete inside a normal work week:

  1. Turn on GitHub secret-scanning push protection at the organization level. If your business uses GitHub, this is a single setting in Organization → Code security and analysis. Make it required for all repositories, public and private, and remove individual users' ability to disable it.
  2. Audit who has cloud admin keys, and rotate them. Pull a list of long-lived access keys from AWS, Azure, and Google Cloud. Anything older than 90 days, anything tied to a person who has left, and anything still embedded in a script gets rotated this week. Move toward short-lived, role-based access (AWS IAM Identity Center, Azure managed identities, Google Workload Identity Federation) for everything else.
  3. Ban browser-stored business passwords and shared password spreadsheets. Roll out a vetted password manager organization-wide. Disable password saving in the browsers your team uses for work. Re-import any existing browser-stored credentials into the manager, then delete the originals.
  4. Write a one-page credential revocation runbook. Name the person on call. List the exact console paths to disable an AWS key, an Azure service principal, a Google Cloud service account, a GitHub personal access token, and your Microsoft 365 break-glass account. Time how long it takes to do each one. If any step takes more than ten minutes, fix it.
  5. Run a free quick security assessment. If you are not sure where you stand on any of the above, our free 5-minute security assessment walks through the most common SMB credential and access-control gaps and gives you a written snapshot.

The Durable Lesson: Controls Only Work If They Cannot Be Quietly Turned Off

The Private-CISA leak is not really a story about CISA, or about GitHub, or even about one contractor. It is a story about what happens when a security control exists but the people it is meant to protect can override it without anyone watching. Push protection caught the secrets. The user disabled push protection. There was no second line of defence — no organization-level lock, no monitoring alert on the disablement, no review when a brand-new public repository started accumulating files with names like importantAWStokens.

For a Canadian or US SMB, the lesson is concrete: every meaningful security control in your environment should have an answer to the question "who can turn this off, and who finds out when they do?" If the answer is "anyone, and nobody," that control is decorative. Fix the ones that matter — secret scanning, MFA, endpoint protection, backup integrity, cloud admin access — first.

If your team needs help working through the list, the same fundamentals apply whether you have five employees or five hundred. That is the work we do every day with businesses across Toronto, Calgary, Vancouver, Ottawa, Edmonton, Winnipeg, Chicago, Dallas, Denver, Miami, Phoenix, Portland, and Seattle. A short, honest conversation usually saves a long, expensive one later.

This article is intended for general informational purposes only and does not constitute professional security, legal, or compliance advice. Details about the Private-CISA GitHub repository exposure are based on public reporting by TechCrunch, KrebsOnSecurity, GitGuardian, Seralys, and statements attributed to CISA as of May 19, 2026, and may evolve as the investigation continues. Organizations should consult qualified cybersecurity professionals before acting on any specific indicator of compromise or making operational changes based on this article.