CISA contractor-linked GitHub leak exposed AWS GovCloud credentials and internal secrets

A public GitHub repository tied to a CISA contractor exposed AWS GovCloud credentials, plaintext passwords, tokens, certificates, deployment files, and internal system details, according to reports from KrebsOnSecurity and GitGuardian.

The repository, named Private-CISA, was discovered by GitGuardian researcher Guillaume Valadon on May 14, 2026. GitGuardian said the repository contained 844 MB of data across its working tree and Git history, with exposed material dating back to November 2025.

CISA said it is investigating the incident and has no current indication that sensitive data was compromised. However, researchers who reviewed the exposure said some credentials were still valid, and KrebsOnSecurity reported that AWS GovCloud keys remained active for about 48 hours after the repository was taken offline.

What was exposed in the Private-CISA repository

The public repository contained far more than a few stray passwords. GitGuardian said it included deployment documentation, Kubernetes manifests, ArgoCD files, Terraform infrastructure code, GitHub Actions workflows, internal documentation backups, scripts, AWS account references, service account details, and secret-management paths.

KrebsOnSecurity reported that the exposed files included credentials for highly privileged AWS GovCloud accounts and dozens of plaintext usernames and passwords for internal CISA systems. One file reportedly named AWS-Workspace-Firefox-Passwords.csv listed credentials tied to multiple internal resources.

Security researchers also found references to an internal CISA DevSecOps environment and credentials for an internal artifactory system. That kind of access can raise supply chain risk because artifact repositories often store or distribute packages used in software builds.

Exposed item	Why it matters
AWS GovCloud credentials	Could allow access to sensitive government cloud environments if still valid.
Plaintext usernames and passwords	Could enable account takeover or lateral movement.
Entra ID SAML certificates	Could affect identity and authentication workflows if mishandled.
Kubernetes and ArgoCD files	Could reveal deployment paths, service accounts, and internal platform structure.
Terraform and CI/CD workflows	Could expose cloud architecture and automation logic.
Artifactory credentials	Could create software supply chain risk if attackers accessed build artifacts.

Why AWS GovCloud credentials are sensitive

AWS GovCloud is designed for U.S. government agencies and organizations handling sensitive regulated workloads. AWS describes GovCloud as isolated U.S. sovereign regions built for requirements such as FedRAMP High, DoD SRG impact levels, CJIS, and controlled unclassified information.

That makes exposed GovCloud credentials especially serious. If keys are valid and over-permissioned, attackers may be able to access cloud resources, inspect infrastructure, read stored data, or modify services depending on assigned privileges.

Philippe Caturegli, founder of Seralys, told KrebsOnSecurity that he validated some exposed AWS credentials and found they could authenticate to three AWS GovCloud accounts at a high privilege level.

How the leak was discovered and removed

GitGuardian said it found the public repository on May 14, 2026. The company’s Good Samaritan program had already sent multiple automated emails to the commit author by May 13, but the issue had not been resolved.

GitGuardian then reported the exposure through CERT/CC and contacted Brian Krebs to help reach CISA. GitGuardian said it reached CISA directly around 16:00 CET on May 15, and the repository went offline later that day.

The repository had been created on November 13, 2025, according to GitGuardian’s timeline. That suggests sensitive files may have been exposed publicly for roughly six months before removal.

Date	Event
November 13, 2025	Private-CISA repository was created and first exposures began, according to GitGuardian.
May 13, 2026	GitGuardian’s Good Samaritan program had already sent multiple alert emails.
May 14, 2026	GitGuardian detected and reported the leak through CERT/CC.
May 15, 2026	GitGuardian contacted CISA directly and the repository was taken offline.
May 18, 2026	KrebsOnSecurity published details of the exposure.
May 19, 2026	Sen. Maggie Hassan requested an urgent classified briefing from CISA leadership.

CISA says it is investigating

CISA confirmed that it is aware of the reported exposure and is investigating. The agency said it currently has no indication that sensitive data was compromised as a result of the incident.

The agency also said it is implementing additional safeguards to prevent similar incidents. That response matters because the repository did not only contain credentials. It reportedly exposed operational details that could help attackers understand internal deployment processes.

Nightwing, the contractor connected to the repository through public reporting, declined to comment and directed questions to CISA.

Congress is asking questions

The exposure has already drawn congressional attention. Axios reported that Sen. Maggie Hassan requested an urgent classified briefing from acting CISA director Nick Andersen.

Her request asked for information about how the exposure happened, what data was exposed, which contractor was responsible, and what steps CISA has taken to limit damage.

The request shows how sensitive the incident has become. CISA is the U.S. government’s lead civilian cybersecurity agency, so a credential exposure tied to its own systems creates reputational and operational concerns.

