Notifications
Clear all
Topic starter
19/08/2026 3:30 pm
TL;DR: A compromised third-party OAuth grant let attackers reach Vercel without breaching Vercel directly, and Expel’s hunt showed why consented app access must be treated as part of the identity perimeter. OAuth permissions are only as safe as the apps and users that hold them, so excessive grants and unexpected app access remain high-value investigation targets.
NHIMG editorial — based on content published by Expel covering the Vercel OAuth supply chain breach: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
Questions worth separating out
Q: How should security teams govern third-party OAuth grants in enterprise environments?
A: Security teams should treat third-party OAuth grants as privileged access, not as ordinary app settings.
Q: Why do compromised OAuth apps create such a high-risk access path?
A: Because the attacker inherits legitimate delegated access rather than forcing a fresh login or password compromise.
Q: What breaks when organisations cannot see third-party app consent clearly?
A: They lose the ability to distinguish sanctioned integrations from shadow apps, and incident scoping becomes slow and incomplete.
Practitioner guidance
- Inventory every third-party OAuth grant Build a current list of approved applications, scopes, owners, and last-used dates so hidden grants can be reviewed before they become incident paths.
- Restrict user-granted scopes by policy Limit which permissions end users can approve, especially for read-write access, mailbox access, data export, and offline token scopes.
- Hunt for unexpected client IDs Search identity logs and consent records for unfamiliar application client IDs, then validate whether those apps are sanctioned or should be removed.
What's in the full analysis
Expel's full analysis covers the operational detail this post intentionally leaves for the source:
- How the compromised OAuth application client ID was used during customer hunts and what that reveals about scoping work
- The exact investigation approach for finding excessive or unexpected OAuth consent grants across environments
- Practical guidance on restricting what permissions users can grant to third-party applications
- The reference details around the disclosed client identifier and why app identity matters in incident response
👉 Read Expel's analysis of the Vercel OAuth supply chain breach →
OAuth consent grants and shadow app risk: what IAM teams need to know?
Explore further
19/08/2026 4:13 pm
Delegated access has become part of the identity perimeter. OAuth grants now function like durable machine-to-machine trust links, so a compromised third-party app can inherit access without touching the primary organisation’s login controls. That shifts the governance problem from authentication alone to consent lifecycle, scope review, and revocation discipline. Practitioners should treat every approved app as an identity object with an owner, purpose, and expiry.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: How can organisations reduce risk from third-party OAuth integrations?
A: Organisations should inventory every integration, limit scopes to business necessity, and monitor token behaviour for abnormal timing, volume, or source location. They should also review vendors that can hold refresh tokens, because a compromise in that layer can extend into many downstream environments.
👉 Read our full editorial: OAuth supply chain abuse exposed Vercel data through third-party access
