Notifications
Clear all
Topic starter
15/08/2026 6:07 pm
TL;DR: A legacy GitHub Personal Access Token shared with a vendor and never revoked gave an attacker standing access to Klue's infrastructure, then exposed customer OAuth tokens across Salesforce, Gong and other SaaS environments, according to Unosecur. The breach shows that expired third-party credentials and ungoverned OAuth grants create a compounding NHI blast radius that standard IAM, SIEM, and PAM controls miss until it is too late.
NHIMG editorial — based on content published by Unosecur covering the Klue GitHub PAT and OAuth token breach chain: A GitHub PAT shared with a vendor years ago just became the entry point for hundreds of breaches
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
- Internal repositories are 6x more likely to contain secrets than public ones, at 32.2% versus 5.6%, contradicting the assumption that private repos are safe.
Questions worth separating out
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 NHI credentials increase SaaS breach risk?
A: Orphaned NHI credentials increase risk because they often retain fixed scopes, no owner review, and no behavioural monitoring, while still being able to authenticate to connected platforms.
Q: How do security teams know if a SaaS integration is behaving abnormally?
A: Teams should baseline normal query volume, pagination behaviour, object enumeration, and egress destinations for each integration identity.
Practitioner guidance
- Revoke vendor-shared credentials on relationship change Tie every third-party PAT, API key, and service credential to a named owner and a contract end date.
- Inventory connected SaaS grants as non-human identities Build a system-of-record for OAuth grants across Salesforce, Google Workspace, Gong, and similar platforms.
- Baseline API behaviour for every integration Measure normal query volume, pagination patterns, object enumeration, and egress destinations for each integration identity.
What's in the full article
Unosecur's full blog covers the operational detail this post intentionally leaves for the source:
- The full incident timeline, including how the original GitHub PAT was created, shared, and left active after the vendor relationship ended.
- The API log evidence showing how the attacker enumerated Salesforce objects and extracted data over up to 24 hours.
- The exact revocation and hunting steps Unosecur recommends across Salesforce, Google Workspace, and other connected SaaS services.
- The customer-facing indicators that distinguish normal integration traffic from a credential-driven extraction pattern.
👉 Read Unosecur's analysis of the orphaned GitHub PAT and OAuth breach chain →
Orphaned GitHub PATs and OAuth grants: what did this breach expose?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
15/08/2026 6:16 pm
Orphaned third-party credentials are not dormant assets, they are active breach pathways. This incident worked because a vendor-shared PAT survived the end of the business relationship, then retained standing access with no lifecycle offboarding. The governance failure is not simply that the token existed, but that ownership, expiry, and revocation were not tied to the vendor relationship lifecycle. Practitioners should treat every external credential as a live identity until proven otherwise.
A few things that frame the scale:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, showing that discovery without revocation leaves live exposure in place.
A question worth separating out:
Q: Who is accountable when a third-party identity compromise leads to customer exposure?
A: Accountability sits with the organisation that owns the trust relationship, not only with the vendor or subcontractor involved. If a third party can reach production identities, the internal team must own approval, lifecycle review, monitoring, and revocation. Shared responsibility does not remove the need for clear internal ownership.
👉 Read our full editorial: Orphaned GitHub tokens turned a vendor share into breach access
