Critical Cxf CVEs
21 CVEs, 3 protected by Waratek
Overview 21 matches · 3 protected · 0 exploited · 0 CISA KEV · 1 public PoC · 0 EPSS ≥ 0.5
Protected by Waratek
3
14.3%
Rule in development
0
0.0%
Mitigation candidate
1
4.8%
No exploit published
17
81.0%
blocked by ARMR today
3
14.3%
partly blocked
0
0.0%
not blocked
18
85.7%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
1
4.8%
Forecast only
0
0.0%
No public exploit
20
95.2%
split by
peak 13 / year
20101
Protected by Waratek1
Critical1
blocked by ARMR today1
No public exploit1
20110
20120
20130
20140
20150
20161
No exploit published1
Critical1
not blocked1
No public exploit1
20171
No exploit published1
Critical1
not blocked1
No public exploit1
20180
20191
No exploit published1
Critical1
not blocked1
No public exploit1
20200
20210
20221
Mitigation candidate1
Critical1
not blocked1
Proof of concept only1
20230
20242
No exploit published2
Critical2
not blocked2
No public exploit2
20251
No exploit published1
Critical1
not blocked1
No public exploit1
202613
Protected by Waratek2
No exploit published11
Critical13
blocked by ARMR today2
not blocked11
No public exploit13
201020122014201620182020202220242026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-97468 | Critical | 2026-10-09 | No exploit published | No public exploit | Apache CXF's STSTokenValidator and Security Token Service (STS) cached validated security tokens under a non-cryptographic 32-bit hash of the token (Java Arrays.hashCode/hashCode()), and treated a cache hit as proof that the presented token had already been validated. An attacker could craft a token (for example a UsernameToken or a self-signed SAML Assertion) whose hash collides with a cached entry. The token would then be accepted without password validation, signature trust verification or a call to the STS. This could let the attacker authenticate as another user and, through STS token validation or renewal, obtain STS-signed tokens for that identity. Users are recommended to upgrade to versions 4.2.4 or 4.1.9 or 3.6.13, which fix this issue. |
| CVE-2026-71575 | Critical | 2026-10-09 | No exploit published | No public exploit | The max_age authentication-freshness check in OidcClientCodeRequestFilter was inoperative due to a milliseconds/seconds unit mismatch and an inverted comparison polarity. Any relying party using setMaxAgeOffset to enforce re-authentication would silently accept sessions of any age, bypassing step-up authentication policies. Users are recommended to upgrade to versions 4.2.4 or 4.1.9 or 3.6.13, which fix this issue. |
| CVE-2026-107938 | Critical | 2026-10-09 | No exploit published | No public exploit | In Apache CXF, the Netty-based HTTP client transport (cxf-rt-transports-http-netty-client) did not verify that the hostname in the server’s TLS certificate matched the host being called. This applied over both HTTP/1.1 and HTTP/2, even when disableCNCheck was left at its default value of false. The certificate chain was validated against the configured trust store, but the endpoint’s identity was not. A network attacker able to intercept traffic could present any certificate trusted by the client, such as a publicly issued certificate for a domain they control, and impersonate the target service. They could then read or modify the exchanged messages, including credentials. Users are recommended to upgrade to versions 4.2.4 or 4.1.9 or 3.6.13, which fix this issue. |
| CVE-2026-68079 | Critical | 2026-08-06 | No exploit published | No public exploit | In Apache CXF's DefaultEncryptingCodeDataProvider, a captured authorization code can be redeemed an unlimited number of times due to a flaw in the implementation of the removeCodeGrant functionality. This violates the RFC requirement that "The authorization code MUST NOT be used more than once." Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue. |
| CVE-2026-66909 | Critical | 2026-08-06 | Protected by Waratek | No public exploit | Apache CXF's JMS transport deserializes the body of any inbound JMS ObjectMessage using native Java deserialization, with no type restrictions in place. Any attacker able to place a message on the service's JMS destination can submit a malicious serialized object, leading to denial of service or, if a suitable gadget class is on the classpath, remote code execution. The fix disables ObjectMessage deserialization by default, with a configuration switch to re-enable it if needed. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue. |
| CVE-2026-65583 | Critical | 2026-08-06 | No exploit published | No public exploit | Apache CXF’s OIDC relying-party token validation could accept self-issued ID tokens without enforcing required claim checks (issuer/subject/audience/time and sub_jwk binding), enabling authentication bypass with crafted tokens. However, note that self-issued ID tokens are not accepted by default in the validator. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fixes this issue. |
| CVE-2026-63687 | Critical | 2026-08-06 | No exploit published | No public exploit | Apache CXF's JwtRequestCodeFilter copies all claims from a signed request JWT into the authorization parameter map without excluding security-sensitive parameters. A client that can produce a validly-signed request JWT (e.g., one whose client_secret is known or compromised) can thereby substitute the code_challenge, code_challenge_method, nonce, and state values that were set in the outer HTTP request, undermining PKCE integrity and OpenID Connect replay protection. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue. |
| CVE-2026-61466 | Critical | 2026-08-06 | No exploit published | No public exploit | In Apache CXF's OAuth2 Dynamic Client Registration endpoint, the authorization server accepts and stores the `scope` value supplied in the client registration request verbatim, without validating it against an AS-defined allowlist. This could lead to a client self-assigning privileged scopes at registration time. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue. |
| CVE-2026-50628 | Critical | 2026-06-12 | No exploit published | No public exploit | A logic error in OAuthRequestFilter rejects legitimate requests originating from the bound IP address, while blindly allowing requests from any other IP address. Enabling this security feature inadvertently creates an inverse security check. Users are recommended to upgrade to versions 4.2.2 or 4.1.7 or 3.6.12, which fixes this issue. |
| CVE-2026-50627 | Critical | 2026-06-12 | No exploit published | No public exploit | The JwtAccessTokenValidator class in Apache CXF fails to validate the 'aud' (Audience) claims of incoming JWT access tokens. This allows a JWT issued for one Resource Server to be successfully replayed against a completely different Resource Server, leading to Token Confusion/Routing attacks. Users are recommended to upgrade to versions 4.2.2 or 4.1.7 or 3.6.12, which fixes this issue. |
| CVE-2026-49875 | Critical | 2026-06-12 | Protected by Waratek | No public exploit | Apache CXF's EndpointReferenceUtils and W3CMultiSchemaFactory classes construct a SAXParserFactory without the necessary JAXP hardening configurations, enabling out-of-band (OOB) external entity resolution. Users are recommended to upgrade to versions 4.2.2 or 4.1.7 or 3.6.12, which fix this issue. |
| CVE-2026-44930 | Critical | 2026-05-22 | No exploit published | No public exploit | An LDAP injection vulnerability in the LDAP Certificate repository of the XKMS server in Apache CXF may allow an attacker to retrieve arbitrary certificates from the repository. Users are recommended to upgrade to versions 4.2.1, 4.1.6 or 3.6.11, which fix this issue. |
| CVE-2026-47323 | Critical | 2026-05-19 | No exploit published | No public exploit | Camel-CXF and Camel-Knative Message Header Injection via Missing Inbound Filtering The CXF and Knative HeaderFilterStrategy implementations (CxfRsHeaderFilterStrategy in camel-cxf-rest, CxfHeaderFilterStrategy in camel-cxf-transport, and KnativeHttpHeaderFilterStrategy in camel-knative-http) only filter outbound Camel-internal headers via setOutFilterStartsWith, while not configuring inbound filtering via setInFilterStartsWith. As a result, an unauthenticated attacker can inject Camel-internal headers (e.g. CamelExecCommandExecutable, CamelFileName) via HTTP requests to CXF-RS or CXF-SOAP endpoints. When a route forwards messages from these endpoints to header-driven components such as camel-exec or camel-file, the injected headers override configured values, enabling remote code execution or arbitrary file writes. This is the same pattern that was previously addressed in camel-undertow (CVE-2025-30177), the broader incoming-header filter (CVE-2025-27636 and CVE-2025-29891), and non-HTTP strategies (CVE-2026-40453). This issue affects Apache Camel: from 3.18.0 before 4.14.6, from 4.15.0 before 4.18.2. Users are recommended to upgrade to version 4.19.0, which fixes the issue. If users are on the 4.18.x LTS releases stream, then they are suggested to upgrade to 4.18.2. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.6. |
| CVE-2025-48913 | Critical | 2025-08-08 | No exploit published | No public exploit | If untrusted users are allowed to configure JMS for Apache CXF, previously they could use RMI or LDAP URLs, potentially leading to code execution capabilities. This interface is now restricted to reject those protocols, removing this possibility. Users are recommended to upgrade to versions 3.6.8, 4.0.9 or 4.1.3, which fix this issue. |
| CVE-2024-29736 | Critical | 2024-07-19 | No exploit published | No public exploit | 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 attacker to perform SSRF style attacks on REST webservices. The attack only applies if a custom stylesheet parameter is configured. |
| CVE-2024-28752 | Critical | 2024-03-15 | No exploit published | No public exploit | 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 attacker to perform SSRF style attacks on webservices that take at least one parameter of any type. Users of other data bindings (including the default databinding) are not impacted. |
| CVE-2022-46364 | Critical | 2022-12-13 | Mitigation candidate | Proof of concept only | A SSRF vulnerability in parsing the href attribute of XOP:Include in MTOM requests in versions of Apache CXF before 3.5.5 and 3.4.10 allows an attacker to perform SSRF style attacks on webservices that take at least one parameter of any type. |
| CVE-2019-12419 | Critical | 2019-11-06 | No exploit published | No public exploit | Apache CXF before 3.3.4 and 3.2.11 provides all of the components that are required to build a fully fledged OpenId Connect service. There is a vulnerability in the access token services, where it does not validate that the authenticated principal is equal to that of the supplied clientId parameter in the request. If a malicious client was able to somehow steal an authorization code issued to another client, then they could exploit this vulnerability to obtain an access token for the other client. |
| CVE-2012-0803 | Critical | 2017-08-08 | No exploit published | No public exploit | The WS-SP UsernameToken policy in Apache CXF 2.4.5 and 2.5.1 allows remote attackers to bypass authentication by sending an empty UsernameToken as part of a SOAP request. |
| CVE-2016-4464 | Critical | 2016-09-21 | No exploit published | No public exploit | The application plugins in Apache CXF Fediz 1.2.x before 1.2.3 and 1.3.x before 1.3.1 do not match SAML AudienceRestriction values against configured audience URIs, which might allow remote attackers to have bypass intended restrictions and have unspecified other impact via a crafted SAML token with a trusted signature. |
| CVE-2010-2076 | Critical | 2010-08-19 | Protected by Waratek | No public exploit | Apache CXF 2.0.x before 2.0.13, 2.1.x before 2.1.10, and 2.2.x before 2.2.9, as used in Apache ServiceMix, Apache Camel, Apache Chemistry, Apache jUDDI, Apache Geronimo, and other products, does not properly reject DTDs in SOAP messages, which allows remote attackers to read arbitrary files, send HTTP requests to intranet servers, or cause a denial of service (CPU and memory consumption) via a crafted DTD, as demonstrated by an entity declaration in a request to samples/wsdl_first_pure_xml, a similar issue to CVE-2010-1632. |