Ghost-Token Bypass in OAuth Implementations [2026]

On paper, the so-called Ghost-Token exploit sounds like token forgery. In practice, it is a metadata and audience-binding failure: a client signs a perfectly valid JWT for one authorization server, and an attacker reuses it at another. One fact matters before anything else: as of May 15, 2026, there is no official specification named OAuth 3.0. The public issue lives in real OAuth 2.0 and OpenID Connect deployments, plus the standards work now tightening their rules.

CVE Summary Card

Reality Check

Two corrections keep this story grounded. First, oauth.net explicitly states that OAuth 3.0 does not exist; the active standards path is OAuth 2.1, still an IETF draft in March 2026. Second, the public technical name is not Ghost-Token. The standards and disclosure trail call it an audience-value ambiguity or audience-injection problem involving signed assertions such as privatekeyjwt.

• The exploit is real even if the headline label is informal.
• The blast radius is widest in brokers, integration hubs, and platforms that speak to many identity providers.
• The bug is architectural, not language-specific.

Vulnerable Code Anatomy

Where the Bug Actually Lives

The vulnerable move is subtle: the client constructs a signed assertion whose aud comes from attacker-controlled metadata, then sends that assertion to an endpoint other than the token endpoint. The attacker does not need to break signing. They only need the client to sign the wrong audience with the right key.

// Conceptual example only: do not copy into production.
const metadata = await discover(asBaseUrl);

const assertion = signJwt({
  iss: clientId,
  sub: clientId,
  aud: metadata.token_endpoint,
  jti: randomId(),
  exp: nowPlus(60)
}, sharedClientSigningKey);

await post(metadata.pushed_authorization_request_endpoint, {
  client_id: clientId,
  client_assertion_type: 'urn:ietf:params:oauth:client-assertion-type:jwt-bearer',
  client_assertion: assertion,
  request: signedRequestObject
});

That snippet looks routine. It is also exactly the pattern the standards updates are trying to kill. If metadata.token_endpoint is an attacker-selected value that points to, or impersonates, an honest server identity, the resulting JWT may be valid at the honest server.

Why the Server Accepts It

Historically, several specs allowed or encouraged token endpoint URLs as acceptable audience identifiers for JWT client authentication. That made interoperability easier, but it also blurred identity. An endpoint URL is a routing detail; an issuer is an identity boundary. Once those two concepts drift apart, replay becomes possible.

// Hardened pattern.
const metadata = await discover(asBaseUrl);
const issuer = validateIssuer(metadata.issuer, asBaseUrl);
const signingKey = keyStore.forIssuer(issuer);

const assertion = signJwt({
  iss: clientId,
  sub: clientId,
  aud: issuer,
  jti: randomId(),
  exp: nowPlus(60)
}, signingKey);

await post(metadata.pushed_authorization_request_endpoint, {
  client_id: clientId,
  client_assertion_type: 'urn:ietf:params:oauth:client-assertion-type:jwt-bearer',
  client_assertion: assertion,
  request: signedRequestObject
});

• Use the authorization server issuer as the sole audience.
• Keep signing keys scoped per issuer, not per app family.
• Refuse multi-value aud arrays for client assertions unless a current spec explicitly requires them.
• Do not let dynamically loaded metadata silently redefine trust boundaries.

Attack Timeline

Key Dates

• October 2012: RFC 6749 standardizes OAuth 2.0.
• February 2020: RFC 8707 defines resource indicators, an important primitive for audience-restricted access tokens.
• September 2021: RFC 9126 defines PAR, which later becomes one of the non-token endpoints relevant to this attack class.
• September 2023: RFC 9449 standardizes DPoP, giving implementers a sender-constraining option for access tokens.
• January 24, 2025: the OpenID Foundation publishes its responsible disclosure notice for the privatekeyjwt issue.
• January 2025: the issue is disclosed to the OAuth working group in an interim meeting called for that purpose.
• April 2025: the University of Stuttgart paper on audience injection appears in the Cryptology ePrint Archive as paper 2025/629.
• February 17, 2026: OpenID Federation 1.0 is published with the tightened audience direction folded into the standards response.
• May 15, 2026: public guidance is clear: there is no official OAuth 3.0, but there is a live remediation path for real implementations.

Why the Response Took the Shape It Did

