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’s happening | 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 segmented environments and whether they are stored outside approved secret managers. SkySiege would assess IAM access key usage, privilege level, account reach, age and whether long-lived credentials exist where role-based or ephemeral access should be used. |
| 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. SkySiege would assess where credentials are embedded in cloud-connected workflows, whether those systems are internet-adjacent or privilege-bearing and whether secret storage practices create lateral movement risk. |
| 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. SkySiege would assess whether cloud-adjacent code repositories have protection mechanisms disabled for convenience and flag governance gaps that allow security controls to be overridden without review. |
| 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 would assess architectural dependence on individual operator behaviour, unmanaged tooling paths and cloud administration patterns that bypass approved platforms and controls. |
| 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 | Validate incident response runbooks for credential revocation, especially for privileged cloud identities. SkySiege would assess key rotation capability, time-to-revoke for exposed credentials, dependency on static credentials and whether revocation would break production or administrative workflows. |
| 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. SkySiege would assess whether exposed identities can access build systems, package registries or software distribution paths that would allow backdooring or broad downstream compromise. |
| 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 would assess whether weak authentication practices combine with cloud privilege and internal access paths to create clear post-compromise escalation routes. |
| 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 | Validate contractor access governance, identity separation, device trust and restrictions on handling privileged cloud credentials. SkySiege would assess whether third-party identities hold excessive privilege, whether account ownership and usage are attributable and whether governance controls meaningfully limit contractor-originated cloud risk. |
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.
