Even the US government is not immune to accidental data leaks. In May 2025, cybersecurity researchers uncovered a publicly accessible GitHub repository owned by the Cybersecurity and Infrastructure Security Agency (CISA) containing 844MB of sensitive data. The CISA credential leak, discovered by GitGuardian’s Guillaume Valadon, included plain‑text passwords, authentication tokens, and other secrets. What makes the incident particularly alarming is that the repository remained exposed for six months before it was taken down — and only after a well‑known journalist intervened.
Despite being named Private-CISA, the repository was visible to anyone with an internet connection since November 13, 2025. When Valadon first looked inside, he assumed it was a hoax because the contents seemed too good to be true. Sadly, they were real. This article unpacks the seven categories of credential secrets that were exposed, explains how the breach happened, and outlines practical lessons for organizations of all sizes.
How the CISA Credential Leak Was Discovered
Valadon works for GitGuardian, a company that continuously monitors public sources — especially GitHub — for leaked secrets. On May 13, 2025, GitGuardian’s Public Monitoring system flagged a repository belonging to CISA. The next day, Valadon began his investigation.
He found directories with names that would make any security professional cringe: Important AWS Tokens.txt, ENTRA ID – SAML Certificates/, and more. The sheer volume and specificity of the exposed data convinced Valadon the repository was authentic. He immediately alerted CISA, but the agency did not respond until cybersecurity journalist Brian Krebs connected with his contacts inside the organization. Within just over 24 hours, the repository was taken down.
The six‑month window of exposure is concerning because threat‑hunting tools and automated scrapers constantly scan GitHub for new repositories containing sensitive strings. Studies show that attackers can detect and exploit leaked credentials in minutes, not days. Although Valadon observed no forks (a weak signal that the repo did not circulate widely), external cloning cannot be ruled out — only GitHub’s internal logs can confirm whether anyone downloaded a copy.
The 7 Types of Credential Secrets Exposed
Below are the seven distinct categories of credential secrets that the CISA credential leak contained. Each category represents a separate vector of risk, from direct account compromise to supply‑chain infiltration.
1. Plain‑Text Passwords
The repository contained multiple files with passwords stored in clear, unencrypted text. This is perhaps the most basic security sin: passwords should never be committed to version control, especially not in plain form. Threat actors who obtained these strings could immediately attempt to log into associated accounts, whether those were internal CISA systems, cloud consoles, or third‑party services.
2. Authentication Tokens (Including AWS Tokens)
A file named Important AWS Tokens.txt lived up to its name. It contained access tokens for Amazon Web Services, the cloud infrastructure that powers many government digital services. With these tokens, an attacker could read S3 buckets, spin up EC2 instances, or even escalate privileges inside CISA’s AWS environment. Tokens are particularly dangerous because they often do not expire for long periods and can grant programmatic access without additional verification.
3. Private Keys (SSH, TLS, and API)
Private cryptographic keys were also exposed. These included SSH keys used for server authentication and TLS keys that help secure web traffic. If anyone had copied those keys, they could impersonate CISA’s internal services, decrypt communications, or gain unauthorized access to systems that trust the corresponding public keys.
4. SAML Certificates
Security Assertion Markup Language (SAML) certificates are used for single sign‑on (SSO) across government agencies. The directory ENTRA ID – SAML Certificates/ contained these certificates in plaintext. With a SAML certificate, a malicious actor could forge authentication assertions, potentially logging into any application that trusts CISA’s identity provider — without needing a user’s password.
5. CI/CD Build Logs and Deployment Workflow Documentation
Continuous Integration / Continuous Deployment (CI/CD) logs often leak environment variables, database connection strings, and temporary tokens. The exposed repository contained build logs and deployment workflow documents that revealed how CISA’s software is built and delivered. Attackers could study these to find additional weaknesses or to craft attacks that mimic legitimate deployment processes.
6. Kubernetes Manifests with Embedded Secrets
Kubernetes configuration files (manifests) sometimes include hardcoded secrets for connecting to container registries, databases, or monitoring tools. The repository leaked several Kubernetes manifests that contained such embedded credentials. If an attacker had applied these manifests to their own cluster, they could replicate CISA’s infrastructure or poison the software supply chain.
7. GitHub Actions Workflows and Organization Automation
GitHub Actions workflows automate testing, building, and deployment. They rely on secrets stored as GitHub repository variables or environment variables. The exposed repo included workflow files that referenced those secrets — and in some cases, the secrets themselves were written directly into the YAML file. This gave intruders a blueprint of CISA’s automation and the credentials used to push code, run tests, or deploy to production.
The Root Cause: Disabling Security Controls
Valadon’s analysis of the repo revealed a troubling pattern. GitHub’s push protection feature blocks commits that contain high‑confidence secrets. When CISA employees tried to push code that included hardcoded credentials, the feature would reject the commit. Instead of removing the secrets, someone documented how to disable push protection so the commits would go through. This is a classic example of treating the symptom rather than the disease.
GitGuardian’s blog post described the repository as a “catalogue of unsafe practices.” Beyond plain‑text passwords and disabled scanning, the repo also contained Git backups — copies of the entire history — which meant that any secret ever committed (even if later removed) could still be recovered from the backup.
You may also enjoy reading: iOS 27 Design Leak: 5 Features I Sounded Off For.
The incident underscores a critical lesson: security tools like GitHub’s secret scanning are not obstacles to productivity. They are safety nets that should be enforced, not bypassed. Mature organizations treat these controls as non‑negotiable prerequisites for committing code.
Lessons for Government Agencies and Developers
The CISA credential leak offers several actionable takeaways for any team that uses version control and cloud infrastructure.
Automate Secret Scanning Before Every Commit
Do not rely solely on GitHub’s push protection. Implement pre‑commit hooks (using tools like truffleHog, git‑secrets, or GitGuardian’s own integrations) that scan for credentials before the commit is finalized. This catches mistakes at the earliest possible stage.
Never Name a Repo “Private” Without Actual Access Controls
The word “Private” in a repository name gives a false sense of security. GitHub determines public or private status through explicit visibility settings, not naming conventions. Always double‑check the visibility badge at the top of the repository page, and enforce branch protection rules that prevent accidental visibility changes.
Rotate All Exposed Secrets Immediately
If a secret leak is detected, every exposed credential must be considered compromised. Generate new passwords, tokens, keys, and certificates. Revoke old ones. Assume that an attacker may have copied them, even if no evidence of exploitation appears. For cloud providers, use tools like AWS Secrets Manager or HashiCorp Vault to automate rotation and eliminate hardcoded secrets.
Monitor Third‑Party Public Monitoring Feeds
Organizations can subscribe to services that alert them when their domains, email addresses, or repository names appear in public leak databases. GitGuardian’s Public Monitoring is one example. Such tools fill the gap when internal security controls fail or when a repo is accidentally made public.
Treat Security Controls as Non‑Negotiable
When a developer encounters a blocked commit because of a hardcoded secret, the correct response is to remove the secret — not to disable the detector. Security teams should educate developers on how to use environment variables or secret management services instead. Making bypassing controls a disciplinary or policy issue can reinforce good habits.
The Broader Context: Budget Cuts and Staff Reductions
The exposed repo comes at a time when CISA has faced significant budget and workforce reductions under the second Trump administration. The agency lost roughly one‑third of its employees, and the fiscal 2027 budget proposal slashes funding by more than $700 million. Diminished resources can lead to corners being cut in security practices — precisely the kind of environment where a repo named Private-CISA can slip through the cracks.
Government cybersecurity agencies are expected to set the standard for secure development. This incident demonstrates that even the most well‑intentioned teams can make catastrophic mistakes when proper automated checks are not in place and when security controls are treated as optional.
The good news is that the repository was taken down quickly once the right contacts were reached. The bad news is that for six months, the US government’s cyber defenders were unintentionally sharing their crown jewels with the entire internet. The CISA credential leak should serve as a wake‑up call for every organization that relies on GitHub — regardless of whether your repo name includes the word “Private.”
