Until a few days ago, a publicly-accessible GitHub repository exposed credentials for both US government AWS accounts and internal Cybersecurity and Infrastructure Security Agency (CISA) systems.
That’s according to cybersecurity reporter Brian Krebs, who first broke the news over the weekend, acting on a tip from researcher Guillaume Valadon at GitGuardian.
Valadon confirmed the information in an email interview with CSO.
Based on the repository’s commit history and the account creator’s own troubleshooting notes, committed back into the repo, Valadon believes the repository was run by a CISA contractor who created it on his personal GitHub account.
“This is a serious breach of security controls, because secrets are stored in plain text and committed to Git instead of being fetched from a secret manager at runtime,” he wrote, “and because internal documents meant to remain private were pushed to a public repository inside a personal developer account.”
GitGuardian is a French-based service whose products scan internal and external sources, including GitHub, for exposed secrets.
On May 14, it found a public GitHub repository named “Private-CISA.” The repository, which had been live since November 13, 2025, contained 844 MB of data, including Kubernetes files, GitHub Actions workflows, internal documentation backups, personal documents and operational scripts, plain-text passwords, AWS tokens, and GitHub access tokens.
The good news: GitHub events data indicates the repository was never forked, Valadon said, “which limited the blast radius.”
The bad news: The owner of the account didn’t reply immediately to Valadon’s warning message, which is why he went to Krebs.
Valadon also reported the leak to the US-based Computer Emergency Response Team Coordination Center (CERT/CC) on May 14, and the next day reached out to CISA. The repository was offline that night. “I must credit them [CISA] for deleting this repository quickly,” Valadon said. “Most of our responsible disclosures take much longer, and many are never fixed. Managing to take the repository offline in a day is impressive work.”
“I worked nine years at ANSSI [France’s equivalent to CISA],” Valadon added, “and now, dealing with leaks daily at GitGuardian, this is definitely one of the worst I have ever seen.”
Based on the account’s data, Krebs believes it was run by a Washington, DC area cybersecurity firm contracted by CISA. The company wouldn’t confirm that when CSO asked for comment, instead referring questions to CISA.
Asked for comment, a CISA spokesperson said in an email that the agency is aware of the reported exposure and is continuing to investigate the situation. “Currently, there is no indication that any sensitive data was compromised as a result of this incident,” they wrote. “While we hold our team members to the highest standards of integrity and operational awareness, we are working to ensure additional safeguards are implemented to prevent future occurrences.”
There are many serious security problems with GitHub repositories, ranging from fake repositories created by threat actors to legitimate accounts that are wrongly created with public access. And last month, researchers at Wiz uncovered an injection vulnerability in the internal git infrastructure that could have enabled hackers to execute arbitrary commands on GitHub’s backend servers.
In the current case, the problem is human; GitHub repositories can contain a range of secrets, such as tokens and credentials included by account creators, which is why users need to implement GitHub’s extensive protections and security best practices, including limiting access to the repository.
Related content: GitHub accounts targeted with fake security alerts
What CSOs and CIOs should do
Exposing secrets on GitHub “is a serious and sadly common problem,” commented Johannes Ullrich, dean of research at the SANS Institute.
But, he added, there are several steps IT can take to prevent this. First, secrets such as passwords and API keys must be centrally managed. An enterprise-wide secret management process isn’t easy to implement, he acknowledged, “but it is also your best bet to avoid secrets from being handled inappropriately.”
Second, use tools that proactively scan user systems and public services such as GitHub for exposed keys. “These products are essential to enforce any policy governing the secure handling of secrets,” Ullrich said.
“In this particular case, the fault appears to have been with a contractor, not CISA itself,” he noted. “Managing vendor relationships is important and must include agreements on how to handle secrets used to access internal systems and data.”
Veteran consultant Robert Enderle of the Enderle Group noted that this kind of exposure happens with alarming frequency. “Developers are often under immense pressure to deliver code quickly,” he said, “and the lines between personal and professional repositories can easily blur. However, for a contractor tied to CISA — the very agency tasked with defending our national infrastructure — the potential fallout is catastrophic. Leaving credentials exposed in a public GitHub repository is akin to leaving the master keys to the nation’s cyber defenses on a public park bench. Had those credentials been leveraged by a nation-state actor, it could have facilitated a massive supply chain attack or deep infiltration into critical government systems.”
To mitigate that potential, CSOs and CIOs must stop relying on policy alone and implement robust, automated governance, Enderle said. “You cannot expect humans not to make mistakes; you have to build systems that catch them,” he said. This means mandating automated secret scanning tools that actively block commits containing credentials or API keys before they ever hit a repository. Enterprises also need to enforce strict separation between personal and professional developer environments, mandate multi-factor authentication (MFA) across the board, and embrace a zero trust architecture that assumes credentials will eventually be compromised, he said.
Valadon added that CSOs and CIOs should perform full secret scanning on all internal repositories, not just public GitHub accounts, block secrets before they reach the repository, use short-lived credentials wherever possible, deploy honeytokens, such as fake passwords that would trick curious attackers, in sensitive repositories, and inventory where their organization’s code actually lives, including checking whether it’s in employees’ and contractors’ personal GitHub accounts.