Orphaned GitHub tokens turned a vendor share into breach access

At a glance

What this is: An orphaned GitHub PAT and downstream OAuth grants created a multi-tenant NHI breach path with valid API access.

Why it matters: It matters because identity teams must govern third-party credentials, SaaS integrations, and behavioral monitoring together, or one stale token can expose many connected environments at once.

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.
• 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.

👉 Read Unosecur's analysis of the orphaned GitHub PAT and OAuth breach chain

Context

A non-human identity becomes dangerous when it outlives the purpose it was created for. In this case, a GitHub Personal Access Token shared with a vendor remained active for years after the integration was never deployed and the relationship had ended, which turned a forgotten credential into a standing entry point for the attacker. The primary problem is NHI governance, not software vulnerability.

The second governance gap is blast-radius control across SaaS integrations. Once the attacker used the orphaned token, they moved through legitimate APIs to harvest OAuth grants from hundreds of customer environments, showing how one unmanaged credential can become a multiplier across Salesforce, Gong, and other connected platforms. That is a typical failure pattern in third-party identity oversight, not an edge case.

Standard IAM views rarely surface OAuth grants, vendor-held tokens, or integration behaviour baselines in one place, so these credentials escape quarterly review and identity tooling focused on humans. The result is a blind spot where the access is valid, the APIs are legitimate, and the attack only becomes visible after the exfiltration has already happened.

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 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. In SaaS environments, one stale token can chain into many OAuth grants and customer datasets. The danger is not the single credential alone, but the access graph it can reach.

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. If a token that usually generates light background traffic suddenly performs sustained extraction or hits many objects in a short window, that is an identity anomaly. The signal comes from comparing behaviour against the integration's own normal pattern.

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.

Technical breakdown

Orphaned GitHub PATs as standing NHI access

A GitHub Personal Access Token is a non-human identity because it authenticates independently of a person and persists until revoked or expired. In this case, the token had fixed scope, no MFA challenge, no owner-driven review cycle, and no effective expiry discipline, so it remained usable long after the vendor relationship ended. That makes the token an orphaned identity: valid access without an active governance relationship. The technical failure is not exploitation of a bug but abuse of legitimate credentials that retained reach across time.

Practical implication: treat every vendor-shared PAT as a governed identity with lifecycle state, owner, expiry, and revocation checkpoints.

OAuth grants as inherited access to connected SaaS data

OAuth grants are not configuration flags. They are access tokens that can continue to act on behalf of an integration even when the original user or vendor workflow is no longer active. In this incident, the attacker used the compromised foothold to query customer Salesforce and Gong environments through ordinary API calls, which means the attack surface expanded from one stale credential to many downstream non-human identities. The security problem is that each grant carries its own authorization history, but most programmes do not track them with the same discipline as human accounts.

Practical implication: inventory every connected app, map its scopes, and revoke grants that cannot be justified by an active business relationship.

Why SIEM, DLP, and PAM did not stop the exfiltration

The logs existed, but conventional controls were watching the wrong layer. SIEM rules tuned to impossible travel or unusual logins do not flag known integration IPs, DLP often cannot distinguish legitimate OAuth-authenticated API extraction from normal use, and PAM generally governs human elevation rather than vendor-held machine credentials. The useful detection pattern here is behavioural: a known integration suddenly issuing query volumes far beyond baseline, across sustained pagination and object enumeration. That is an NHI monitoring problem, not a perimeter problem.

Practical implication: baseline non-human API behaviour and alert on abnormal query volume, pagination patterns, and object enumeration bursts.

Threat narrative

Attacker objective: The attacker aimed to turn one stale third-party credential into broad SaaS access and extortion leverage across many customer environments.

1. Entry occurred when an attacker obtained a legacy GitHub Personal Access Token that had been shared with a vendor and never revoked, giving standing access to Klue's environment.
2. Escalation happened when that foothold was used to harvest OAuth tokens tied to customer integrations and to query Salesforce and Gong environments through legitimate APIs.
3. Impact followed when the attacker exfiltrated contacts, price quotes, sales communications, and competitive intelligence across hundreds of customer environments for up to 24 hours.

Breaches seen in the wild

• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Compounding blast radius is the real risk in SaaS integration governance. One compromised NHI did not just expose the owning organisation, it inherited customer OAuth grants and turned those grants into a multi-tenant extraction path. That is why NHI governance must include downstream reach, not just credential existence. The practitioner lesson is to map not only who holds a token, but what that token can chain into across SaaS ecosystems.

Identity review cadences fail when the access object is a machine credential with no human usage rhythm. Quarterly access reviews assume visible human ownership and stable entitlements; a PAT or OAuth grant can remain valid, idle, and unreviewed for years. The implication is not to review harder, but to recognise that the review model itself breaks when non-human identities outlive the business context that created them.

Behavioral monitoring is now a core NHI control, not an advanced detection layer. The attack stayed within legitimate APIs precisely because the security stack was looking for authentication anomalies instead of identity behaviour anomalies. NHI programmes need to treat query volume, pagination, object enumeration, and egress patterns as first-class identity signals. Without that shift, valid credentials remain invisible until after exfiltration.

Identity blast radius is the right concept for this class of breach. The useful question is no longer whether one token is valid, but how far that token can propagate access through vendors, integrations, and customer-connected systems. This breach shows that blast radius is determined by governance depth, not by the number of authentication layers. Practitioners should build controls around propagated reach, not isolated credentials.

From our research:

• 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.
• From our research: 64% of valid secrets leaked in 2022 are still valid and exploitable today, showing that discovery without revocation leaves live exposure in place.
• From our research: Read 52 NHI Breaches Analysis for related breach patterns that show how standing credentials keep extending blast radius across environments.

What this signals

Identity blast radius now matters more than isolated credential hygiene. A single orphaned token can cascade into customer OAuth grants, which means governance teams need a full map of propagated access rather than just a count of active credentials. That same logic appears across [the Secret Sprawl Challenge](https://nhimg.org/the-secret-sprawl-challenge) and the broader NHI breach landscape.

With 64% of valid secrets leaked in 2022 still valid and exploitable today, per The State of Secrets Sprawl 2026, the operational lesson is clear: detection without automated revocation leaves real exposure in place. Security teams should expect stale credentials to become active attack paths, not historical artefacts.

Orphaned credential governance: this breach shows that the control problem is lifecycle closure, not simply secret storage. Teams that already track workload identity and third-party access should extend the same discipline to vendor-shared PATs, OAuth grants, and any integration that can query production data.

For practitioners

• 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. Revoke the credential when the integration is not deployed, the vendor relationship ends, or the business purpose changes, and require explicit re-approval before reissue.
• Inventory connected SaaS grants as non-human identities Build a system-of-record for OAuth grants across Salesforce, Google Workspace, Gong, and similar platforms. Record scopes, last activity, issuing party, and downstream data reach so that grants can be reviewed as identities rather than as app settings.
• Baseline API behaviour for every integration Measure normal query volume, pagination patterns, object enumeration, and egress destinations for each integration identity. Alert when a credential suddenly exceeds its normal pattern, especially during sustained extraction from high-value objects.
• Separate human PAM from machine credential governance Do not assume privileged access tooling covers vendor-held tokens or OAuth sessions. Create a dedicated control path for non-human identities that handles issuance, expiry, scope review, and immediate revocation across SaaS and cloud services.

Key takeaways

• A stale vendor-shared GitHub PAT created the first foothold, proving that orphaned non-human identities can outlive business purpose and become live breach access.
• The breach scaled through legitimate OAuth grants and API calls, which shows that the true risk is propagated blast radius across connected SaaS systems.
• Revocation on relationship change, behavioural baselining, and dedicated NHI governance would have reduced or stopped the attack before customer data left the environment.

Key terms

• Orphaned NHI: An orphaned NHI is a non-human identity that remains active without a clear owner, business purpose, or lifecycle path. These identities often survive employee departures, application changes, or missed deprovisioning steps, which makes them difficult to review and risky to leave in place.
• 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.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Behavior Baseline: A record of normal activity for a non-human identity, including typical consumers, resources, and actions over time. Baselines help security teams detect when an identity is being used in an unusual way and provide the context needed to enforce least privilege safely in dynamic environments.

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.

👉 Unosecur's full post covers the API evidence, customer impact, and immediate revocation steps in detail.

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 identity security capability across human and non-human access, it is worth exploring.