By Miran Qarachatani

Developer, Cybersecurity & AI

A contractor for the US Cybersecurity and Infrastructure Security Agency (CISA) left a public GitHub repository called Private-CISA exposed to the open internet for roughly six months. By the time GitGuardian and KrebsOnSecurity escalated it on May 15, 2026, the repo held administrative AWS GovCloud keys, plaintext passwords for dozens of internal CISA systems, SSH keys, SAML certificates, and API tokens. Philippe Caturegli of Seralys, who confirmed the keys were live, called it “the worst leak that I’ve witnessed in my career.” The useful question for Canadian or American SMBs is not “How did CISA let this happen?” It is, “Which of the five failures behind this leak are true inside my own company right now?”

What Actually Happened, in 90 Seconds

A contractor created a personal public GitHub repository named Private-CISA on November 13, 2025. He disabled GitHub’s built-in push protection (the feature that scans commits for secrets before they go live), then used the repo as a personal sync point between his work and home machines. Over six months it accumulated about 844 MB of CISA internal data.

Two files made the leak catastrophic:

• importantAWStokens — administrative credentials to three CISA AWS GovCloud environments, the dedicated US-government region of AWS used for sensitive federal workloads.

• AWS-Workspace-Firefox-Passwords.csv — a Firefox password export containing plaintext usernames and passwords for dozens of internal systems, including the LZ-DSO (“Landing Zone DevSecOps”) environment used to build CISA’s own tooling.

GitGuardian flagged the repo on May 14. The owner did not respond to automated alerts. Public escalation followed on May 15. The repository was pulled within about 26 hours of public notification — but the exposed AWS keys remained valid for another 48 hours after takedown. That delay is its own separate security incident inside the larger one.

Failure #1: The Safety Net Was Switched Off on Purpose

GitHub has shipped push protection as a default on personal accounts since 2024. It scans commits at push time for known secret patterns and refuses the push upon detection. The Private-CISA contractor explicitly turned it off. Commit-log analysis cited by Krebs confirms this was a deliberate action, not a misconfiguration. For an SMB, the question that falls out of this is: For every security control in your environment, who can turn it off, and who finds out when they do? If the answer is, “Anyone, and nobody,” that control is decorative. GitHub push protection has an organization-level lock that prevents individual users from disabling it. So do most of the equivalent controls in Bitbucket, GitLab, and Azure DevOps. Most SMBs never set those locks because nobody ever asked.

Failure #2: Browser-Stored Passwords Are Still Producing Plaintext CSVs

The file that did the most damage in the CISA leak wasn’t the AWS keys. It was the Firefox password export. Every major browser will happily dump every saved password to a CSV with two clicks. The problem is that it produces a perfectly clean plaintext file of every credential the user has ever saved while logged into their work browser profile. That file then sits in Downloads/, gets accidentally committed, or gets uploaded to a sync tool by a user who has no idea what is in it. A real password manager (Bitwarden, 1Password, Keeper, or any zero-knowledge equivalent) solves this at the source. Credentials live in an encrypted vault. Exports are still possible, but they are an active, friction-laden choice rather than a side effect of the browser doing its job. If your team is saving business passwords in browser profiles or, worse, in shared spreadsheets, you are one accidental drag-and-drop away from your own version of AWS-Workspace-Firefox-Passwords.csv. The “we have a team password manager” conversation pays for itself the first time it prevents this.

Failure #3: Long-Lived Keys and Slow Revocation

The 48 hours of continued credential validity after the repo went private is the part of this incident SMBs should study most closely. The keys in importantAWStokens were long-lived static access keys — the same kind of credential most SMBs use to wire up backups, accounting integrations, CI/CD pipelines, and SaaS connectors. They do not expire on their own. Revoking them requires someone to log into the AWS console, find the right IAM user, and disable the key. If nobody on your team is sure how to do that, or which keys exist in the first place, your blast-radius math gets ugly fast. The mature pattern, for which AWS, Azure, and Google Cloud have all built first-class tooling, is short-lived, role-based credentials issued on demand from an identity provider — AWS IAM Identity Center, Azure managed identities, Google Workload Identity Federation. The credential lives for minutes or hours, then expires automatically. Revocation is implicit. There is nothing to forget to rotate.

