CVE-2025-27370: OpenID Connect Auth Bypass Vulnerability

CVE-2025-27370 Overview

CVE-2025-27370 is an audience injection vulnerability in OpenID Connect Core through 1.0 errata set 2. The flaw affects the private_key_jwt client authentication mechanism. A malicious Authorization Server can trick a Client into writing attacker-controlled values into the JWT aud (audience) claim. These attacker-influenced audience values may include token endpoints or issuer identifiers belonging to other Authorization Servers. The malicious Authorization Server can then replay the signed private key JWT to impersonate the Client against a legitimate Authorization Server. The vulnerability is categorized under [CWE-305]: Authentication Bypass by Primary Weakness.

Critical Impact
A malicious Authorization Server can capture private key JWTs and reuse them to impersonate legitimate OpenID Connect Clients across federated identity ecosystems.

Affected Products

OpenID Connect Core through 1.0 errata set 2
Client implementations using the private_key_jwt authentication method
Federated identity deployments trusting multiple Authorization Servers

Discovery Timeline

2025-03-03 - CVE-2025-27370 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-27370

Vulnerability Analysis

OpenID Connect Core defines private_key_jwt as a client authentication method. The Client generates a JSON Web Token (JWT), signs it with its private key, and sends it to the Authorization Server's token endpoint. The JWT contains an aud (audience) claim identifying the intended recipient. The specification permits several acceptable values for aud, including the token endpoint URL and the Authorization Server's issuer identifier.

The vulnerability arises when a Client interacts with an Authorization Server that returns metadata directing the Client to place attacker-chosen values in the aud claim. Because the resulting JWT is signed by the legitimate Client, any recipient matching the audience will accept it as authentic Client authentication. The malicious server can forward the signed JWT to a different Authorization Server where the Client also holds registration, achieving Client impersonation.

Root Cause

The root cause is insufficient constraint on the aud claim value during Client-side JWT construction. Client libraries derive the audience from Authorization Server metadata rather than pinning it to a value the Client independently trusts. This gap in cryptographic binding between the assertion and the intended verifier enables cross-server token replay.

Attack Vector

Exploitation requires the target Client to authenticate against a malicious or compromised Authorization Server using private_key_jwt. The attacker manipulates issuer or token endpoint metadata so the Client emits a signed assertion carrying an aud value belonging to a second, trusted Authorization Server. The attacker then presents the captured JWT to that second server, authenticating as the victim Client. User interaction is required to initiate the flow, and attack complexity is high. Full technical analysis is available in the IACR Research Paper and the OpenID Security Vulnerability Notice.

Detection Methods for CVE-2025-27370

Indicators of Compromise

Signed private_key_jwt assertions where the aud claim references an Authorization Server different from the one receiving the request
Token endpoint requests presenting Client assertions issued to another issuer identifier
Unexpected Client authentication successes originating from unusual network sources or IP ranges
Authorization Server metadata endpoints returning issuer or token endpoint values that deviate from published federation records

Detection Strategies

Log every incoming client_assertion at the token endpoint and record its iss, sub, aud, and jti claims for correlation
Alert when the aud claim of a Client assertion does not equal the receiving Authorization Server's canonical issuer identifier or token endpoint URL
Detect jti reuse across different Authorization Servers within a federation to identify replayed assertions
Baseline expected Authorization Server metadata and flag Clients that fetch metadata from unregistered endpoints

Monitoring Recommendations

Instrument OpenID Connect libraries to emit telemetry containing the resolved aud value before signing the assertion
Forward Client authentication logs to a centralized data lake for long-term retention and cross-server correlation
Monitor DNS and TLS certificate changes on Authorization Server discovery endpoints to identify metadata tampering

How to Mitigate CVE-2025-27370

Immediate Actions Required

Inventory all Clients that use the private_key_jwt authentication method across your identity infrastructure
Restrict trusted Authorization Servers to a pinned allowlist rather than accepting any discovered metadata
Update OpenID Connect client libraries once vendors publish patched releases that constrain the aud claim
Rotate Client signing keys after applying fixes if interaction with untrusted Authorization Servers occurred

Patch Information

The OpenID Foundation has published guidance and coordinated disclosure materials describing the required specification and implementation changes. Review the OpenID Disclosure Document for the authoritative remediation guidance. Client library maintainers should validate that the aud claim is bound to a value the Client independently derives from its own configuration for the target Authorization Server.

Workarounds

Configure Clients to pin the aud claim to a static, per-Authorization-Server value rather than resolving it dynamically from remote metadata
Use distinct signing keys for each Authorization Server relationship to limit the blast radius of a captured assertion
Set short expiration (exp) windows on Client assertions and enforce single-use jti tracking on the receiving side
Where feasible, migrate high-value Clients to authentication methods bound to the target endpoint, such as mutual TLS (mTLS) client authentication

bash

# Configuration example
# Refer to vendor-specific documentation for exact syntax.
# See the OpenID Foundation disclosure notice for authoritative remediation guidance.