CVE-2026-49875
Patch Available.
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
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.
An Information Exposure vulnerability (CVE-2026-49875) has been identified in the XML schema handling of Apache CXF's EndpointReferenceUtils and W3CMultiSchemaFactory classes, which allows attackers to trigger out-of-band (OOB) XML external entity (XXE) resolution while CXF compiles XML schemas, exposing local files and internal network resources to an attacker-controlled endpoint.
Per OWASP: Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.
This issue affects all versions prior to 3.6.12, versions 4.0.0 up to but not including 4.1.7, and versions 4.2.0 up to but not including 4.2.2 of Apache CXF.
Details
Module Info
- Product: Apache CXF
- Affected packages:
org.apache.cxf:cxf-core - Affected versions: <3.6.12, >=4.0.0 <4.1.7, >=4.2.0 <4.2.2
- GitHub repository: https://github.com/apache/cxf
- Published packages: https://central.sonatype.com/artifact/org.apache.cxf/cxf-core
- Package manager: Maven
- Fixed in:
- OSS Apache CXF 4.2.2, 4.1.7, 3.6.12
- NES for Apache CXF v3.5.13, v3.4.12
Vulnerability Info
This Critical-severity vulnerability is found in the org.apache.cxf:cxf-core package in all versions prior to 3.6.12, versions 4.0.0 up to but not including 4.1.7, and versions 4.2.0 up to but not including 4.2.2 of Apache CXF.
When CXF needs a compiled javax.xml.validation.Schema for a service (for example, when schema validation is enabled on an endpoint), EndpointReferenceUtils.getSchema collects the schema documents referenced by the service model, including schemas imported from WSDL and XSD locations, and hands them to a JAXP SchemaFactory. The factory is created with the platform defaults: secure processing is not enabled and the ACCESS_EXTERNAL_DTD and ACCESS_EXTERNAL_SCHEMA restrictions are left open, so DOCTYPE declarations and external entity or schema references inside those documents are resolved:
private static Schema createSchema(ServiceInfo serviceInfo, Bus b) {
Schema schema = serviceInfo.getProperty(Schema.class.getName(), Schema.class);
if (schema == null) {
SchemaFactory factory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
Map<String, byte[]> schemaSourcesMap = new LinkedHashMap<>();
Map<String, Source> schemaSourcesMap2 = new LinkedHashMap<>();
...
factory.setResourceResolver(new SchemaLSResourceResolver(schemaSourcesMap,
b != null ? b : BusFactory.getThreadDefaultBus(false)));
schema = factory.newSchema(schemaSourcesMap2.values()
.toArray(new Source[schemaSourcesMap2.size()]));
The legacy Woodstox/MSV validation path in W3CMultiSchemaFactory.createSchema has the same weakness. It builds a SAXParserFactory to read the schema sources without enabling secure processing or disallowing DOCTYPE declarations:
parserFactory = SAXParserFactory.newInstance();
parserFactory.setNamespaceAware(true);
WSDLGrammarReaderController ctrl = new WSDLGrammarReaderController(null, baseURI, embeddedSources);
xmlSchemaReader = new RecursiveAllowedXMLSchemaReader(ctrl, parserFactory);
multiSchemaReader = new MultiSchemaReader(xmlSchemaReader);
for (Source source : schemaSources.values()) {
multiSchemaReader.parse(source);
}
If an attacker can influence a schema document that CXF compiles, for example a WSDL or XSD fetched from a location they control, they can embed a DOCTYPE with external parameter entities. The parser then fetches attacker-chosen URLs and can send the contents of local files or internal resources out of band to an attacker-controlled server.
This vulnerability was introduced in 2006 with Apache CXF 2.0-incubator-M1.
Mitigation
Only recent versions of Apache CXF are community-supported. The 3.5.x line was already End-of-Life when this CVE was published 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
- Venkatraman Kumar from Securin (finder)