Spring Web Services CVE-2026-40998: Brief Summary of the Jaxp13XPathTemplate XXE Bypass

Introduction

A parser hardening bypass in Spring Web Services allows unauthenticated attackers to perform XML External Entity (XXE) attacks against any application that evaluates XPath expressions over untrusted XML using the Jaxp13XPathTemplate class. The flaw, scored at CVSS 8.2, is particularly notable because it silently circumvents the very XXE protections that Spring's own hardened parser configuration is designed to enforce, creating a false sense of security for developers who assumed the framework handled XML safely.

This is not the first time Spring Web Services has been caught with an XXE gap. CVE-2019-3773 disclosed a similar class of issue seven years ago, and CVE-2013-7315 exposed XXE in the broader Spring Framework before that. The recurrence of this weakness category across the Spring ecosystem makes CVE-2026-40998 worth examining not just for its immediate impact, but for what it reveals about the challenge of maintaining consistent parser hardening across a large codebase.

Technical Information

Root Cause: Divergent Parser Configurations

CVE-2026-40998 resides in the Jaxp13XPathTemplate class within the org.springframework.ws/spring-ws-core Maven artifact. This class is an implementation of XPathOperations that uses JAXP 1.3, which has been part of Java SE since version 1.5. It is used when applications need to evaluate XPath expressions against XML payloads, a common operation in SOAP based web service processing.

Spring Web Services maintains a hardened XML parser configuration that disables dangerous XML features such as external entity resolution and DTD processing. However, when Jaxp13XPathTemplate processes StreamSource or SAXSource inputs, it delegates parsing to the JDK's default DocumentBuilderFactory. This default factory does not apply Spring's hardening measures. The JDK's default behavior permits XML documents to define external entities with URIs that resolve to resources outside the application's intended sphere of control, as documented in CWE-611.

The core issue is a code path divergence: Spring's primary XML processing paths use the hardened configuration, but Jaxp13XPathTemplate takes a separate path for these two specific source types that bypasses it entirely. Developers relying on Spring's documented security posture would have no indication that this particular class operates under different, weaker parsing rules.

CVSS v3.1 Scoring Breakdown

The 8.2 base score reflects the combination of easy remote exploitation and high confidentiality impact:

Attack Flow

The preconditions for exploitation, as stated in the Spring advisory, are: "exposing XPath evaluation over data controlled or influenced by remote users, either directly or through message paths, and using the vulnerable source types without an additional hardening layer."

The attack proceeds as follows:

1. Identify a target endpoint: The attacker locates an application endpoint that accepts XML input and processes it through Jaxp13XPathTemplate using StreamSource or SAXSource. This is common in SOAP based web services that perform XPath evaluation on incoming messages.

2. Craft a malicious XML payload: The attacker constructs an XML document containing an external entity definition. For file disclosure, the entity references a file:// URI pointing to a sensitive file on the server (e.g., /etc/passwd, application configuration files, or credentials). For SSRF, the entity references an http:// URI pointing to an internal service.

3. Submit the payload: The attacker sends the crafted XML to the target endpoint. Because the attack vector is network based and requires no authentication or user interaction, this can be done with a simple HTTP request.

4. Parser resolves the external entity: The Jaxp13XPathTemplate class parses the XML using the JDK's default DocumentBuilderFactory, which does not restrict external entity resolution. The parser fetches the resource specified in the entity definition.

5. Exfiltrate data: The resolved entity content (file contents or internal service responses) is incorporated into the parsed document. Depending on the application's response behavior, this content may be returned directly to the attacker or may be extractable through error messages or out of band channels.

The Spring advisory explicitly identifies two attack outcomes: confidential file disclosure and server side request forgery (SSRF) through external entities.

The Patch Gap Problem

A critical aspect of this vulnerability is the differential availability of fixes across version branches. OSS (open source) fixes exist only for the two most recent branches: 5.0.x and 4.1.x. Fixes for the 4.0.x and 3.1.x branches are gated behind Broadcom's Enterprise Support subscription. Organizations running these older branches without Enterprise subscriptions have no officially sanctioned remediation path.

This creates a two tier security landscape. Broadcom's June 2026 announcement of "day zero CVE patches" for Enterprise subscribers formalizes this model. Proofpoint has observed that adversaries increasingly exploit the gap between vulnerability disclosure and remediation, and the lack of OSS patches for older branches extends this window indefinitely for some organizations.

Affected Systems and Versions

The affected Maven package is org.springframework.ws/spring-ws-core. The following version ranges are vulnerable:

The Spring advisory notes that "versions which are no longer officially supported are also affected by this issue." The spring-ws-core package has 227 usages documented on Maven Central, indicating significant adoption in production environments.

Applications are vulnerable if they meet the following conditions:

• They use Jaxp13XPathTemplate to evaluate XPath expressions
• The XML input is provided as StreamSource or SAXSource
• The XML content is controlled or influenced by remote users, either directly or through message processing paths
• No additional XML hardening layer is applied outside of Spring's default configuration

Vendor Security History

Spring Web Services and the broader Spring Framework have a documented pattern of XXE vulnerabilities across multiple years:

The OWASP XXE Prevention Cheat Sheet specifically notes that "some XXE vulnerabilities were found in Spring OXM and Spring MVC" affecting Spring Framework versions 3.0.0 to 3.2.3. The recurrence of this weakness class across the Spring ecosystem suggests that hardening measures applied to one code path do not consistently propagate to all XML processing paths within the codebase.

Broadcom, which now oversees the Spring portfolio through its Tanzu division, reported a 1700% increase in monthly Spring security advisories from March to April 2026. The company responded with what it described as the largest series of Spring security updates in the framework's 23 year history, including expanded security tooling and SLSA Level 3 supply chain protections. The CVE was assigned by VMware ([email protected]), reflecting the CNA lineage from VMware's role even under Broadcom ownership.

References

• CVE-2026-40998: Jaxp13 XPath XXE via StreamSource (Spring Advisory)
• CVE Record: CVE-2026-40998
• CVE-2026-40998 on OffSeq Radar
• CWE-611: Improper Restriction of XML External Entity Reference
• OWASP: XML External Entity (XXE) Processing
• OWASP XXE Prevention Cheat Sheet
• PortSwigger: XML External Entity (XXE) Injection
• CVE-2019-3773: XML External Entity Injection in Spring Web Services
• Spring Security Advisories (Historical)
• Broadcom Expands Its Investment in Spring and Java Ecosystem Security
• Broadcom Bolsters Spring Security with Largest Update Ever
• CISA Known Exploited Vulnerabilities Catalog
• Jaxp13XPathTemplate API Documentation
• spring-ws-core on Maven Central
• org.springframework.ws on MVN Repository
• The Patch Gap Just Got Faster and Hackers Know It (Proofpoint/PCQuest)