What is the CVSS score of CVE-2026-50627?

CVE-2026-50627 has a CVSS 3.1 base score of 9.1 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H. EPSS exploitation probability: 0.0%.

Which versions of Apache CXF are affected by CVE-2026-50627?

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.. A patch is available.

How to fix or mitigate CVE-2026-50627?

Within 24 hours: identify all Apache CXF deployments and versions (vulnerable: all prior to 4.1.7 and versions 4.2.0-4.2.1). Within 7 days: apply available vendor patch to upgrade to CXF 4.1.7 or later. Within 30 days: verify patching across all systems and establish automated version tracking.

Apache CXF CVE-2026-50627

EUVD-2026-36395 CRITICAL

Authentication Bypass by Alternate Name (CWE-289)

2026-06-11

GHSA-9mrv-8pvf-hf4m

Apache Information Disclosure Cxf

9.1

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

9.1 CRITICAL

AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

vuln.today AI

9.9 CRITICAL

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.

3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Red Hat

8.1 HIGH

qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

Attack Vector

Network

Attack Complexity

Low

Privileges Required

High

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Updated

Jun 15, 2026 - 18:31 vuln.today

v3 (cvss_changed)

Analysis Updated

Jun 15, 2026 - 18:31 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Jun 15, 2026 - 18:22 vuln.today

cvss_changed

CVSS changed

Jun 15, 2026 - 18:22 NVD

9.1 (CRITICAL)

Patch available

Jun 12, 2026 - 11:01 EUVD

Analysis Generated

Jun 11, 2026 - 18:23 vuln.today

Description PRE-NVD

Disclosed via oss-security. NVD scoring and full description are pending.

AnalysisAI

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.

Technical ContextAI

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.

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.