Notifications
Clear all
Topic starter
01/08/2026 8:55 pm
TL;DR: Leftover GitHub sessions, OAuth grants, and personal access tokens behave as bearer credentials that can be stolen through phishing, leaked from machines, or left active after users move on, according to Exaforce. The real issue is standing access: revocation is the control that collapses exposure windows when authentication has already happened.
NHIMG editorial — based on content published by Exaforce: You don’t see me, therefore I am: Taking a look at abusing GitHub’s first party sessions for initial access
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: How should security teams govern GitHub non-human identities?
A: Security teams should govern GitHub non-human identities as a single entitlement surface, not as separate repository settings.
Q: Why do GitHub tokens remain risky after MFA is enabled?
A: Because MFA protects the login event, not the ongoing use of a token already issued.
Q: What breaks when GitHub token revocation is delayed?
A: The attacker keeps using the valid credential window for as long as it remains active.
Practitioner guidance
- Inventory all GitHub bearer credentials Map OAuth grants, GitHub App authorisations, personal access tokens, and CLI-stored credentials to an owner, scope, and revocation path.
- Automate emergency revocation workflows Use detection alerts to trigger immediate token invalidation for suspected phishing, lost devices, employee exits, or leaked secrets.
- Separate app grant review from user access review Review GitHub OAuth and app authorisations independently from human account recertification, because the credential may remain active after the user account looks clean.
What's in the full article
Exaforce's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step revocation paths for GitHub OAuth grants, GitHub App authorisations, and personal access tokens.
- Endpoint storage locations for GitHub CLI credentials on Windows, Linux, and macOS.
- GitHub API calls used to list and revoke organisation credential authorisations.
- Detection event patterns that help distinguish ordinary login activity from suspicious token abuse.
👉 Read Exaforce's analysis of GitHub first-party sessions and token revocation →
GitHub sessions and tokens: how long are your controls really standing?
Explore further
01/08/2026 9:03 pm
GitHub token exposure is not a point-in-time event, it is a standing access problem. Once a bearer credential exists, the attacker does not need to defeat authentication again. The control question becomes whether the organisation can revoke, rotate, and audit that access before it is used. For IAM and NHI teams, the practical lesson is that lifecycle governance is the real boundary, not login success.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
A question worth separating out:
Q: Who is accountable for revoking GitHub app authorisations after compromise?
A: The identity or platform team should own the control, but accountability must be shared with the application owner and incident response lead. If authorisations are not revocable within the containment process, the organisation has delegated too much trust to a session that no longer has a valid business purpose.
👉 Read our full editorial: GitHub first-party sessions create a standing access risk for IAM
