A contractor-maintained GitHub repository associated with CISA publicly exposed plaintext passwords, tokens, logs and high-privilege AWS GovCloud credentials, with Seralys validating that at least three exposed AWS accounts were still accessible at a high privilege level.
The incident is notable not just for the sensitivity of the affected environment, but because it demonstrates a common cloud failure mode: long-lived credentials are small, portable and easy to leak, yet they can immediately grant broad access to cloud accounts, internal systems and software delivery infrastructure. GitGuardian and Seralys found that the repository also contained internal Artifactory credentials and deployment-related files, expanding the risk from simple credential exposure to potential lateral movement and software supply chain compromise. The repository owner had reportedly disabled GitHub’s default secret protection and the exposed AWS keys reportedly remained valid for roughly 48 hours after notification. The core lesson is clear: organisations need visibility into long-lived credential use, privileged account sprawl, disabled repository security controls and delayed key revocation, because a trivial publication event can become a full cloud governance and enterprise risk issue.
| What Happened | Cause | Action |
|---|---|---|
| High-privilege cloud credentials were published to a public GitHub repository | The repository contained files such as importantAWStokens and Seralys validated that exposed credentials could authenticate to three AWS GovCloud accounts at a high privilege level |
Validate whether any long-lived AWS access keys exist for privileged identities, especially in GovCloud or restricted environments. Assess whether they are stored outside approved secret managers. SkySiege scans for IAM access key usage, privilege level, account reach, age and whether long-lived credentials exist where role-based or ephemeral access should be used. The best option is to avoid long lived credentials anyway. |
| Plaintext passwords for internal systems were stored in files and exposed externally | The repository included AWS-Workspace-Firefox-Passwords.csv with plaintext usernames and passwords for dozens of internal CISA systems, including a DevSecOps-related environment |
Validate whether plaintext credentials are stored in repositories, user workspaces, exported browser files, CSVs or build artefacts. |
| Secret-detection safeguards were deliberately disabled | GitGuardian reported the administrator disabled GitHub’s default setting that blocks users from publishing SSH keys or other secrets in public repositories | Validate repository and SCM security settings centrally, including secret scanning, push protection, public repo restrictions and exception workflows. Whilst SkySiege doesn’t currently support GitHub, in the cloud assesses whether protection mechanisms have been disabled as standard. |
| The repository appears to have been used as a synchronization scratchpad instead of a controlled engineering repository | Seralys observed a pattern consistent with an individual operator using the repository to sync files across differently configured environments, rather than maintaining a curated project repository | Validate whether unmanaged personal workflows are being used to move cloud credentials, scripts, exports and infrastructure data between systems. SkySiege checks key usage to understand the source including network and activity. If a key is used in multiple locations that helps identify where systems are being used to sync credentials. |
| Exposed credentials remained valid after notification | Seralys reported the GitHub account was removed quickly, but the exposed AWS keys remained valid for another 48 hours | Lock down long lived credentials so that if they exist then they are known and simple to revoke.. |
| Internal package infrastructure was exposed, creating supply chain risk | The archive reportedly included plaintext credentials to CISA’s internal Artifactory, which Seralys identified as a prime target for persistence and malicious package tampering | Validate access controls around artefact repositories, CI/CD package stores and deployment systems. As part of controls around long lived tokens this would also tie these tokens to their purpose ensuring that compromise is simple to follow through the chain. |
| Weak password construction increased blast radius even without the public leak | Seralys found easily guessed passwords, including patterns based on platform names followed by the current year | Validate password policy enforcement, especially for internal administrative systems and developer tooling. SkySiege explicitly checks password policies across the systems that it supports to prevent this sort of failure. |
| Governance failed to prevent a contractor from handling highly sensitive access unsafely | The repository was maintained by a Nightwing contractor, using a mix of CISA-associated and personal email identifiers and contained broad internal access material | With controls and visibility of long lived tokens and user access it becomes clear and automatable to discover non-compliant access with indentities from outside the intended domains and authentication paths. |
This incident shows how trivial data handling errors can become major cloud security events. Long-lived credentials are easy to copy, sync, export and publish, but they can represent direct control over entire cloud accounts, internal systems and spending. In this case, exposed AWS GovCloud credentials and internal passwords were not merely present in a public repository; some were reportedly still valid and highly privileged. That converts a basic repository hygiene issue into an enterprise access control failure.
The detection gap is equally important. GitHub protections were reportedly disabled, which means preventive controls were consciously weakened. If an organisation lacks visibility into disabled repository security settings, long-lived access key usage or privileged credential proliferation, it may not know that catastrophic exposure conditions already exist. The reported 48-hour delay in revoking valid AWS keys also points to an operational gap: if credential rotation is difficult, then static credentials become both a security risk and a resilience problem.
The governance weakness is broader than one user mistake. A contractor was apparently able to accumulate and handle cloud keys, internal passwords and software delivery credentials in an unmanaged way. That indicates weak guardrails around privileged access, third-party administration and software supply chain systems. For regulated or public-sector organisations, this also raises legal, compliance and reputational concerns because exposed credentials tied to sensitive government environments can trigger questions about access governance, incident response maturity and control enforcement.
Financial risk is also clear. High-privilege AWS credentials can enable resource abuse, destructive actions and unplanned spend in addition to data access. The practical lesson is to reduce long-lived credential use, monitor for unusual access patterns, enforce repository protections and maintain clear visibility into where cloud secrets exist and how quickly they can be revoked.