Why secret scanning did not prevent the exposure

GitHub offers secret scanning and push protection to help prevent hardcoded credentials from reaching repositories. GitHub describes push protection as a feature that blocks supported secrets before they are pushed.

KrebsOnSecurity reported that commit logs suggested GitHub’s default secret-blocking setting had been disabled in the offending account. GitGuardian also said the repository contained explicit instructions to disable GitHub secret scanning.

That detail makes the incident more serious. Tools can reduce risk, but they cannot help if users bypass or disable them while storing passwords, keys, and backup files in public repositories.

• Secret scanning should be enabled for all repositories.
• Push protection should block supported secrets before commit.
• Developers should not store passwords or cloud keys in Git history.
• Public repositories should never be used as file sync folders.
• Organizations should monitor contractor-owned repositories for exposed assets.

Potential risks from the GitHub exposure

The most immediate risk is unauthorized access using valid credentials. Even after the repository was removed, any copied keys, tokens, certificates, or passwords could remain usable until revoked.

The second risk is reconnaissance. Infrastructure files, deployment workflows, internal hostnames, IAM references, and Kubernetes manifests can help attackers map systems and plan later attacks.

The third risk is software supply chain compromise. If attackers gained access to artifact repositories or CI/CD systems, they could potentially tamper with packages, build processes, or deployment pipelines.

Risk	Possible impact
Cloud account access	Attackers could access, inspect, or modify AWS GovCloud resources.
Identity compromise	Exposed passwords, tokens, and SAML materials could affect authentication systems.
Infrastructure mapping	Terraform, Kubernetes, and ArgoCD files could reveal architecture and deployment flows.
CI/CD compromise	Build logs and workflows could help attackers target software delivery pipelines.
Artifact tampering	Artifactory credentials could create risk to packages used in builds.
Persistence	Attackers could reuse copied secrets if any remain valid after cleanup.

What CISA and contractors should do next

The first priority is full credential revocation. Every exposed AWS key, GitHub token, password, SAML certificate, Kubernetes secret, service account credential, and artifact repository credential should be rotated or invalidated.

The second priority is log review. Security teams should review AWS CloudTrail, GitHub audit logs, identity provider logs, Artifactory logs, Kubernetes audit logs, and CI/CD activity from the full exposure window.

The third priority is source and artifact integrity. If attackers had any opportunity to access build systems or package repositories, teams should verify package signatures, rebuild trusted artifacts, and compare deployment history against known-good baselines.

1. Revoke all exposed AWS GovCloud credentials and access keys.
2. Rotate passwords, GitHub tokens, API tokens, SAML certificates, and service account secrets.
3. Review CloudTrail for access from unknown IP addresses, unusual API calls, and privilege changes.
4. Audit GitHub logs for repository access, clones, token use, workflow changes, and secret scanning bypasses.
5. Inspect Artifactory or package repositories for unauthorized uploads or modified artifacts.
6. Review Kubernetes, ArgoCD, and Terraform activity tied to exposed files.
7. Check whether public forks, mirrors, caches, or archives copied the repository before removal.
8. Require contractor-managed repositories to meet the same security controls as internal repositories.

Lessons for other organizations

The Private-CISA incident shows how one public repository can expose an entire operational map. Credentials are only part of the risk. Architecture files, logs, deployment scripts, and backups can give attackers context they would otherwise spend weeks gathering.

Organizations should treat contractor accounts and personal developer repositories as part of their exposure surface. Sensitive projects often leak through accounts that do not sit inside the official organization on GitHub.

Secret scanning also needs enforcement. Alerts help, but organizations need policies that prevent bypasses, require immediate rotation, and trigger incident response when secrets appear in public locations.

• Scan public GitHub for employee and contractor leaks.
• Block secrets at commit time wherever possible.
• Use short-lived credentials instead of long-lived static keys.
• Require hardware-backed MFA for privileged cloud accounts.
• Separate personal and work Git identities.
• Ban public repositories for backups and file synchronization.
• Automate revocation when secrets appear in public code.
• Review third-party and contractor access regularly.

A basic mistake with serious consequences

The reported CISA-linked GitHub exposure is a reminder that cloud security often fails at the simplest layer: secrets handling. Even strong cloud platforms can become vulnerable when credentials, certificates, and deployment files are stored in public repositories.

The repository has been removed, but removal is only the first step. The real measure of risk depends on whether all exposed secrets were revoked, whether logs show unauthorized use, and whether build systems stayed clean.

For any organization, the lesson is direct. Do not commit secrets, do not use GitHub as a backup folder, enforce secret scanning, and treat every public credential leak as an incident until logs prove otherwise.

FAQ