Failure #4: The Repository Was a Personal Sync Drive

The commit pattern on Private-CISA — 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 a workflow that personal cloud drives, work-issued device management, and zero-trust device sync tools exist specifically to replace. If any developer or contractor in your business is moving company work between a work laptop and a personal machine through a personal Git account, your BYOD policy has a hole in it. Not because Git is inherently bad, but because once company data is in a personal account, your visibility ends. You can’t scan it. You can’t rotate credentials from it. You can’t detect a public/private flip.

Failure #5: AI Coding Tools Are Reading Your Secrets Right Now

If your developers use Claude Code, Cursor, GitHub Copilot’s agent mode, Kiro, Antigravity, or any other agentic AI coding assistant, those tools have read access to the full file tree of whatever project they are working on. That includes the .env file at the project root with your database password, your Stripe test key, your OpenAI API key, your Sentry DSN. When the agent reads that file as part of doing its job — answering “is the database password set correctly?” or “why is the LLM call failing?” — those secrets are sent to the AI vendor’s API as conversation context. Even if the vendor doesn’t train on it, a determined attacker (or a future prompt injection) can sometimes extract secrets that the model has seen. Depending on the vendor and your account’s training-data settings, that conversation may be retained for analysis, used to improve future models, or simply held in vendor logs. Large language models are also extraordinarily good at memorizing the things they are trained on. A secret that ends up in training data is not lost in the noise — it is potentially extractable by a future user prompting the model in the right shape. This is happening at scale right now, on hundreds of millions of developer machines, with credentials nobody has rotated in years. The mitigation is the same one that should have been in place before AI tools existed:

• Get production credentials out of .env files in source trees. Use a real secrets manager — AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, HashiCorp Vault, or open-source tools like SOPS or varlock that encrypt secrets at rest in the repo itself.
• Use short-lived, scoped credentials in development. Dev keys should never have production access.
• Opt out of training-data use in your AI vendor settings, and pay for the enterprise tier on any AI tool your developers use for company work. The cost difference is rounding error against a single rotated credential incident.

What to Check This Week

Five questions to put to your IT lead, your managed IT provider, or your security partner. If any answer is “I’m not sure,” that is the answer.

• Push Protection: Is it enabled organization-wide, required for all repos (public and private), and locked so individual users can’t disable it? For GitHub, this is a single setting under Organization → Code security and analysis. Make it required for all repositories, public and private, and remove individual users’ ability to disable it.
• Revocation: Do you have an up-to-date inventory of all long-lived access keys? 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, anything embedded in a script — rotate this week. Write the revocation steps into a one-page runbook and time how long they take.
• Password Manager: Have you disabled browser password saving on company-managed devices? Roll out a password manager organization-wide. Disable password saving in work browsers. Import existing browser-stored credentials into the manager, then delete the originals.
• AI Tools: Have you audited which AI coding tools your developers are using and what directories they can access? Get production secrets out of .env files. Move to a secrets manager. Set your AI vendor accounts to enterprise tier with training opt-out. Make sure developers know which directories the agent can read.
• Scanning: Do you scan your own public footprint? GitHub’s secret-scanning alerts for organization-owned repos are free. GitGuardian’s public dashboard catches most external exposure. A quarterly external review by your security partner catches what they miss.

The Lesson

The Private-CISA leak is not really a story about CISA, GitHub, or one contractor. It’s a story about what happens when a meaningful security control exists but the people it is meant to protect can override it without anyone watching. The agency that publishes federal hardening guidance for the United States could not enforce its own, not because the controls didn’t exist, but because every one of them could be quietly turned off. For every meaningful control in your environment, you should be able to answer two questions:

Who can turn this off? Who finds out when they do?

When the answer to either is “We don’t know,” that’s where the next leak comes from. If you would like help working through any of the five questions above, our team works with SMBs across Canada and the U.S. on exactly this kind of credential and access-control review. A short conversation usually saves a long, expensive one later.