Orphaned GitHub tokens turned a vendor share into breach access

At a glance

What this is: This is a breach analysis of an orphaned GitHub PAT that opened access to Klue and enabled theft of downstream OAuth tokens across customer SaaS integrations.

Why it matters: It matters because IGA, PAM, and SIEM controls that focus on humans can miss non-human identities whose access survives the relationship that created them.

👉 Read Unosecur's analysis of the orphaned GitHub token breach path

Context

An orphaned non-human identity is a credential that still works after the business reason for creating it has gone away. In this case, a GitHub Personal Access Token shared with a vendor was never revoked, so a third party's abandoned access path became the entry point into Klue's environment and then into customer SaaS integrations.

The identity governance failure is broader than one token. Once the attacker had standing access, they were able to harvest OAuth grants tied to customer connections and use legitimate APIs against Salesforce, Gong, and other SaaS systems. That shows why third-party NHI lifecycle control, not just endpoint or login security, has to be part of the access model.

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. The failure is lifecycle governance, not authentication strength. If the token can still reach production systems, it can be reused for legitimate API activity, lateral access, or data extraction until someone explicitly revokes it.

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. Once a token is authorised, it can keep reaching SaaS data through valid APIs even when the person who approved it has moved on. The practical risk is blast-radius expansion across connected systems, especially when one integration can touch multiple business datasets.

Q: How can security teams tell when a trusted integration is being abused?

A: Look for drift from the approved behavioural baseline. Unexpected source infrastructure, new user agents, API version changes, schema discovery, and unusually large QueryMore pagination bursts are all strong signals that a trusted integration is no longer acting normally. Those signals should be monitored as identity events, not just application logs.

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.

Technical breakdown

How an orphaned GitHub PAT becomes standing access

A GitHub Personal Access Token behaves like a non-human credential with fixed scope and no inherent expiry unless someone deliberately revokes it. When a token is issued for a vendor integration that never goes live, the business process that justified the token can disappear while the credential remains valid. That creates standing access with no live owner, no revalidation trigger, and no natural offboarding event. In practice, the token is still an authenticated path into the environment long after the relationship that created it has ended.

Practical implication: treat third-party PATs as lifecycle-managed identities, not disposable integration artifacts.

Why OAuth grants extend the blast radius beyond the first compromise

OAuth grants are delegated authorisations, not temporary login events. Once a customer authorises an integration, the token can keep acting independently of the human who approved it, and it may reach multiple SaaS objects through legitimate APIs. That is why one compromised integration credential can expose far more than the first target. The attack path here shows the difference between control of an account and control of the delegated access it already holds across connected services.

Practical implication: inventory delegated grants separately from user accounts and review the data scope each grant can reach.

Why standard monitoring missed valid API abuse

This incident did not rely on exploitation, phishing, or a broken platform control. It used valid credentials and normal APIs, which means perimeter and login-centric tooling had little reason to fire. The useful detection signal was behavioural: query volume, pagination patterns, and access timing that diverged from normal integration activity. In other words, the identity layer was the failure point because the activity was authorised but no longer trustworthy in context.

Practical implication: baseline NHI behaviour by token, integration, and API volume rather than by IP reputation alone.

Threat narrative

Attacker objective: The attacker aimed to turn one abandoned vendor credential into broad access to customer SaaS data and extortion leverage.

1. Entry occurred when an orphaned GitHub Personal Access Token, originally shared with a vendor, remained active after the integration was never deployed and the relationship ended.
2. Credential abuse followed when the attacker used that standing access to enter Klue's environment and push a code update that harvested customer OAuth tokens.
3. Escalation came through delegated access, as those OAuth tokens let the attacker query Salesforce, Gong, and other connected SaaS environments directly through legitimate APIs.
4. Impact was prolonged exfiltration lasting up to 24 hours per environment, with customer contacts, price quotes, sales communications, and competitive intelligence exposed.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

OAuth grant scope is the real blast-radius variable: The breach became materially larger after the attacker moved from the orphaned GitHub PAT to customer OAuth tokens. That is the point where one abandoned credential turned into a chained delegation problem across Salesforce, Gong, and other SaaS environments. Practitioners should read this as a warning that delegated access often outlives the oversight model that approved it.

Standing privilege without an owner is a broken assumption, not just a missing control: The token existed with no one actively responsible for it, no expiry pressure, and no monitoring tied to its normal behaviour. That assumption was designed for credentials that remain under human review. It fails when the access path is handed to a vendor, forgotten, and still usable years later. The implication is that governance has to track ownership drift, not merely credential presence.

Identity-layer detection is the only control plane that can see this pattern in time: SIEM, DLP, and PAM all have blind spots when an attacker works through valid OAuth sessions and ordinary APIs. What matters is whether the organisation can baseline normal token behaviour and detect deviation before exfiltration completes. For practitioners, the field is moving from access approval to access observability for every non-human identity.

Orphaned access creates compounded trust debt across the SaaS estate: The more integrations a vendor touchpoint reaches, the more every unrevoked token expands the downstream exposure set. That is why the named concept here is vendor orphaned access debt: every unreclaimed third-party credential adds future breach surface until it is explicitly retired. The practitioner conclusion is that offboarding must cover delegated grants, not just accounts.

What this signals

Vendor orphaned access debt: A third-party credential is only safe when its ownership, purpose, and revocation path stay aligned. Once those links break, the credential becomes dormant authority that can be reactivated by an attacker at any later point.

This breach also shows why access reviews alone are insufficient for non-human identities. Review cadences are too slow for credentials that can be exploited through legitimate APIs, so the control point has to move to issuance, delegation, and offboarding.

For practitioners, the immediate question is not whether the integration is trusted. It is whether every token that can act on behalf of the business is still justified, observable, and revocable today.

For practitioners

• 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. Anything without all three should be treated as an orphaned identity, not a forgotten secret.
• 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. Remove dormant grants before the next vendor relationship change or product decommission leaves them as standing access.
• 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. Behavioural baselines matter more than login success in this attack pattern.
• Tie NHI offboarding to vendor relationship offboarding Make contract termination, product decommission, and integration retirement trigger credential revocation in the same workflow. If the business relationship ends but the token remains valid, the identity governance process has not actually finished.

Key takeaways

• An abandoned vendor-issued GitHub PAT gave an attacker standing access and opened a path into customer SaaS environments.
• The incident demonstrates how one orphaned non-human identity can compound into broad OAuth-based exposure across multiple systems.
• The limiting control is lifecycle governance at issuance and offboarding, not just monitoring after the credential has already been used.

Key terms

• Orphaned Identity: An orphaned identity is a service account, token, or other machine credential that no longer has a clear owner, purpose, or retirement path. These identities create compliance and security risk because they are easy to forget, difficult to review, and often remain active long after they should have been removed.
• OAuth Grant: An OAuth grant is the delegated permission an application receives to act on a user's behalf without storing the user's password. In NHI governance, it should be treated as a standing identity relationship with scope, ownership, and revocation requirements, not as a one-time setup detail.
• Standing Access: Standing access is persistent privilege that remains available without fresh approval or contextual checks. In NHI environments, standing access usually appears as long-lived tokens, reusable service accounts, or broad roles attached to automation. It is convenient operationally, but it expands risk when conditions change or secrets leak.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.

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

👉 The full Unosecur analysis covers the token lifecycle failure, API abuse pattern, and post-incident containment details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.