CVE-2025-27370OpenID private_key_jwt audience ambiguity
What broke
CVE-2025-27370 is the OpenID Connect identifier for the same private_key_jwt audience ambiguity as CVE-2025-27371. A client assertion is a JWT. If aud is not a single, exact identifier for the intended authorization server, another server that knows the client's public key may accept it.
Why it matters
OIDC deployments reuse OAuth client authentication. Multi-tenant SaaS IdPs and multi-region banks are the obvious victims: one environment's client JWT becomes another's. This is a protocol footgun, not a single product bug.
What to do
- Same control as 27371: exact
aud, per-environment keys, and a library that rejects surprising audiences. - Review FAPI deployments first. They lean on
private_key_jwtand sender-constrained tokens.
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-27370
- OpenID Foundation disclosure
Related identity CVEs
Related on Start with Identity
- 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
- GlossaryCIBA
Client-Initiated Backchannel Authentication. An OpenID Connect flow where authentication is initiated on one device and approved on another, useful for call cen
- GlossaryClaims
Statements about a subject carried in a token, such as subject identifier, email, roles, or expiry. Relying parties make authorization decisions from claims, so
- 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.
- CVEKeycloak session hijack via prompt=login re-authentication
Starting a new authentication with prompt=login could hijack an existing Keycloak session. The re-auth step did not bind to the original user tightly enough. Pa
- CVESimpleHelp accepts unsigned OIDC tokens, MFA bypass
SimpleHelp through 5.5.15 (and 6.0 pre-release) accepted OIDC ID tokens without signature verification, including alg:none. A forged token bypasses MFA. Patch i
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.