Apache CXF EUVD-2026-36402

Exploitation requires all of the following: (1) The target application uses the Apache CXF artifact cxf-rt-rs-security-jose-jaxrs at a vulnerable version (4.2.0-4.2.1 or any version before 4.1.7). (2) A JAX-RS endpoint is protected by JwsJsonContainerRequestFilter - this is not a default CXF configuration; it must be explicitly configured by the application developer. (3) The attacker must be able to reach the endpoint and submit JWS JSON Serialization-formatted requests, which inherently requires possessing or forging a signing credential accepted by the filter. (4) The endpoint or downstream application logic makes a security-relevant decision based on the Content-Type or a signed HTTP header value extracted from the JWS protected header. Exploitation is limited by: the non-default nature of the filter (must be deliberately deployed), the requirement for a valid signing credential for at least one signature entry, and the need for downstream code to act on the spoofed metadata in a harmful way.

No CVSS vector or EPSS score was provided in the available data, requiring independent assessment. The vulnerability is network-exploitable against JAX-RS endpoints using JwsJsonContainerRequestFilter, but requires the attacker to possess a signing credential accepted by the endpoint - reducing the realistic threat surface relative to fully unauthenticated flaws. Attack complexity is high because the attacker must construct a syntactically valid multi-signature JWS JSON token where only one entry bears an accepted signature while the first entry carries malicious metadata. Real-world impact depends entirely on how the downstream application uses Content-Type or signed-header values: in the most severe case, manipulating Content-Type could trigger unexpected deserialization or parser behavior in the JAX-RS layer; in benign configurations the metadata may be ignored. No KEV listing and no public exploit code have been identified, suggesting this is not currently under mass exploitation. The risk profile is moderate-to-low for most deployments but warrants prompt patching wherever JWS JSON signing is used for authorization or input validation decisions.

An attacker holding a legitimate signing key accepted by a deployed Apache CXF JAX-RS endpoint constructs a JWS JSON token with two signature entries: the first contains an attacker-crafted protected header (e.g., a spoofed Content-Type value pointing to a class the application deserializes) but an invalid or absent signature, while the second entry carries the attacker's genuine, accepted signature over the actual payload. The JwsJsonContainerRequestFilter accepts the token because the second signature validates, but then reads the Content-Type from the unverified first entry, causing the JAX-RS layer to deserialize the body using the attacker-specified type. No public proof-of-concept code has been identified at time of analysis.