CVE-2025-27371: OAuth 2.0 JWT Auth Bypass Vulnerability

CVE-2025-27371 Overview

CVE-2025-27371 affects IETF OAuth 2.0-related specifications that implement the JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication. The vulnerability stems from ambiguities in the audience (aud) claim values of JWTs sent to authorization servers. The impacted specifications include RFC 7523, RFC 7521, RFC 7522, RFC 9101 (JWT-Secured Authorization Request, JAR), and RFC 9126 (Pushed Authorization Requests, PAR). This ambiguity can allow a JWT intended for one endpoint to be accepted at another, enabling client impersonation under specific conditions. The issue is a specification-level flaw rather than a single product defect, so it affects any implementation that follows the ambiguous audience handling described in these RFCs.

Critical Impact
Attackers can potentially reuse a private_key_jwt client assertion across OAuth 2.0 endpoints, enabling client impersonation and integrity compromise of authorization flows.

Affected Products

OAuth 2.0 authorization servers implementing RFC 7523 private_key_jwt and client_secret_jwt client authentication
OpenID Connect providers relying on JWT-based client authentication
Implementations of RFC 9101 (JAR) and RFC 9126 (PAR) that accept audience-scoped JWTs

Discovery Timeline

2025-03-03 - CVE-2025-27371 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-27371

Vulnerability Analysis

The vulnerability is classified under [CWE-305] (Authentication Bypass by Primary Weakness) and applies to how authorization servers validate the aud claim in client assertion JWTs. RFC 7523 permits the audience value to identify the authorization server, but does not strictly require a per-endpoint identifier. As a result, a JWT crafted for one endpoint, such as the token endpoint, may satisfy audience checks at another endpoint, such as PAR or JAR endpoints. An attacker who obtains or intercepts such an assertion can replay it at a different endpoint accepted by the same authorization server. This undermines the intent of private_key_jwt and client_secret_jwt authentication, which is to bind an assertion to a specific relying party interaction. The flaw exists in the protocol design rather than in a single library, so mitigation depends on implementers tightening validation logic.

Root Cause

The root cause is under-specified audience semantics across multiple OAuth 2.0 RFCs. The specifications allow the audience value to be the issuer identifier or the authorization server URL, rather than requiring a distinct value per endpoint. This ambiguity lets a single JWT satisfy validation checks at multiple endpoints that share the same audience identifier.

Attack Vector

Exploitation requires network access to the authorization server and user interaction, and the attack complexity is high. An adversary who can capture a valid client assertion, for example through a misrouted request or a confused deputy scenario, can present that assertion at a different endpoint of the same authorization server. The scope changes because the compromise crosses trust boundaries between endpoints. See the IACR analysis of the flaw and the OpenID Foundation responsible disclosure notice for technical details.

No verified public proof-of-concept code is available. The vulnerability mechanism is described in the referenced specifications analysis rather than as a concrete exploit against a specific product.

Detection Methods for CVE-2025-27371

Indicators of Compromise

Client assertion JWTs where the aud claim points to a generic issuer or server URL rather than a specific endpoint URL.
Repeated presentation of identical JWT jti values across token, PAR, and JAR endpoints within a short window.
Unexpected client authentication events at endpoints that a given client does not normally use.

Detection Strategies

Log and correlate the aud, iss, sub, and jti claims of every client assertion accepted by the authorization server.
Alert on client assertions whose aud value does not match the exact endpoint URL that received the request.
Detect reuse of the same jti at more than one endpoint, which indicates cross-endpoint replay.

Monitoring Recommendations

Ingest authorization server audit logs into a centralized analytics platform and retain them long enough to investigate multi-step flows.
Baseline normal client behavior per endpoint, including which clients use PAR, JAR, and the token endpoint.
Monitor for anomalous spikes in failed audience validation errors, which may indicate probing activity.

How to Mitigate CVE-2025-27371

Immediate Actions Required

Configure authorization servers to require the aud claim in client assertions to equal the exact endpoint URL that receives the request.
Reject client assertions whose audience is a generic issuer identifier when stricter endpoint-specific validation is available.
Enforce single-use semantics on the jti claim across all endpoints, not per endpoint.

Patch Information

No single vendor patch resolves this vulnerability because it is a specification-level issue. Implementers should follow updated guidance from the OpenID Foundation security notice and monitor IETF OAuth working group updates. Review the OWASP ASVS discussion and the OSW 2025 presentation for concrete implementation guidance.

Workarounds

Restrict acceptable aud values to a strict allowlist of full endpoint URLs per authorization server component.
Bind client assertions to the specific request by including a hash of request parameters where the profile supports it.
Shorten JWT lifetimes for client assertions to reduce the window for replay across endpoints.
Where feasible, use mutual TLS (mTLS) client authentication as an alternative to private_key_jwt until implementations are hardened.

bash

# Configuration example: strict per-endpoint audience validation (pseudocode)
client_authentication:
  method: private_key_jwt
  audience_validation: strict
  allowed_audiences:
    token_endpoint: "https://as.example.com/oauth2/token"
    par_endpoint:   "https://as.example.com/oauth2/par"
    jar_endpoint:   "https://as.example.com/oauth2/jar"
  jti_replay_protection: global
  max_assertion_lifetime_seconds: 60