On 18 May 2026 KrebsOnSecurity reported that a CISA contractor with administrative access to the agency's code development platform had created a public GitHub profile named "Private-CISA". It held plaintext credentials to dozens of internal systems. Commit logs showed the contractor had disabled GitHub's built-in protection against publishing sensitive credentials in public repositories.
CISA said there was "no indication that any sensitive data was compromised as a result of the incident." The hard part, according to the report, was cleanup: more than a week after GitGuardian first notified CISA, the agency was still working to invalidate and replace many exposed keys.
What's affected
Per the KrebsOnSecurity report, the exposed material included:
- File names such as
Important AWS Tokens.txt,kube-config.txt, and a CSV of browser-saved AWS Workspace passwords. - Plaintext credentials to "important CISA GovCloud resources".
- An RSA private key for a GitHub app owned by CISA's enterprise account. The app was installed on the CISA-IT GitHub organization with full access to its repositories.
- Credentials for other security technologies that the reporter chose not to name.
The report says experts believed the archive was created in November 2025 and looked like a personal sync repository, while an update said the most sensitive secrets appeared in late April 2026. CISA did not say how long the data was exposed. The repository is now defunct.
You are not affected by this incident unless you share a vendor or a pattern with it. The pattern is what matters.
How to check if you're exposed
The question is not whether your people are careless. It is whether one careless act is blocked, logged or invisible.
- Can an individual turn off secret scanning protection? In the organization, open Settings, then Advanced Security, then Configurations. If push protection is enforced by a configuration, check who is on the bypass list. If a repository owner can change it alone, a personal repository with the same credentials is outside your control.
- What happens in a personal account? Org-level settings do not cover repositories in someone's personal account. Ask whether contractors and staff are allowed to push work files to personal GitHub accounts at all.
- Which secrets are long lived and unrotatable in a day? List cloud keys, kubeconfigs, app private keys and registry tokens. For each, write down how long a full rotation would take.
What to do now
- Turn push protection on for every repository through an organization security configuration, then apply it.
- Use delegated bypass. In the configuration, set "Bypass privileges" to specific actors, and give the fine-grained permission "Review and manage secret scanning bypass requests" to a small custom role. GitHub's docs warn that exempting an actor can lead to leaked secrets and should be done with caution.
- Alert on bypasses. Push protection generates an alert whenever a contributor bypasses the block, so route those to the security channel.
- Rotate before you investigate. Revoke or replace each exposed credential first, then work out who used it. A private key for a GitHub app should be deleted and regenerated, and its installation reviewed.
- For a leaked GitHub token you do not own, GitHub's credential revocation API can revoke a list of tokens in bulk. See our separate guide.
How this could have been avoided
- Org-enforced push protection with no self-service off switch. The commit history showed protection being disabled by the user. A configuration applied from the organization, plus delegated bypass, turns that into a request someone has to approve.
- Short-lived cloud credentials. A text file of AWS tokens is only useful while the tokens are valid. Role-based, expiring credentials from a vault or single sign-on shrink the window.
- No credentials in browser exports. A CSV of saved browser passwords means shared secrets were being kept in a personal tool. A shared team vault with access logs removes the temptation.
- App private keys stored as secrets with an owner. The RSA key gave full repository access on an organization. Store such keys in a managed secret store, rotate on a schedule, and keep the app permissions narrow.
- A tested rotation runbook. The slow cleanup is the clearest lesson. If rotating a credential takes weeks, it is not really rotatable.
Why it matters
Experts quoted in the report said attackers watch public GitHub event feeds for exposed keys, as do researchers. Once a secret is public, assume it is copied within minutes and treat rotation as the only fix. Deleting the repository does not undo that.
The second lesson is about trust in tools. Risky Business's James Wilson said organizations can use top-down policies to block people from disabling the protections, and Adam Boileau said the problem is human and technical controls may not solve all of it. Both are right. Controls make the careless act harder, and training explains why.
Try it yourself
Pick one repository and commit a fake key in the format of a well-known provider on a scratch branch, then try to push it. Note what you see, who could bypass it, and where the bypass would be recorded. If the answer is "nobody would know", fix that first.
Click through it at your own pace, or open it full screen.
Quick check
What did the commit logs show about GitHub's secret protection?
According to KrebsOnSecurity, the contractor had disabled GitHub's built-in protection against publishing sensitive credentials in public repositories.
Why is rotating more urgent than investigating?
Public GitHub activity is monitored by researchers and attackers alike, so a leaked credential should be assumed copied. Replace it first, then review how it was used.
