Topic starter
15/08/2026 6:07 pm
TL;DR: Unosecur reports that a legacy GitHub Personal Access Token shared with a vendor and never revoked gave an attacker standing access to Klue's infrastructure, then let them harvest OAuth tokens and query customer SaaS environments directly for up to 24 hours. Orphaned non-human identities create compounding blast radius because access persists after ownership, purpose, and monitoring have all disappeared.
Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “A GitHub PAT Shared With a Vendor Years Ago Just Became the Entry Point for Hundreds of Breaches”.
Key questions
Q: What breaks when a vendor-shared GitHub PAT is not revoked?
A: A vendor-shared GitHub PAT becomes an orphaned non-human identity, which means it can keep providing standing access long after the original business purpose ends.
Q: Why do orphaned OAuth grants create more risk than the first compromised token?
A: Because OAuth grants are delegated access, not just a login method.
Q: How can security teams tell when a trusted integration is being abused?
A: Look for drift from the approved behavioural baseline.
Practitioner guidance
- Audit third-party PAT ownership and expiry Find every GitHub Personal Access Token or similar credential issued for vendor work, then verify a current business owner, intended purpose, and revocation date.
- Revoke unused OAuth grants across SaaS tenants Review connected applications in Salesforce, Google Workspace, and other SaaS platforms for grants that no longer match active integrations.
- Baseline normal non-human identity behaviour Measure ordinary query volume, API call patterns, and pagination behaviour for each integration so you can spot when an authenticated credential starts behaving like a bulk extraction tool.
Bottom line: An abandoned vendor-issued GitHub PAT gave an attacker standing access and opened a path into customer SaaS environments.
What's in the full article
Unosecur's full breach analysis covers the operational detail this post intentionally leaves for the source:
- The exact sequence from orphaned GitHub PAT to downstream OAuth token harvesting
- The named SaaS environments and access paths implicated in the exfiltration
- The incident response steps and log indicators used to trace the API activity
- The vendor and customer-side actions that can close the access path after discovery
👉 Read Unosecur's analysis of the orphaned GitHub token breach path →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
15/08/2026 6:16 pm
Orphaned vendor credentials are now a primary breach path, not an edge case: This incident shows that a non-human identity created for a partner can survive long after the partner relationship ends and still retain effective access. That is a governance failure, not a technical anomaly. The lesson for the field is that third-party NHI lifecycle control must be treated as a first-class identity discipline, because expired business purpose does not automatically end credential authority.
A question worth separating out:
Q: When should teams treat third-party access as a governance problem instead of an operational one?
A: When access survives the relationship that created it. If a vendor integration remains valid after the project, contract, or deployment ends, the issue is no longer operational convenience. It becomes identity governance, because a forgotten credential can still authenticate, inherit downstream grants, and expose data long after the original approval is obsolete.
👉 Read our full editorial: Orphaned GitHub tokens turned a vendor share into breach access