CVE-2026-100227

Overview

Apache CXF is an open-source services framework, maintained by the Apache Software Foundation, for building and consuming web services in Java. It implements the JAX-WS and JAX-RS APIs and supports SOAP, the WS-* standards, RESTful HTTP, and OAuth 2.0 over transports such as HTTP and JMS. Its modules are published as Maven artifacts under org.apache.cxf.

A signature forgery vulnerability (CVE-2026-100227) has been identified in the JAX-RS XML Security module of Apache CXF, which allows attackers to wrap any document signed by a trusted key in unsigned content that the application then treats as signed.

Per OWASP: Software and data integrity failures relate to code and infrastructure that does not protect against integrity violations.

This issue affects multiple versions of Apache CXF.

Details

Module Info

• Product: Apache CXF
• Affected packages: org.apache.cxf:cxf-rt-rs-security-xml
• Affected versions: <3.6.13, >=4.0.0 <4.1.9, >=4.2.0 <4.2.4
• GitHub repository: https://github.com/apache/cxf
• Published packages: https://central.sonatype.com/artifact/org.apache.cxf/cxf-rt-rs-security-xml
• Package manager: Maven
• Fixed in:
  • OSS Apache CXF 3.6.13, 4.1.9, 4.2.4
  • NES for Apache CXF v3.4.13, v3.5.14

Vulnerability Info

This Medium-severity vulnerability is found in the org.apache.cxf:cxf-rt-rs-security-xml package in multiple versions of Apache CXF. The JAX-RS XML Signature filters XmlSigInHandler and XmlSigInInterceptor, which share AbstractXmlSigInHandler, and the streaming XmlSecInInterceptor verify an XML Signature on the request body but do not make sure that the XML they hand to the application is the XML the signature covers.

In AbstractXmlSigInHandler, the reference check only requires the enveloped-signature transform when the referenced element is the document root, and it ignores any other transform it does not recognize:

Element signedEl = getSignedElement(root, ref);
if (signedEl != null) {
    enveloped = signedEl == root;
} else {
    throwFault("Signature Reference ID is invalid", null);
}
...
for (int i = 0; i < transforms.getLength(); i++) {
    try {
        Transform tr = transforms.item(i);
        if (Transforms.TRANSFORM_ENVELOPED_SIGNATURE.equals(tr.getURI())) {
            envelopedConfirmed = true;
        } else if (c14TransformExpected != null && c14TransformExpected.equals(tr.getURI())) {
            c14TransformConfirmed = true;
        }
    } catch (Exception ex) {
        throwFault("Problem accessing Transform instance", ex);
    }
}

So a reference may point at a child element rather than the root, and transforms that exclude part of the referenced content are accepted. Once the signature value checks out, the handler passes the whole document root to the application, not the signed element:

message.setContent(XMLStreamReader.class,
                   new W3CDOMStreamReader(root));

For an enveloping signature, the body handed on is simply the first element of the first ds:Object, which need not be the element the reference points at:

Element objectNode = getNode(envelopingSigElement, Constants.SignatureSpecNS, "Object", 0);
...
Element node = DOMUtils.getFirstElement(objectNode);

The streaming XmlSecInInterceptor has the same gap: when a signature is required it only checks that a signature value was processed somewhere in the request, not that the root element is the signed one.

if (signatureRequired) {
    Event requiredEvent = SecurityEventConstants.SignatureValue;
    if (!isEventInResults(requiredEvent, incomingSecurityEventList)) {
        ...
    }
}

An attacker who holds any document signed by a trusted key can therefore keep the signed element (so the signature still verifies) and wrap it in, or place next to it, unsigned content of their choosing. The application then reads that unsigned content as if it were signed, defeating the integrity and origin guarantees the signature was meant to give.

Mitigation

Only recent versions of Apache CXF are community-supported. Older lines are End-of-Life and will not receive public updates to address this issue.

Users of the affected components should apply one of the following mitigations:

• Upgrade to a currently supported Apache CXF release line (3.6.x or later) that contains the fix.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Guanping Zhang (finder)