CVE-2025-27371OAuth 2.0 private_key_jwt audience ambiguity
What broke
The OpenID Foundation disclosed that the OAuth 2.0 JWT client-authentication profile (private_key_jwt) leaves the audience value underspecified. A client assertion minted for authorization server A can be accepted by authorization server B if both share a view of the client's key and neither pins aud tightly. CVE-2025-27371 is the OAuth-spec ID. CVE-2025-27370 is the OpenID twin.
There is no single vendor patch. The fix is in the spec text and in how implementations validate aud.
Why it matters
private_key_jwt is the "grown-up" client authentication. Banks, FAPI deployments, and high-assurance CIAM stacks use it specifically to avoid shared secrets. An audience mix-up turns that strength into a confused-deputy: a JWT meant for one environment or tenant is a valid login somewhere else.
What to do
- Pin
audto the exact authorization-server identifier (issuer or token-endpoint URL) your implementation now documents. Reject arrays that include extra values. - Separate client keys per environment and per tenant. Shared keys make the spec ambiguity exploitable.
- Track the OpenID Foundation and IETF errata. This is a spec-level CVE, so library defaults will lag.
After you patch
Token-layer flaws produce credentials that keep working after the patch, so remediation is about invalidating what was issued.
- Rotate the signing keys published at your JWKS endpoint, then confirm relying parties refetch on an unknown key id rather than caching indefinitely.
- Revoke refresh tokens and sessions. Access tokens expire on their own; refresh tokens are the ones that turn a short compromise into months of access.
- Audit client registrations and consent grants created during the window, particularly any client with broad scopes or a redirect URI you do not recognize.
- Verify validation on your side: pinned algorithms, issuer and audience checks, and no acceptance of
alg: none. See JWT and the validate a JWT recipe.
Sources
- NVD: CVE-2025-27371
- OpenID Foundation disclosure on private_key_jwt audience
Related identity CVEs
Related on Start with Identity
- CVEWordPress OAuth SSO plugin JWT bypass, admin takeover
The OAuth SSO WordPress plugin through 6.26.12 failed JWT signature verification. A forged token becomes an administrator. Patched in 6.26.13.
- CVEDrupal Simple OAuth/OIDC auth bypass via an alternate path
Drupal Simple OAuth / OIDC 6.0.0 through 6.0.6 allowed authentication to be skipped on an alternate path. Patched in 6.0.7.
- CVEDuende OAuth token management mixes tokens across requests
A race in Duende's .NET OAuth token-management package could attach client A's token to client B's request. Session mix-up, not a crypto break, but it is still
- GlossaryAccess Token
A short-lived credential a client presents to a resource server to access protected data. Access tokens are typically opaque or JWT-formatted, with lifetimes me
- GlossaryAgentic Identity
Identity for autonomous AI agents that act on a user's behalf, call APIs, and chain tools. Requires scoped, delegated, auditable, and revocable credentials rath
- GlossaryAuthorization Code Flow
The recommended OAuth 2.0 flow for apps with a user: the app receives a short-lived code, then exchanges it for tokens from a back channel. Combined with PKCE f
Technique
This CVE is an instance of Token replay against an unbound endpoint. A token that is not bound to the client, session, or challenge that requested it can be lifted once and replayed anywhere the check for binding is missing, no matter how it was strengthened.