Contain first, then revoke in a controlled sequence that preserves evidence. Teams should invalidate tokens, rotate dependent credentials, inspect public repositories for exfiltration markers, and search for backdoors in developer workspaces and workflows. The goal is to close persistence paths before the attacker can repurpose stolen access.
What makes exposed GitHub tokens and SSH keys dangerous?
These secrets can grant immediate repository access, code changes, issue and workflow control, or shell access to build and developer systems. The practical risk is not just data exposure, but persistence: once an attacker can reuse a valid token or key, they may plant backdoors, harvest more secrets, and move into CI/CD or adjacent environments.
A GitHub token often carries broader blast radius than teams expect, especially when it can read private repositories, trigger workflows, or access package and deployment paths. An SSH key can be equally high impact because it may authenticate to servers, bastions, or developer workstations, which is why NHI governance guidance such as the OWASP Non-Human Identity Top 10 remains relevant when access material is exposed.
SSH exposure also deserves its own containment path because the key may already exist in authorised_keys files, agent caches, or automation scripts. NHIMG’s SSH Key and SSH Certificate Management Guide is useful here because the response has to cover both revocation and orphan cleanup, not just password-style rotation.
How should containment and revocation be sequenced?
Start by preserving evidence, then remove the attacker’s usable access in a controlled order. That usually means identifying every place the token or key could authenticate, invalidating the exposed secret, and only then rotating dependent credentials so you do not strand legitimate automation before you have mapped the blast radius.
The sequence matters because a rushed reset can break pipelines, hide attacker activity, or leave alternate access paths intact. For GitHub-specific incidents, watch for malicious workflow changes, repository settings drift, and newly added deploy keys or personal access tokens, since these are common persistence points after initial secret abuse.
Response teams should also treat exposed secrets as a source of secondary compromise. If a token or SSH key was able to reach build systems, repository management, or privileged hosts, assume the attacker may have used it to plant additional access, and review whether the exposed material was reused elsewhere in the environment.
In practice, incident evidence from campaigns like GhostAction returns 2026 and GitHub internal repositories breach 2026 shows why revocation and repository hunting need to happen together rather than as separate workstreams.
What should teams check after the token or key is revoked?
After the exposed secret is invalidated, teams should search for signs that it was already used: unusual repository clones, new workflow files, suspicious branch changes, added deploy keys, unexpected package publishes, or recent modifications to developer environments. They should also inspect public repositories, gists, build logs, and shell history for exfiltration markers or staged follow-on access.
That review should extend beyond GitHub itself. If the secret had access to cloud consoles, CI/CD platforms, container registries, or bastions, the investigation needs to check for persistence in those downstream systems as well. Credential exposure is often a gateway to more durable access, not the final objective.
Teams investigating SSH key exposure should verify whether the key appears in authorised_keys, automation scripts, deployment images, or CI variables, because those locations can preserve access long after the original credential is removed. A relevant case pattern is documented in NHIMG’s CI/CD pipeline exploitation case study, where exposed credentials enabled a workflow compromise and key planting on the target server.
Risk and Threat Considerations
Exposed GitHub tokens and SSH keys create a rapid path from secret theft to source code access, workflow tampering, and persistence. The main threat is that attackers often do not need to exploit a software flaw if a valid secret already gives them trusted access, especially in environments where developer tooling and automation share credentials.
Failure mechanism: The secret is reused before it is revoked, or it remains effective in one of its downstream trust paths, such as a workflow, deploy key, build runner, bastion, or workstation login. That allows the attacker to establish persistence, add new credentials, or harvest additional secrets before defenders complete rotation.
Impact: Compromise can spread from one exposed token or key into repository theft, CI/CD abuse, code tampering, and broader environment access. The longer the secret remains valid, the more likely the attacker can convert a single exposure into durable control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Exposed GitHub tokens and SSH keys are leaked secrets that enable unauthorized access. |
| NHI-01 — Improper Offboarding | Exposure response must remove residual access paths and orphaned credentials. | |
| NHI-05 — Overprivileged NHI | GitHub tokens and SSH keys often have broader access than teams expect. | |
| Recommendation — Rotate exposed secrets immediately and revoke any downstream access they enabled. Remove orphaned keys and tokens from every place they can still authenticate. Reduce token and key scope so compromise cannot reach repositories and production systems. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Tokens and SSH keys are authenticators that must be revoked and rotated after exposure. |
| AC-2 — Account Management | Exposed access material may require disabling or reviewing linked accounts and service access. | |
| Recommendation — Invalidate compromised authenticators and replace them on a controlled schedule. Review and disable any account or service path that still trusts the exposed secret. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | The incident involves stolen secrets that attackers can reuse for access and persistence. |
| Recommendation — Hunt for credential theft, reuse, and persistence after the exposure is contained. | ||
Practitioner Guidance
What to prioritise: Treat exposed GitHub access material as an active incident until you can prove the secret is dead everywhere it matters. The first decision is whether the secret can still authenticate to production or privileged systems, because that determines whether rotation must outrun the investigation.
Decision rule: If the token or SSH key can reach repositories, build infrastructure, or administrative hosts, revoke it first and then work outward through dependent credentials, sessions, and trust relationships. If the secret was scoped narrowly, you still need to verify whether it was copied into automation, caches, or cloned environments before declaring the incident contained.
What to verify: Confirm that repository permissions, deploy keys, workflow credentials, and server-side SSH authorisations no longer accept the exposed secret. Also confirm that logging and audit trails are intact, because evidence preservation is what lets you distinguish a controlled containment from a silent attacker fallback.
Practitioner takeaway: The right response is not “rotate later after triage”, it is “close the live access path now, then prove there is no second path left for the attacker to reuse.”
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org