GHSA-9mrv-8pvf-hf4m
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain valid JWT from shared issuer
-
DeliveryIdentify peer CXF Resource Server
-
ExploitReplay token against unintended audience
-
ExecutionPass JwtAccessTokenValidator without aud check
-
PersistInvoke privileged API on victim service
-
ImpactExfiltrate or modify data across trust boundary
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Alternate name authentication
|
| Exploitation Conditions | Exploitation requires (1) the target service to use Apache CXF's JwtAccessTokenValidator (i.e. the CXF RS Security OAuth2/JWT Resource Server stack is enabled), (2) two or more Resource Servers sharing the same Authorization Server / signing trust so that a token minted for one is cryptographically valid at another, and (3) the attacker to already hold a valid, signed, unexpired JWT issued by that shared issuer for a different audience - typically because they are a legitimate client of another service in the federation, which is why CVSS sets PR:H. No user interaction is required and the request is unauthenticated from the target Resource Server's perspective. Exploitation is limited where each Resource Server has its own dedicated issuer/signing key, where audience enforcement is configured explicitly via rs.security.jwt.expected-audiences, or where CXF is used without its JWT-based OAuth2 stack. |
| Impact | Signals point in different directions and need to be reconciled. NVD scores this CVSS 9.1 (Critical) driven by S:C (scope change across Resource Servers) and full C:H/I:H/A:H, but PR:H tells the real story: the attacker must already possess a valid, signed JWT from the shared issuer, which is typically obtained by being a legitimate but lower-trust client of another Resource Server. EPSS is only 0.02% (4th percentile) and the CVE is not listed in CISA KEV; no public exploit was identified at time of analysis, so this is not a mass-exploitation candidate. The realistic risk is concentrated in multi-tenant OAuth2 deployments where one issuer mints tokens for several CXF-based Resource Servers with differing trust levels - there, a malicious or compromised tenant can pivot horizontally. For single-audience or single-RS deployments, real-world risk is materially lower than 9.1 suggests. Note also a minor data tension: the public 'Apache, Information Disclosure, Cxf' tag understates impact, which the CVSS vector flags as I:H/A:H as well. |
| Exploit ScenarioDerived | A legitimate but low-trust client of Resource Server A (say, a reporting API) obtains a valid JWT from the shared Authorization Server. Because CXF's JwtAccessTokenValidator on Resource Server B (say, a payments API) does not check that 'aud' equals B, the attacker presents the same bearer token to B and is silently authenticated with the privileges the token carries, allowing data access or modification on a service they were never authorized for. No POC is publicly known at time of analysis, but the attack reduces to a single replayed HTTP request and is trivial to script once a valid token is held. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv3 – Jun 15, 2026
Token confusion in Apache CXF's JwtAccessTokenValidator allows an attacker holding a valid JWT issued for one Resource Server to replay it against an unrelated Resource Server because the 'aud' (Audience) claim is not validated. Affects Apache CXF 4.2.0 through 4.2.1 and all versions prior to 4.1.7, enabling cross-service authentication bypass with full confidentiality, integrity, and availability impact on the unintended target. No public exploit identified at time of analysis and EPSS is very low (0.02%, 4th percentile), but the fix is straightforward and the issue is structurally severe for federated OAuth2/JWT deployments.
Earlier versions of this analysis (2)
Token confusion in Apache CXF's JwtAccessTokenValidator allows authenticated attackers to replay JWT access tokens issued for one Resource Server against a different Resource Server because the 'aud' (Audience) claim is not validated. Versions 4.2.0 through 4.2.1 and all releases prior to 4.1.7 are affected, with the vendor releasing fixes in 4.2.2 and 4.1.7. There is no public exploit identified at time of analysis and EPSS is very low (0.02%), but the architectural impact on federated OAuth2/JWT deployments is significant.
Token Confusion attack in Apache CXF's OAuth2 JWT validation layer allows a bearer token issued for one Resource Server to be replayed against a different Resource Server without rejection. The JwtAccessTokenValidator class omits validation of the 'aud' (Audience) claim - and per the advisory title, also the 'iss' (Issuer) claim - enabling cross-service token routing attacks across all deployments of the cxf-rt-rs-security-oauth2 artifact below version 4.1.7 or between 4.2.0 and 4.2.1. No public exploit code has been identified at time of analysis, but the vulnerability class is well-understood and straightforward to exploit in multi-service architectures. Vendor-released patches 4.2.2 and 4.1.7 were published June 10, 2026.
RemediationAI
Vendor-released patch: upgrade to Apache CXF 4.2.2 (for the 4.2.x line) or 4.1.7 (for 4.1.x and earlier), both of which add proper validation of the JWT 'aud' claim in JwtAccessTokenValidator; consult https://lists.apache.org/thread/0jfzz9q992957b99tw7hodcqjfyxwb1m and https://seclists.org/oss-sec/2026/q2/887 for the official notice. If immediate patching is not possible, configure the OAuth2/JWT consumer to enforce a strict expected audience by setting the rs.security.jwt.expected-audiences (and related rs.security.audiences) properties so token validation fails when the 'aud' value does not match the local Resource Server identifier - trade-off is that any client still issuing audience-less tokens will be rejected and must be reconfigured. Alternatively, segment the OAuth2 deployment so each Resource Server uses a dedicated Authorization Server or signing key, which eliminates the cross-server replay but increases operational complexity and key-rotation burden. As a network-layer compensating control, restrict inbound traffic to each CXF Resource Server to clients known to legitimately need it, reducing the population of holders of a 'wrong audience' token; this does not stop insiders or compromised peer services and should not substitute for the patch.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in maven, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Apache CXF is a widely deployed open-source services framework (SOAP, REST/JAX-RS, WS-*) that includes an OAuth2/JWT subsystem in its RS Security module. The JwtAccessTokenValidator is responsible for verifying inbound bearer JWTs at a Resource Server. RFC 7519 §4.1.3 and RFC 8725 §3.11 require Resource Servers to verify the 'aud' claim so a token minted for service A cannot be presented to service B. Failing to do so realises CWE-289 (Authentication Bypass by Alternate Name / token routing): the recipient trusts the signature and issuer but never confirms that it is the intended audience, collapsing the security boundary between tenants/services that share a common Authorization Server. The CPE strings (cpe:2.3:a:apache:cxf:*) confirm the framework itself is in scope rather than any specific downstream application.
Know when Cxf gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Network-reachable Resource Server, no user interaction, scope changes to a different RS; PR:L because attacker only needs to be a legitimate client of any peer service to mint a usable JWT, not a high-privilege admin.
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
4Description PRE-NVD
Blast Radius
ecosystem impact- 15 maven packages depend on org.apache.cxf:cxf-rt-rs-security-oauth2 (8 direct, 7 indirect)
Ecosystem-wide dependent count for version 4.2.0.
Executive ViewAI
Apache CXF contains a JWT token validation flaw (CVE-2026-50627) that allows attackers with valid credentials from one OAuth2 provider to gain unauthorized access to unrelated services. This breaks trust isolation in federated identity deployments, exposing downstream applications to cross-service authentication bypass without requiring additional credentials.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
A SSRF vulnerability using the Aegis DataBinding in versions of Apache CXF before 4.0.4, 3.6.3 and 3.5.8 allows an attac
The streaming XML parser in Apache CXF 2.5.x before 2.5.10, 2.6.x before 2.6.7, and 2.7.x before 2.7.4 allows remote att
Apache CXF 2.4.x before 2.4.8, 2.5.x before 2.5.4, and 2.6.x before 2.6.1, when a Supporting Token specifies a child WS-
The WS-SP UsernameToken policy in Apache CXF 2.4.5 and 2.5.1 allows remote attackers to bypass authentication by sending
Authentication bypass in Apache CXF's OAuthRequestFilter affects versions prior to 4.1.7 and 4.2.0-4.2.1, where an inver
XML External Entity (XXE) processing in Apache CXF versions prior to 4.1.7 and 4.2.0-4.2.1 allows remote attackers to tr
A SSRF vulnerability in parsing the href attribute of XOP:Include in MTOM requests in versions of Apache CXF before 3.5.
Apache CXF before 3.3.4 and 3.2.11 provides all of the components that are required to build a fully fledged OpenId Conn
All versions of Apache Santuario - XML Security for Java prior to 2.2.3 and 2.1.7 are vulnerable to an issue where the "
A SSRF vulnerability in WADL service description in versions of Apache CXF before 4.0.5, 3.6.4 and 3.5.9 allows an attac
The OAuth2 Hawk and JOSE MAC Validation code in Apache CXF prior to 3.0.13 and 3.1.x prior to 3.1.10 is not using a cons
Apache CXF 2.5.x before 2.5.10, 2.6.x before CXF 2.6.7, and 2.7.x before CXF 2.7.4 does not verify that a specified cryp
EUVD-2026-36395
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB