What happened
Spring disclosed CVE-2019-3773 as an XML External Entity (XXE) vulnerability in Spring Web Services when affected components receive XML from untrusted sources [S1]. The vendor identifies Spring Web Services 2.4.3, 3.0.4, and older releases as affected [S1].
NVD maps the issue to CWE-611 and scores it 9.8 Critical under CVSS 3.1 [S2]. The advisory was first published in January 2019, but the relevant question for an application remains whether its resolved Spring Web Services components are still within the affected release lines [S1].
Exposure and impact
The vulnerability matters when an application uses affected Spring Web Services components to process XML from an untrusted source [S1]. In that configuration, external-entity processing can cross the intended boundary between an XML document and resources available to the parser, which is why the issue is classified as CWE-611 [S2].
A dependency declaration alone does not prove that an application exposes a reachable SOAP or XML endpoint, accepts attacker-controlled XML, or enables the affected parser path [S1]. Teams should treat an affected-version match as a version-based advisory and confirm runtime reachability and parser configuration separately [S1].
Remediation and verification
Spring directs users to upgrade the spring-ws and spring-xml JARs to 2.4.4, 3.0.6, or later [S1]. The fixed components disable the relevant XML features by default, while still allowing explicit configuration when XML comes from a trusted source [S1].
After upgrading, inspect the resolved dependency graph rather than only the top-level build file. Confirm that deployed JARs, application images, and every supported service have moved off the affected Spring Web Services versions [S1]. Review custom XML parser settings and ensure untrusted XML cannot re-enable DTD or external-entity resolution [S1].
Use benign regression documents that do not reference local files, internal services, or external callback infrastructure. Validate that the application rejects prohibited document types or external-entity declarations without retrieving any external resource.
Evidence boundaries
Repository manifests and dependency locks can establish that a project resolves an affected Spring Web Services version, but they cannot prove that the vulnerable code path is deployed or reachable [S1]. Conversely, a public endpoint fingerprint cannot reliably establish the effective JAR version or parser configuration [S1].
Conclusive exploit-style validation could cause the target parser to access files or network resources [S2]. Safe review should therefore combine dependency inventory, configuration inspection, and non-invasive regression tests rather than attempting out-of-band callbacks or sensitive-resource retrieval.