Description

Apache CXF reads a top-level WSDL through its hardened StaxUtils path, which disables XML DTDs and external entities. However, any <wsdl:import> or <xsd:import> referenced from that top-level WSDL is handed off to WSDL4J, which does not disable DOCTYPE declarations or external entities. As a result, the protections applied to the top-level document do not extend to imported documents, leaving imported WSDL/XSD content vulnerable to XML External Entity (XXE) attacks. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-06T11:16:30.463Z",
  "pubdate": "2026-08-06T11:16:30.463Z",
  "executiveSummary": "An XML External Entity (XXE) vulnerability exists in Apache CXF due to inconsistent parser hardening across WSDL and XSD document ingestion paths. While the framework correctly disables XML DTDs and external entity processing for top-level WSDL files processed through StaxUtils, it delegates the parsing of referenced <wsdl:import> and <xsd:import> documents to WSDL4J.\nWSDL4J fails to enforce the same security constraints, leaving DOCTYPE declarations and external entities active during the parsing of imported definitions. This security gap allows remote attackers to supply malicious WSDL or XSD imports containing crafted external entity references.\nSuccessful exploitation of this vulnerability can lead to unauthorized disclosure of confidential local files residing on the server, server-side request forgery (SSRF), and potential denial-of-service conditions through recursive entity expansion attacks. The impact directly compromises the confidentiality and integrity of the hosting infrastructure.\nThe vulnerability affects Apache CXF deployments handling untrusted WSDL or XSD inputs. Exploitation requires the attacker to supply or influence a top-level WSDL document that triggers the loading of a malicious imported schema or service definition containing external entity payloads. Remediation requires upgrading to the patched software versions provided by the vendor.",
  "technicalDetails": "The root cause of the vulnerability stems from a disparity in XML parsing configurations between the primary parsing pipeline and secondary document resolution mechanisms within Apache CXF. When Apache CXF ingests a top-level WSDL document, it utilizes a hardened StaxUtils execution path that explicitly disables the processing of XML Document Type Definitions (DTDs) and external entities, thereby neutralizing standard XXE vectors at the initial entry point.\nHowever, the attack surface persists because the architecture delegates the retrieval and parsing of subsequently referenced schemas and service definitions—specifically those declared via <wsdl:import> and <xsd:import> elements—to the WSDL4J library. WSDL4J does not inherit the security context or feature configurations enforced by the hardened StaxUtils path and instantiates its own underlying XML parsers without disabling external entity resolution or DOCTYPE declarations by default.\nThe attack flow proceeds as follows: First, an attacker provides or hosts a maliciously crafted top-level WSDL file containing an import directive pointing to an external or attacker-controlled resource (<wsdl:import> or <xsd:import>). Second, Apache CXF successfully processes the top-level document through its secure StaxUtils path without triggering alarms. Third, the framework hands off the resolution of the imported document to WSDL4J. Fourth, WSDL4J parses the imported WSDL or XSD document, which contains a malicious DOCTYPE declaration defining an external entity (e.g., pointing to file:///etc/passwd or an internal network service via HTTP). Fifth, the underlying XML parser resolves the external entity, reading local file contents or executing unauthorized outbound requests.\nThe vulnerable component is the integration layer between Apache CXF and WSDL4J responsible for handling imported WSDL and XSD documents. The affected software versions include all versions prior to the designated security releases. The vulnerability can be exploited over the network if the application dynamically consumes untrusted WSDL endpoints or processes user-supplied WSDL files. No authentication or elevated privileges are strictly required if the endpoint accepting the WSDL definition is exposed to unauthenticated clients."
}