Apache Cxf
Monthly
Apache CXF versions prior to 4.2.4, 4.1.9, and 3.6.13 allow remote, unauthenticated attackers to cause a denial of service by submitting a very large XML document that exhausts memory and CPU during parsing. The flaw lies in StaxUtils, which by default imposes no limit on the total number of elements or characters, and is most impactful when CXF builds a DOM from the input, such as in SAAJ or WS-Security processing. No public exploit code has been identified, and deployments that enforce a request size limit are largely protected.
Man-in-the-middle attackers can impersonate any TLS server contacted by Apache CXF's optional Netty-based HTTP client transport, because cxf-rt-transports-http-netty-client validates the server certificate chain against the configured trust store but never checks that the certificate's hostname matches the host actually being called - a gap present over both HTTP/1.1 and HTTP/2 and present even with disableCNCheck left at its secure default of false. Applications running Apache CXF before 3.6.13, 4.1.9 or 4.2.4 that use this transport for outbound TLS calls are affected; an unauthenticated attacker who already holds a traffic-interception position and any certificate issued by a CA in the client's trust store (for example, a free publicly issued certificate for an attacker-controlled domain) can read or modify exchanged messages and credentials. No public exploit identified at time of analysis, and exploitation is gated by the requirement for an on-path MITM position plus a trusted-chain certificate, which is reflected in our assessed vector returning High attack complexity rather than the published AC:L; EPSS is correspondingly low at 0.11% (1st percentile), so this is a serious TLS trust failure rather than an immediate mass-exploitation priority. Vendor fixes are available in 3.6.13, 4.1.9 and 4.2.4.
Unbounded memory allocation in Apache CXF's multipart/MTOM attachment part-header parser lets a remote, unauthenticated attacker exhaust server memory and cause a denial of service by sending a single crafted multipart request. The parser applies attachment-max-header-size (default 300 characters) only per physical line and enforces attachment-headers-max-count (default 500) against distinct header names rather than total header lines, so folded continuation lines or a repeated header name slip past both limits and inflate the parsed value without bound. Affected are CXF 4.2.0 through 4.2.3, 4.0.0 through 4.1.8, and all releases before 3.6.13 that expose a multipart/MTOM-accepting endpoint; fixed releases are 4.2.4, 4.1.9 and 3.6.13. Exploitation requires no authentication (CVSS PR:N/UI:N) and no non-default configuration, but it is limited to availability impact only; EPSS is low at 0.24% (14th percentile) and no public exploit code or confirmed active exploitation was identified at time of analysis.
XML signature wrapping in Apache CXF's JAX-RS XML Security module allows remote, unauthenticated attackers to have unsigned content accepted as if it were covered by a trusted XML signature. Only deployments that consume inbound XML through CXF's XML Signature interceptors (XmlSigInHandler, XmlSigInInterceptor, or the streaming XmlSecInInterceptor) are exposed, and the attacker must first hold any XML document signed by a key the target trusts; that signed document can then be wrapped in forged content and repeatedly presented. Fixed versions 4.2.4, 4.1.9, and 3.6.13 address the issue; no public exploit code has been identified and EPSS is low (0.17%, 6th percentile), though integrity impact is rated High (CVSS 7.5).
Trust bypass in Apache CXF's STSTokenValidator allows a remote, unauthenticated attacker to have a forged SAML assertion signed with an untrusted certificate accepted as trusted without the assertion ever being validated by the Security Token Service. Only deployments that use STSTokenValidator to validate SAML tokens while leaving alwaysValidateToSts unset are affected, and exploitation additionally requires a race window in which the result of a concurrent legitimate request's successful trust check is read from shared state. No public exploit code or CISA KEV listing has been identified at time of analysis, EPSS is 0.17% (6th percentile), and vendor fixes are available in Apache CXF 4.2.4, 4.1.9 and 3.6.13.
Token validation bypass in Apache CXF's STSTokenValidator and Security Token Service (STS) allows unauthenticated remote attackers to impersonate another user by presenting a forged UsernameToken or self-signed SAML Assertion whose 32-bit Java hash collides with an entry already held in the validated-token cache. Because a cache hit is treated as proof of prior validation, the forged token is accepted without password validation, signature trust verification, or any call to the STS, and can subsequently be exchanged through STS validation or renewal for STS-signed tokens issued for the victim identity. Exploitation is constrained in practice: the target deployment must use STSTokenValidator or STS token validation/renewal with the validated-token cache enabled, and a legitimately validated token for the identity being impersonated must already be present in that cache; no public exploit code has been identified at time of analysis, KEV status is negative, and EPSS is low (~0.17%, 6th percentile), yet the headline CVSS of 9.1 reflects high confidentiality and integrity impact if the preconditions are met. Vendor patches are available in 4.2.4, 4.1.9, and 3.6.13.
CPU exhaustion denial of service in Apache CXF's FIQL query parser allows remote attackers to degrade or stall a server by submitting a long search expression containing no recognizable operator, which drives the parser's operator-search logic into excessive combinatorial matching and burns CPU on a request-handling thread. Affected are CXF 3.6.x, 4.1.x and 4.2.x deployments that expose FIQL-based search/filter endpoints; the assessed CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (base 7.5), meaning availability impact only, with confidentiality and integrity unaffected. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor-released fixes - 4.2.4, 4.1.9 and 3.6.13 - neutralize the long-input vector by capping FIQL expressions at 4 KiB by default while still permitting normal queries.
A remote, unauthenticated attacker can exhaust server heap memory in Apache CXF by submitting a small (kilobyte-scale) DEFLATE payload that inflates to gigabytes when the framework decompresses it without any output-size cap. The flaw is reachable through two deployment-specific paths: JWE decryption when the 'zip=DEF' compression header is present (for example a JoseSessionTokenProvider configured with RSA-OAEP key wrap), and SAML token inflation over the HTTP redirect or POST binding - in both cases decompression occurs before or independently of any trust, signature, or key validation, so no credentials or valid keys are needed. Impact is availability only (assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5), with confirmed exploitation limited to reachable configurations; EPSS is 0.16% (4th percentile), no CISA KEV listing, and no public exploit identified at time of analysis. Vendor-released patches are available in 4.2.4, 4.1.9, and 3.6.13, which introduce a configurable 10 MiB inflation cap.
Concurrent token-exchange requests against Apache CXF's JPA-backed OAuth2 authorization code grant provider can redeem a single authorization code more than once, yielding multiple valid access tokens from one code. Only deployments running the JPA authorization code provider that persists codes to a shared relational database under READ_COMMITTED isolation and that expose the token endpoint to remote callers are affected; versions below 3.6.13, 4.0.0 through 4.1.8, and 4.2.0 through 4.2.3 are in scope. Exploitation is unauthenticated per the CVSS vector (PR:N) but carries a high attack-complexity rating because the attacker must already hold one unredeemed code and win a timing race, so success is probabilistic; EPSS is low at 0.22% (11th percentile) and no public exploit identified at time of analysis, making this a real-but-conditional risk rather than a mass-exploitation emergency.
Authentication bypass in Apache CXF's OidcClientCodeRequestFilter renders the max_age authentication-freshness check inoperative, allowing stale OIDC sessions to be accepted regardless of age when a relying party has configured setMaxAgeOffset to enforce step-up re-authentication. The defect stems from a milliseconds/seconds unit mismatch and inverted comparison polarity, silently defeating session-age validation; affected releases are Apache CXF 4.2.0 before 4.2.4, 4.0.0 before 4.1.9, and 3.6.x before 3.6.13. Vendor patches are available, no public exploit identified at time of analysis, and EPSS is low (0.23%), though exploitation requires the non-default setMaxAgeOffset setting, limiting real-world impact to deployments that opt into max_age policies.
Double-spending of OAuth2 authorization codes in Apache CXF's JCacheCodeDataProvider enables issuance of multiple valid access tokens from a single code. Concurrent requests to the token endpoint during the brief window between code validation and invalidation exploit the TOCTOU race condition (CWE-367), allowing an attacker in possession of a valid authorization code to obtain additional access tokens beyond the one they are entitled to. No public exploit has been identified at time of analysis, and fixed versions are available across all maintained branches.
Authorization scope escalation in Apache CXF's OAuth2 Dynamic Client Registration endpoint allows any registering client to self-assign privileged scopes by supplying arbitrary `scope` values in the registration request, which the authorization server stores verbatim without validating against a server-defined allowlist. Affected versions span the 3.x, 4.1.x, and 4.2.x release lines; patched releases 3.6.12, 4.1.8, and 4.2.3 are available per the Apache advisory. No public exploit or active exploitation has been identified at time of analysis, but the straightforward exploitation path - crafting a single registration request - makes this a meaningful authorization bypass risk for any deployment exposing CXF's OAuth2 AS with Dynamic Client Registration enabled.
Apache CXF's JwtRequestCodeFilter blindly copies all claims from a validly-signed JWT request object into the OAuth2 authorization parameter map, including security-sensitive fields that must not be client-controlled: code_challenge, code_challenge_method, nonce, and state. Affected are all Apache CXF deployments using this filter for OAuth2/OIDC authorization code flows prior to versions 4.2.3, 4.1.8, and 3.6.12. An OAuth2 client with a known or compromised client_secret can craft a signed request JWT that overrides the PKCE parameters established in the outer HTTP request, effectively nullifying PKCE authorization code binding and OIDC replay protection. No public exploit code or CISA KEV listing has been identified at time of analysis.
Authentication bypass in Apache CXF's OIDC relying-party implementation allows network-accessible attackers to forge self-issued ID tokens that skip all required OpenID Connect claim checks - issuer, subject, audience, time bounds, and sub_jwk binding - effectively impersonating any user identity. Affected are all Apache CXF versions prior to 4.2.3, 4.1.8, and 3.6.12 when the relying party is explicitly configured to accept self-issued OIDC tokens, a non-default setting. No public exploit or CISA KEV listing has been identified at time of analysis, but the attack surface is constrained to a narrow set of deliberately misconfigured deployments.
Apache CXF's DefaultEncryptingCodeDataProvider allows captured OAuth 2.0 authorization codes to be redeemed an unlimited number of times, violating RFC 6749's single-use requirement. The removeCodeGrant() method that should invalidate a code after first exchange fails to do so, meaning any attacker who intercepts or obtains a legitimate authorization code can replay it repeatedly to obtain additional access tokens. No public exploit has been identified at time of analysis, and the issue is addressed in patched releases 4.2.3, 4.1.8, and 3.6.12.
Token revocation bypass in Apache CXF's DefaultEncryptingOAuthDataProvider allows revoked OAuth access and refresh tokens to remain functionally valid indefinitely - the provider continues to decrypt them successfully and TokenIntrospectionService returns active:true in direct violation of RFC 7009 and RFC 7662 mandates. All Apache CXF deployments using this built-in OAuth data provider and relying on token revocation as a security control are affected across the 3.6.x, 4.1.x, and 4.2.x branches. An attacker or suspended user who retains a revoked token can continue accessing protected resources as though revocation never occurred, bypassing intended authorization boundaries. No public exploit has been identified at time of analysis, though the attack requires no tooling beyond a standard HTTP client.
XML External Entity injection in Apache CXF's WSDL import processing allows attackers who can influence imported WSDL or XSD documents to bypass XXE protections applied to the top-level WSDL. CXF correctly hardens top-level WSDL parsing via StaxUtils, but delegates all <wsdl:import> and <xsd:import> resolution to WSDL4J, which lacks equivalent DOCTYPE and external entity restrictions - creating a security boundary mismatch that nullifies the top-level protections. No public exploit has been identified at time of analysis, but CWE-611 is a well-understood attack class with established tooling; successful exploitation against vulnerable deployments can yield arbitrary server-side file reads and SSRF. Vendor-released patches are available across three active release branches.
Authorization Code Substitution in Apache CXF's OpenID Connect Relying Party implementation allows remote attackers to hijack authenticated sessions when CXF is deployed in Hybrid Flow mode with a non-compliant or misconfigured Identity Provider that omits the c_hash parameter. Successful exploitation yields full authenticated access equivalent to account takeover, with high confidentiality and integrity impact. No public exploit has been identified at time of analysis, but SSVC classifies the attack as automatable with total technical impact once the prerequisite IdP condition is present.
Unsafe deserialization in Apache CXF's JMS transport allows any party able to publish to the service's JMS destination to achieve denial of service or, where a compatible deserialization gadget chain is present on the application classpath, remote code execution within the CXF process. All Apache CXF versions prior to 4.2.3, 4.1.8, and 3.6.12 are affected when the JMS transport is in use. No public exploit code or CISA KEV listing has been identified at time of analysis, though the vulnerability class (CWE-502 with unrestricted ObjectInputStream) is well-understood and tooling such as ysoserial makes it routinely exploitable wherever gadget libraries are present.
Denial of service persists in Apache CXF due to an incomplete remediation of CVE-2026-50645, allowing unauthenticated network attackers to exhaust server resources by submitting messages containing an excessive number of MIME attachment headers. All Apache CXF deployments running versions prior to 4.2.3, 4.1.8, or 3.6.12 remain vulnerable despite having applied the prior patch. No public exploit code or active exploitation has been identified at time of analysis, but the bypass-of-fix nature of this vulnerability means any organization that patched CVE-2026-50645 and considered itself remediated must re-patch.
Uncontrolled resource consumption in Apache CXF's JAX-RS form parameter processing enables remote denial-of-service attacks against any exposed endpoint accepting form-encoded requests. The framework provides a 'maxFormParameterCount' configuration knob but sets no default ceiling, meaning unpatched deployments will parse arbitrarily large parameter sets until memory or CPU is exhausted. Fixed versions (4.2.3, 4.1.8, and 3.6.12) enforce a default cap of 500 parameters; no public exploit or CISA KEV listing has been identified at time of analysis.
Unbounded attachment ingestion in Apache CXF enables remote denial-of-service against any endpoint that processes multipart messages. Versions prior to 4.2.3, 4.1.8, and 3.6.12 imposed no default ceiling on the 'attachment-max-size' parameter, allowing attackers to exhaust server memory or processing capacity by submitting arbitrarily large attachments. No public exploit has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog, but the low attack complexity makes this a realistic threat for internet-exposed CXF deployments.
Remote code execution in Apache CXF (versions before 3.6.11, 4.0.0-4.1.5, and 4.2.0) arises because the fix for CVE-2025-48913 was incomplete, leaving a second code path through which untrusted JMS configuration can be abused to execute code. The flaw only matters where untrusted users are permitted to supply or influence JMS transport configuration for CXF endpoints. This is a remediation-regression issue carrying no public exploit identified at time of analysis, a very low EPSS (0.10%), and SSVC exploitation status of 'none', but the technical impact is rated total.
Arbitrary certificate disclosure in Apache CXF's XKMS server lets remote attackers abuse an LDAP injection flaw (CWE-90) in the LDAP-backed certificate repository to retrieve certificates they are not authorized to see. Affected builds span Apache CXF 3.x before 3.6.11, 4.0.0-4.1.x before 4.1.6, and 4.2.0 before 4.2.1; the issue was reported by Apache itself and fixed in those releases. No public exploit identified at time of analysis, EPSS is very low (0.02%, 4th percentile), and CISA SSVC scores exploitation as 'none' with only 'partial' technical impact.
Open redirect in Apache CXF's OIDC relying-party component lets remote, unauthenticated attackers steer users to an attacker-controlled site by planting external URLs inside OIDC state parameters that the RP preserves and later reuses as a post-authentication redirect target. Only deployments that actually enable the OIDC relying-party code path are exposed, and a victim must be lured into initiating and completing an authentication flow through an attacker-supplied link, so exploitation is not fully automatic. Both directly encoded and double-encoded external URLs can slip past origin validation depending on which validation path runs; there is no public exploit identified at time of analysis, vendor-released fixes are available in 4.2.4, 4.1.9, and 3.6.13, and the assessed CVSS:3.1 vector AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N reflects a low-severity redirect impact gated by mandatory user interaction.
XML External Entity injection in Apache CXF's WS-Transfer module exposes SOAP endpoints to server-side file read and internal network probing by unauthenticated remote attackers. The insecure XML parser configuration (CWE-611) affects all 3.x releases before 3.6.11, 4.0.x-4.1.x before 4.1.6, and 4.2.0 before 4.2.1. No public exploit has been identified at time of analysis, EPSS sits at the 8th percentile (0.03%), and CISA SSVC rates exploitation as 'none', placing this squarely in the patch-on-schedule rather than emergency-response category despite the broad network attack vector.
Apache CXF versions prior to 4.2.4, 4.1.9, and 3.6.13 allow remote, unauthenticated attackers to cause a denial of service by submitting a very large XML document that exhausts memory and CPU during parsing. The flaw lies in StaxUtils, which by default imposes no limit on the total number of elements or characters, and is most impactful when CXF builds a DOM from the input, such as in SAAJ or WS-Security processing. No public exploit code has been identified, and deployments that enforce a request size limit are largely protected.
Man-in-the-middle attackers can impersonate any TLS server contacted by Apache CXF's optional Netty-based HTTP client transport, because cxf-rt-transports-http-netty-client validates the server certificate chain against the configured trust store but never checks that the certificate's hostname matches the host actually being called - a gap present over both HTTP/1.1 and HTTP/2 and present even with disableCNCheck left at its secure default of false. Applications running Apache CXF before 3.6.13, 4.1.9 or 4.2.4 that use this transport for outbound TLS calls are affected; an unauthenticated attacker who already holds a traffic-interception position and any certificate issued by a CA in the client's trust store (for example, a free publicly issued certificate for an attacker-controlled domain) can read or modify exchanged messages and credentials. No public exploit identified at time of analysis, and exploitation is gated by the requirement for an on-path MITM position plus a trusted-chain certificate, which is reflected in our assessed vector returning High attack complexity rather than the published AC:L; EPSS is correspondingly low at 0.11% (1st percentile), so this is a serious TLS trust failure rather than an immediate mass-exploitation priority. Vendor fixes are available in 3.6.13, 4.1.9 and 4.2.4.
Unbounded memory allocation in Apache CXF's multipart/MTOM attachment part-header parser lets a remote, unauthenticated attacker exhaust server memory and cause a denial of service by sending a single crafted multipart request. The parser applies attachment-max-header-size (default 300 characters) only per physical line and enforces attachment-headers-max-count (default 500) against distinct header names rather than total header lines, so folded continuation lines or a repeated header name slip past both limits and inflate the parsed value without bound. Affected are CXF 4.2.0 through 4.2.3, 4.0.0 through 4.1.8, and all releases before 3.6.13 that expose a multipart/MTOM-accepting endpoint; fixed releases are 4.2.4, 4.1.9 and 3.6.13. Exploitation requires no authentication (CVSS PR:N/UI:N) and no non-default configuration, but it is limited to availability impact only; EPSS is low at 0.24% (14th percentile) and no public exploit code or confirmed active exploitation was identified at time of analysis.
XML signature wrapping in Apache CXF's JAX-RS XML Security module allows remote, unauthenticated attackers to have unsigned content accepted as if it were covered by a trusted XML signature. Only deployments that consume inbound XML through CXF's XML Signature interceptors (XmlSigInHandler, XmlSigInInterceptor, or the streaming XmlSecInInterceptor) are exposed, and the attacker must first hold any XML document signed by a key the target trusts; that signed document can then be wrapped in forged content and repeatedly presented. Fixed versions 4.2.4, 4.1.9, and 3.6.13 address the issue; no public exploit code has been identified and EPSS is low (0.17%, 6th percentile), though integrity impact is rated High (CVSS 7.5).
Trust bypass in Apache CXF's STSTokenValidator allows a remote, unauthenticated attacker to have a forged SAML assertion signed with an untrusted certificate accepted as trusted without the assertion ever being validated by the Security Token Service. Only deployments that use STSTokenValidator to validate SAML tokens while leaving alwaysValidateToSts unset are affected, and exploitation additionally requires a race window in which the result of a concurrent legitimate request's successful trust check is read from shared state. No public exploit code or CISA KEV listing has been identified at time of analysis, EPSS is 0.17% (6th percentile), and vendor fixes are available in Apache CXF 4.2.4, 4.1.9 and 3.6.13.
Token validation bypass in Apache CXF's STSTokenValidator and Security Token Service (STS) allows unauthenticated remote attackers to impersonate another user by presenting a forged UsernameToken or self-signed SAML Assertion whose 32-bit Java hash collides with an entry already held in the validated-token cache. Because a cache hit is treated as proof of prior validation, the forged token is accepted without password validation, signature trust verification, or any call to the STS, and can subsequently be exchanged through STS validation or renewal for STS-signed tokens issued for the victim identity. Exploitation is constrained in practice: the target deployment must use STSTokenValidator or STS token validation/renewal with the validated-token cache enabled, and a legitimately validated token for the identity being impersonated must already be present in that cache; no public exploit code has been identified at time of analysis, KEV status is negative, and EPSS is low (~0.17%, 6th percentile), yet the headline CVSS of 9.1 reflects high confidentiality and integrity impact if the preconditions are met. Vendor patches are available in 4.2.4, 4.1.9, and 3.6.13.
CPU exhaustion denial of service in Apache CXF's FIQL query parser allows remote attackers to degrade or stall a server by submitting a long search expression containing no recognizable operator, which drives the parser's operator-search logic into excessive combinatorial matching and burns CPU on a request-handling thread. Affected are CXF 3.6.x, 4.1.x and 4.2.x deployments that expose FIQL-based search/filter endpoints; the assessed CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (base 7.5), meaning availability impact only, with confidentiality and integrity unaffected. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor-released fixes - 4.2.4, 4.1.9 and 3.6.13 - neutralize the long-input vector by capping FIQL expressions at 4 KiB by default while still permitting normal queries.
A remote, unauthenticated attacker can exhaust server heap memory in Apache CXF by submitting a small (kilobyte-scale) DEFLATE payload that inflates to gigabytes when the framework decompresses it without any output-size cap. The flaw is reachable through two deployment-specific paths: JWE decryption when the 'zip=DEF' compression header is present (for example a JoseSessionTokenProvider configured with RSA-OAEP key wrap), and SAML token inflation over the HTTP redirect or POST binding - in both cases decompression occurs before or independently of any trust, signature, or key validation, so no credentials or valid keys are needed. Impact is availability only (assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5), with confirmed exploitation limited to reachable configurations; EPSS is 0.16% (4th percentile), no CISA KEV listing, and no public exploit identified at time of analysis. Vendor-released patches are available in 4.2.4, 4.1.9, and 3.6.13, which introduce a configurable 10 MiB inflation cap.
Concurrent token-exchange requests against Apache CXF's JPA-backed OAuth2 authorization code grant provider can redeem a single authorization code more than once, yielding multiple valid access tokens from one code. Only deployments running the JPA authorization code provider that persists codes to a shared relational database under READ_COMMITTED isolation and that expose the token endpoint to remote callers are affected; versions below 3.6.13, 4.0.0 through 4.1.8, and 4.2.0 through 4.2.3 are in scope. Exploitation is unauthenticated per the CVSS vector (PR:N) but carries a high attack-complexity rating because the attacker must already hold one unredeemed code and win a timing race, so success is probabilistic; EPSS is low at 0.22% (11th percentile) and no public exploit identified at time of analysis, making this a real-but-conditional risk rather than a mass-exploitation emergency.
Authentication bypass in Apache CXF's OidcClientCodeRequestFilter renders the max_age authentication-freshness check inoperative, allowing stale OIDC sessions to be accepted regardless of age when a relying party has configured setMaxAgeOffset to enforce step-up re-authentication. The defect stems from a milliseconds/seconds unit mismatch and inverted comparison polarity, silently defeating session-age validation; affected releases are Apache CXF 4.2.0 before 4.2.4, 4.0.0 before 4.1.9, and 3.6.x before 3.6.13. Vendor patches are available, no public exploit identified at time of analysis, and EPSS is low (0.23%), though exploitation requires the non-default setMaxAgeOffset setting, limiting real-world impact to deployments that opt into max_age policies.
Double-spending of OAuth2 authorization codes in Apache CXF's JCacheCodeDataProvider enables issuance of multiple valid access tokens from a single code. Concurrent requests to the token endpoint during the brief window between code validation and invalidation exploit the TOCTOU race condition (CWE-367), allowing an attacker in possession of a valid authorization code to obtain additional access tokens beyond the one they are entitled to. No public exploit has been identified at time of analysis, and fixed versions are available across all maintained branches.
Authorization scope escalation in Apache CXF's OAuth2 Dynamic Client Registration endpoint allows any registering client to self-assign privileged scopes by supplying arbitrary `scope` values in the registration request, which the authorization server stores verbatim without validating against a server-defined allowlist. Affected versions span the 3.x, 4.1.x, and 4.2.x release lines; patched releases 3.6.12, 4.1.8, and 4.2.3 are available per the Apache advisory. No public exploit or active exploitation has been identified at time of analysis, but the straightforward exploitation path - crafting a single registration request - makes this a meaningful authorization bypass risk for any deployment exposing CXF's OAuth2 AS with Dynamic Client Registration enabled.
Apache CXF's JwtRequestCodeFilter blindly copies all claims from a validly-signed JWT request object into the OAuth2 authorization parameter map, including security-sensitive fields that must not be client-controlled: code_challenge, code_challenge_method, nonce, and state. Affected are all Apache CXF deployments using this filter for OAuth2/OIDC authorization code flows prior to versions 4.2.3, 4.1.8, and 3.6.12. An OAuth2 client with a known or compromised client_secret can craft a signed request JWT that overrides the PKCE parameters established in the outer HTTP request, effectively nullifying PKCE authorization code binding and OIDC replay protection. No public exploit code or CISA KEV listing has been identified at time of analysis.
Authentication bypass in Apache CXF's OIDC relying-party implementation allows network-accessible attackers to forge self-issued ID tokens that skip all required OpenID Connect claim checks - issuer, subject, audience, time bounds, and sub_jwk binding - effectively impersonating any user identity. Affected are all Apache CXF versions prior to 4.2.3, 4.1.8, and 3.6.12 when the relying party is explicitly configured to accept self-issued OIDC tokens, a non-default setting. No public exploit or CISA KEV listing has been identified at time of analysis, but the attack surface is constrained to a narrow set of deliberately misconfigured deployments.
Apache CXF's DefaultEncryptingCodeDataProvider allows captured OAuth 2.0 authorization codes to be redeemed an unlimited number of times, violating RFC 6749's single-use requirement. The removeCodeGrant() method that should invalidate a code after first exchange fails to do so, meaning any attacker who intercepts or obtains a legitimate authorization code can replay it repeatedly to obtain additional access tokens. No public exploit has been identified at time of analysis, and the issue is addressed in patched releases 4.2.3, 4.1.8, and 3.6.12.
Token revocation bypass in Apache CXF's DefaultEncryptingOAuthDataProvider allows revoked OAuth access and refresh tokens to remain functionally valid indefinitely - the provider continues to decrypt them successfully and TokenIntrospectionService returns active:true in direct violation of RFC 7009 and RFC 7662 mandates. All Apache CXF deployments using this built-in OAuth data provider and relying on token revocation as a security control are affected across the 3.6.x, 4.1.x, and 4.2.x branches. An attacker or suspended user who retains a revoked token can continue accessing protected resources as though revocation never occurred, bypassing intended authorization boundaries. No public exploit has been identified at time of analysis, though the attack requires no tooling beyond a standard HTTP client.
XML External Entity injection in Apache CXF's WSDL import processing allows attackers who can influence imported WSDL or XSD documents to bypass XXE protections applied to the top-level WSDL. CXF correctly hardens top-level WSDL parsing via StaxUtils, but delegates all <wsdl:import> and <xsd:import> resolution to WSDL4J, which lacks equivalent DOCTYPE and external entity restrictions - creating a security boundary mismatch that nullifies the top-level protections. No public exploit has been identified at time of analysis, but CWE-611 is a well-understood attack class with established tooling; successful exploitation against vulnerable deployments can yield arbitrary server-side file reads and SSRF. Vendor-released patches are available across three active release branches.
Authorization Code Substitution in Apache CXF's OpenID Connect Relying Party implementation allows remote attackers to hijack authenticated sessions when CXF is deployed in Hybrid Flow mode with a non-compliant or misconfigured Identity Provider that omits the c_hash parameter. Successful exploitation yields full authenticated access equivalent to account takeover, with high confidentiality and integrity impact. No public exploit has been identified at time of analysis, but SSVC classifies the attack as automatable with total technical impact once the prerequisite IdP condition is present.
Unsafe deserialization in Apache CXF's JMS transport allows any party able to publish to the service's JMS destination to achieve denial of service or, where a compatible deserialization gadget chain is present on the application classpath, remote code execution within the CXF process. All Apache CXF versions prior to 4.2.3, 4.1.8, and 3.6.12 are affected when the JMS transport is in use. No public exploit code or CISA KEV listing has been identified at time of analysis, though the vulnerability class (CWE-502 with unrestricted ObjectInputStream) is well-understood and tooling such as ysoserial makes it routinely exploitable wherever gadget libraries are present.
Denial of service persists in Apache CXF due to an incomplete remediation of CVE-2026-50645, allowing unauthenticated network attackers to exhaust server resources by submitting messages containing an excessive number of MIME attachment headers. All Apache CXF deployments running versions prior to 4.2.3, 4.1.8, or 3.6.12 remain vulnerable despite having applied the prior patch. No public exploit code or active exploitation has been identified at time of analysis, but the bypass-of-fix nature of this vulnerability means any organization that patched CVE-2026-50645 and considered itself remediated must re-patch.
Uncontrolled resource consumption in Apache CXF's JAX-RS form parameter processing enables remote denial-of-service attacks against any exposed endpoint accepting form-encoded requests. The framework provides a 'maxFormParameterCount' configuration knob but sets no default ceiling, meaning unpatched deployments will parse arbitrarily large parameter sets until memory or CPU is exhausted. Fixed versions (4.2.3, 4.1.8, and 3.6.12) enforce a default cap of 500 parameters; no public exploit or CISA KEV listing has been identified at time of analysis.
Unbounded attachment ingestion in Apache CXF enables remote denial-of-service against any endpoint that processes multipart messages. Versions prior to 4.2.3, 4.1.8, and 3.6.12 imposed no default ceiling on the 'attachment-max-size' parameter, allowing attackers to exhaust server memory or processing capacity by submitting arbitrarily large attachments. No public exploit has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog, but the low attack complexity makes this a realistic threat for internet-exposed CXF deployments.
Remote code execution in Apache CXF (versions before 3.6.11, 4.0.0-4.1.5, and 4.2.0) arises because the fix for CVE-2025-48913 was incomplete, leaving a second code path through which untrusted JMS configuration can be abused to execute code. The flaw only matters where untrusted users are permitted to supply or influence JMS transport configuration for CXF endpoints. This is a remediation-regression issue carrying no public exploit identified at time of analysis, a very low EPSS (0.10%), and SSVC exploitation status of 'none', but the technical impact is rated total.
Arbitrary certificate disclosure in Apache CXF's XKMS server lets remote attackers abuse an LDAP injection flaw (CWE-90) in the LDAP-backed certificate repository to retrieve certificates they are not authorized to see. Affected builds span Apache CXF 3.x before 3.6.11, 4.0.0-4.1.x before 4.1.6, and 4.2.0 before 4.2.1; the issue was reported by Apache itself and fixed in those releases. No public exploit identified at time of analysis, EPSS is very low (0.02%, 4th percentile), and CISA SSVC scores exploitation as 'none' with only 'partial' technical impact.
Open redirect in Apache CXF's OIDC relying-party component lets remote, unauthenticated attackers steer users to an attacker-controlled site by planting external URLs inside OIDC state parameters that the RP preserves and later reuses as a post-authentication redirect target. Only deployments that actually enable the OIDC relying-party code path are exposed, and a victim must be lured into initiating and completing an authentication flow through an attacker-supplied link, so exploitation is not fully automatic. Both directly encoded and double-encoded external URLs can slip past origin validation depending on which validation path runs; there is no public exploit identified at time of analysis, vendor-released fixes are available in 4.2.4, 4.1.9, and 3.6.13, and the assessed CVSS:3.1 vector AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N reflects a low-severity redirect impact gated by mandatory user interaction.
XML External Entity injection in Apache CXF's WS-Transfer module exposes SOAP endpoints to server-side file read and internal network probing by unauthenticated remote attackers. The insecure XML parser configuration (CWE-611) affects all 3.x releases before 3.6.11, 4.0.x-4.1.x before 4.1.6, and 4.2.0 before 4.2.1. No public exploit has been identified at time of analysis, EPSS sits at the 8th percentile (0.03%), and CISA SSVC rates exploitation as 'none', placing this squarely in the patch-on-schedule rather than emergency-response category despite the broad network attack vector.