CVE-2025-27370 in Connect
Summary
by MITRE • 03/03/2025
OpenID Connect Core through 1.0 errata set 2 allows audience injection in certain situations. When the private_key_jwt authentication mechanism is used, a malicious Authorization Server could trick a Client into writing attacker-controlled values into the audience, including token endpoints or issuer identifiers of other Authorization Servers. The malicious Authorization Server could then use these private key JWTs to impersonate the Client.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 06/01/2025
The vulnerability identified as CVE-2025-27370 affects the OpenID Connect Core specification through version 1.0 errata set 2 and represents a critical audience injection flaw that undermines the security of the authentication flow. This vulnerability specifically manifests when the private_key_jwt authentication mechanism is employed, creating a scenario where a malicious authorization server can manipulate client applications into accepting attacker-controlled audience values. The flaw resides in the improper validation of audience claims within the token processing pipeline, allowing for unauthorized modification of critical identity attributes that should remain under the control of legitimate service providers.
The technical implementation of this vulnerability exploits the trust relationship between clients and authorization servers within the OpenID Connect framework. When a client application authenticates using private_key_jwt, it typically validates the audience claim to ensure that tokens are intended for its specific service. However, the flaw allows a malicious authorization server to inject arbitrary audience values that include token endpoints or issuer identifiers of other authorization servers. This injection occurs during the token validation process, where the client fails to properly verify that the audience values correspond to legitimate and expected service endpoints. The vulnerability is particularly dangerous because it leverages the trust model inherent in the OpenID Connect protocol, where clients inherently trust the authorization server to provide valid tokens.
The operational impact of this vulnerability extends beyond simple authentication bypasses, creating a sophisticated attack vector that enables cross-authorization server impersonation. An attacker who successfully exploits this vulnerability can manipulate client applications into treating tokens from malicious servers as legitimate, effectively allowing them to impersonate the client to other authorization servers. This creates a chain reaction where compromised clients can be used to gain access to additional services, potentially leading to widespread credential compromise and unauthorized data access. The attack scenario involves a malicious authorization server that can inject arbitrary audience claims into tokens, causing the client to accept these tokens as valid for authentication purposes, thereby undermining the fundamental security assumptions of the OpenID Connect protocol.
From a cybersecurity perspective, this vulnerability aligns with CWE-290 authentication bypass weaknesses and maps to ATT&CK technique T1566.002 for social engineering via phishing, as it exploits trust relationships within the authentication infrastructure. The vulnerability's impact is particularly severe because it affects the core authentication mechanism that underpins numerous identity and access management systems. Organizations implementing OpenID Connect with private_key_jwt authentication are at risk of having their clients compromised, potentially leading to unauthorized access to sensitive systems and data. The attack requires minimal privileges from the attacker's perspective, as they only need to control a malicious authorization server to manipulate legitimate clients.
Mitigation strategies for this vulnerability should focus on implementing robust audience validation mechanisms within client applications. Organizations should ensure that client implementations perform strict validation of audience claims against known and expected service endpoints, rejecting any tokens that contain unexpected audience values. The recommended approach includes implementing a whitelist of acceptable audience values and performing comprehensive validation during token processing. Additionally, organizations should consider implementing additional security controls such as token introspection services, where clients can verify token validity with the authorization server before accepting tokens. Regular security assessments and code reviews focused on authentication flows are essential to identify and remediate similar vulnerabilities in identity management systems. The fix should involve updating client implementations to properly validate audience claims and reject tokens that contain unexpected or attacker-controlled audience values, ensuring that the trust relationship between clients and authorization servers remains intact.