This was not a one-vendor memory-corruption bug with a single patch train. It was a standards ambiguity crossing multiple documents, test suites, and conformance regimes. The result is slower but more durable: tighten audience rules in the specs, update conformance suites, and push ecosystems toward issuer-bound identity instead of endpoint-bound convenience.

Exploitation Walkthrough

Preconditions

• The client talks to at least two authorization servers.
• One authorization server is attacker-controlled, compromised, or maliciously configured.
• The client uses signed client authentication such as privatekeyjwt with the same key material across servers.
• The client authenticates to a non-token endpoint such as PAR, revocation, device authorization, or CIBA.

Conceptual Flow

1. The attacker exposes an authorization server configuration that looks valid enough to onboard.
2. The malicious metadata advertises an audience target that the honest authorization server would also accept, historically often a token endpoint URL.
3. The victim client begins a flow and signs a client assertion for the malicious server, but the signed aud now names the honest server identity.
4. Because the assertion is sent to a non-token endpoint controlled by the attacker, the attacker captures the signed JWT.
5. The attacker replays that JWT to the honest authorization server, which sees a valid client identifier, a valid signature, and an acceptable audience.
6. The honest server treats the attacker as the victim client and may issue tokens, accept pushed requests, or advance a broader account-takeover chain.

The key insight is that the attacker never forges the JWT. They coerce the victim client into producing it. That makes the exploit operationally attractive: it turns a standards-compliant signature into an attacker-owned credential.

Likely Impact

• Client impersonation against an honest authorization server.
• Unauthorized access token issuance under the victim client identity.
• Cross-tool or cross-tenant account binding errors in centralized OAuth brokers.
• Misleading logs, because every cryptographic check can still look clean.

During triage, avoid pasting raw JWTs, account identifiers, or callback URLs into tickets and chat. Sanitize captures first with the Data Masking Tool; the operational habit matters because these incidents often blend customer identifiers, issuer URLs, and token fragments in the same trace.

Hardening Guide

Client-Side Fixes

• Set aud to the authorization server issuer identifier only, as the sole audience value.
• Validate issuer metadata strictly and bind the chosen issuer to the entire flow context.
• Use separate signing keys for each authorization server, even when the same app integrates with many providers.
• Store the selected provider context in the user session and verify it again on callback.
• Prefer static trust onboarding for high-value providers instead of accepting arbitrary dynamic metadata.

Authorization Server Fixes

• Reject client assertions whose aud is not exactly your issuer identifier.
• Stop accepting a mix of issuer, token endpoint, and endpoint-specific URLs as equivalent audiences.
• Log issuer mismatches and repeated assertion identifiers as security events, not debug noise.
• Update conformance suites and negative tests so these cases fail by default.

Defense in Depth

• Use RFC 9207 issuer identification in authorization responses where applicable to reduce mix-up risk.
• Use RFC 8707 resource indicators so access tokens are audience-restricted to the intended resource server.
• Use sender-constrained access tokens with DPoP or mTLS where your ecosystem can support them.
• Keep PKCE, but treat it as table stakes for other threats, not a fix for audience injection.
• Continuously inventory every endpoint where client authentication occurs; many teams secure /token and forget /par, revocation, or device flows.

Architectural Lessons

Identity Is Not Routing

The deepest lesson here is that endpoint URLs are not identity. They are transport coordinates. Once a platform uses them as the canonical trust anchor for signatures, any metadata confusion becomes identity confusion.

Shared Keys Expand the Blast Radius

Reusing one signing key across many providers feels operationally tidy. It also means one successful audience confusion event can mint a credential that is valid across trust domains. Key reuse is not just a convenience choice; it is a threat model choice.

Central OAuth Brokers Need Stricter Context Binding

The IETF work following this disclosure also highlights broader multi-tool and cross-tenant confusion attacks. Platforms that orchestrate many connectors, agents, or tenant-defined OAuth providers need stronger binding between provider, tool, tenant, redirect URI, and user session than legacy single-provider apps ever needed.

• Bind every OAuth flow to a concrete connection context.
• Resolve issuer to endpoints, not endpoints to issuer.
• Treat metadata ingestion as a supply-chain surface.
• Fail closed when issuer, endpoint, key set, or client registration context drift apart.

The practical takeaway for engineering leaders is simple. Do not wait for a hypothetical OAuth 3.0 reset. The fix for Ghost-Token-class failures already exists today: issuer-first identity, per-server key isolation, and explicit context binding across every OAuth hop.