Apache CXF CVE-2026-100227

Exploitation requires that the application consume inbound XML using Apache CXF's JAX-RS XML Signature verification - specifically XmlSigInHandler, XmlSigInInterceptor, or the streaming XmlSecInInterceptor; CXF deployments that do not enable these XML signature interceptors are not affected. The attacker must also possess at least one XML document already signed by a key the target trusts, which they then wrap in unsigned content. Limiting factors: the vulnerability only manifests in this non-default XML-signature configuration and depends on the attacker first acquiring a trusted-key-signed artifact, though once obtained the forgery can be repeated. Fixed in CXF 4.2.4, 4.1.9, and 3.6.13.

This is a genuine integrity-impact flaw but a moderate-priority one in practice. The vendor CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N = 7.5) indicates a remotely reachable, unauthenticated signature-wrapping (XSW-style) bypass with no confidentiality or availability impact - only integrity (I:H), because forged/unsigned content is accepted as authentically signed. All exploitation signals point AWAY from urgency: EPSS is only 0.17% (6th percentile), there is no CISA KEV listing, and no public exploit code is identified in the provided sources. No SSVC decision data was supplied. A notable caveat: the vector shows PR:N, but exploitation realistically requires the attacker to first obtain at least one document legitimately signed by a trusted key - this is a meaningful precondition the base vector does not capture and arguably warrants AC:H in some deployments. Additionally, the CWE (CWE-362 Race Condition) and the 'Information Disclosure'/'Race Condition' tags CONFLICT with the description and vector: the issue is improper signature verification (CWE-347 class) with integrity, not confidentiality, impact - treat those labels as erroneous (see data_quality_flags). Net: a real defense-in-depth bug worth patching on affected deployments, but not an actively-exploited emergency; prioritize for systems that actually enable the JAX-RS XML signature interceptors.

An attacker obtains any XML document that was validly signed by a key the target trusts (e.g., a previously intercepted or legitimately issued signed message). They wrap that signed element inside attacker-controlled, unsigned XML and submit it to a JAX-RS endpoint whose application relies on XmlSigInHandler, XmlSigInInterceptor, or the streaming XmlSecInInterceptor. The interceptor confirms a valid signature exists but fails to verify it actually covers the payload delivered to the application, so the forged unsigned content is processed as trusted. No public exploit code is identified at time of analysis.