{"id":8209,"date":"2026-05-19T20:57:46","date_gmt":"2026-05-19T20:57:46","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=8209"},"modified":"2026-05-19T20:57:46","modified_gmt":"2026-05-19T20:57:46","slug":"contractors-public-github-account-exposed-govcloud-and-cisa-credentials","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=8209","title":{"rendered":"Contractor\u2019s public GitHub account exposed GovCloud and CISA credentials"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

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.<\/p>\n

That\u2019s according to cybersecurity reporter Brian Krebs, who first broke the news over the weekend<\/a>, acting on a tip from researcher Guillaume Valadon<\/a> at GitGuardian.<\/p>\n

Valadon confirmed the information in an email interview with CSO<\/em>.<\/p>\n

Based on the repository\u2019s commit history and the account creator\u2019s 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.<\/p>\n

\u201cThis 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,\u201d he wrote, \u201cand because internal documents meant to remain private\u00a0were pushed to a public\u00a0repository inside a personal developer account.\u201d<\/p>\n

GitGuardian is a French-based service whose products scan internal and external sources, including GitHub, for exposed secrets.<\/p>\n

On May 14, it found a public GitHub repository named \u201cPrivate-CISA.\u201d The repository, which had been live since November 13, 2025, contained 844 MB of data, including Kubernetes files,\u00a0GitHub Actions workflows, internal documentation backups, personal documents and operational scripts, plain-text passwords, AWS tokens, and GitHub access tokens.\u00a0<\/p>\n

The good news: GitHub events data indicates the repository was never forked, Valadon said, \u201cwhich limited the blast radius.\u201d<\/p>\n

The bad news: The owner of the account didn\u2019t reply immediately to Valadon\u2019s warning message, which is why he went to Krebs.<\/p>\n

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. \u201cI must credit them [CISA] for deleting this repository quickly,\u201d Valadon said. \u201cMost of our responsible disclosures take much longer, and many are never fixed. Managing to take the repository offline in a day is impressive work.\u201d<\/p>\n

\u201cI worked nine years at ANSSI [France\u2019s equivalent to CISA],\u201d Valadon added, \u201cand now, dealing with leaks daily at GitGuardian, this is definitely one of the worst I have ever seen.\u201d<\/p>\n

Based on the account\u2019s data, Krebs believes it was run by a Washington, DC area cybersecurity firm contracted by CISA. The company wouldn\u2019t confirm that when CSO<\/em> asked for comment, instead referring questions to CISA.<\/p>\n

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. \u201cCurrently, there is no indication that any sensitive data was compromised as a result of this incident,\u201d they wrote. \u201cWhile 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.\u201d\u00a0<\/p>\n

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<\/a> in the internal git infrastructure that could have enabled hackers to execute arbitrary commands on GitHub\u2019s backend servers.<\/p>\n

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\u2019s extensive protections and security best practices<\/a>, including limiting access to the repository.<\/p>\n

Related content: GitHub accounts targeted with fake security alerts<\/a><\/strong><\/p>\n

What CSOs and CIOs should do<\/h2>\n

Exposing secrets on GitHub \u201cis a serious and sadly common problem,\u201d commented Johannes Ullrich<\/a>, dean of research at the SANS Institute.<\/p>\n

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\u2019t easy to implement, he acknowledged, \u201cbut it is also your best bet to avoid secrets from being handled inappropriately.\u201d <\/p>\n

Second, use tools that proactively scan user systems and public services such as GitHub for exposed keys. \u201cThese products are essential to enforce any policy governing the secure handling of secrets,\u201d Ullrich said.<\/p>\n

\u201cIn this particular case, the fault appears to have been with a contractor, not CISA itself,\u201d he noted. \u201cManaging vendor relationships is important and must include agreements on how to handle secrets used to access internal systems and data.\u201d<\/p>\n

Veteran consultant Robert Enderle<\/a> of the Enderle Group noted that this kind of exposure happens with alarming frequency. \u201cDevelopers are often under immense pressure to deliver code quickly,\u201d he said, \u201cand the lines between personal and professional repositories can easily blur. However, for a contractor tied to CISA \u2014 the very agency tasked with defending our national infrastructure \u2014 the potential fallout is catastrophic. Leaving credentials exposed in a public GitHub repository is akin to leaving the master keys to the nation\u2019s 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.\u201d\u00a0<\/p>\n

To mitigate that potential, CSOs and CIOs must stop relying on policy alone and implement robust, automated governance, Enderle said. \u201cYou cannot expect humans not to make mistakes; you have to build systems that catch them,\u201d 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<\/a> architecture that assumes credentials will eventually be compromised, he said.<\/p>\n

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\u2019s code actually lives, including checking whether it\u2019s in employees\u2019 and contractors\u2019 personal GitHub accounts.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

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\u2019s 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 […]<\/p>\n","protected":false},"author":0,"featured_media":8210,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-8209","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/8209"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=8209"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/8209\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/8210"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=8209"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=8209"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=8209"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}