CVE-2026-24400: 
Java vulnerability analysis and mitigation

CVE-2026-24400 is an XML External Entity (XXE) injection vulnerability in the AssertJ Java testing library, specifically within org.assertj.core.util.xml.XmlStringPrettyFormatter. The toXmlDocument(String) method initializes DocumentBuilderFactory with default settings that do not disable DTDs or external entities, enabling XXE attacks when untrusted XML is processed. It affects AssertJ versions 1.4.0 through 3.27.6 (across the 1.x, 2.x, and 3.x release lines), with the fix available in version 3.27.7. The vulnerability was disclosed on January 24, 2026, and published to the GitHub Advisory Database on January 26, 2026. It carries a CVSS v3.1 base score of 9.1 (Critical) and a CVSS v4.0 base score of 8.2 (High) (GitHub Advisory, AssertJ Security Advisory).

The root cause is CWE-611 (Improper Restriction of XML External Entity Reference): the XmlStringPrettyFormatter.toXmlDocument(String) method creates a DocumentBuilderFactory instance without explicitly disabling DTD processing or external entity resolution, leaving the XML parser open to XXE attacks. Exploitation requires that an application passes attacker-controlled XML to either isXmlEqualTo(CharSequence) (from org.assertj.core.api.AbstractCharSequenceAssert) or xmlPrettyFormat(String) (from org.assertj.core.util.xml.XmlStringPrettyFormatter); this scenario is most likely in test environments that process external fixture files or user-supplied XML. The fix, committed in 85ca7eb, deprecates XmlStringPrettyFormatter and addresses the unsafe parser configuration (GitHub Advisory, AssertJ Security Advisory).

Successful exploitation can result in three distinct attack outcomes: arbitrary local file disclosure via file:// URIs (e.g., reading /etc/passwd or application configuration files containing credentials), Server-Side Request Forgery (SSRF) via HTTP/HTTPS URIs that can be used to probe internal network services, and Denial of Service through "Billion Laughs" recursive entity expansion attacks that exhaust memory. The confidentiality impact is high, as sensitive files accessible to the JVM process can be exfiltrated; integrity is not directly affected, but SSRF may enable lateral movement to internal systems (GitHub Advisory, Red Hat Bugzilla).

1. Identify a vulnerable target: Locate an application or test pipeline using AssertJ versions 1.4.0–3.27.6 that passes untrusted or externally-supplied XML to isXmlEqualTo(CharSequence) or xmlPrettyFormat(String) — for example, a test suite that reads XML fixture files from user-controlled paths.
2. Craft a malicious XML payload: Construct an XML document with an external entity declaration pointing to a target resource, such as a local file or internal HTTP endpoint:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root>&xxe;</root>

3. Inject the payload: Supply the crafted XML as input to the vulnerable method — e.g., by placing it in an XML fixture file read by the test, or by injecting it through an application endpoint that internally calls isXmlEqualTo() or xmlPrettyFormat().
4. Trigger XML parsing: Cause the application to invoke XmlStringPrettyFormatter.toXmlDocument() with the malicious input; the unprotected DocumentBuilderFactory will resolve the external entity.
5. Exfiltrate data or trigger SSRF/DoS: The resolved entity content (e.g., /etc/passwd contents) is embedded in the parsed document and may be returned in error messages, logs, or assertion output; alternatively, use an HTTP URI to perform SSRF against internal services, or use a "Billion Laughs" payload to cause memory exhaustion (GitHub Advisory, AssertJ Security Advisory).

• Logs: Unexpected Java XML parser errors or SAXParseException stack traces referencing XmlStringPrettyFormatter or DocumentBuilderFactory in application or test logs; log entries showing file paths (e.g., /etc/passwd) or internal URLs appearing in XML assertion output or error messages.
• Network: Outbound HTTP/HTTPS requests from the JVM process to unexpected internal IP addresses or hostnames, particularly originating from test runner or application server processes — indicative of SSRF exploitation.
• Process: Unusual memory consumption or JVM out-of-memory errors during XML processing, which may indicate a "Billion Laughs" DoS attempt.
• File System: Evidence of sensitive file contents (e.g., /etc/passwd, configuration files with credentials) appearing in test output files, log files, or assertion failure messages.

The primary remediation is to upgrade AssertJ (org.assertj:assertj-core) to version 3.27.7 or later, which fixes the XXE vulnerability and deprecates XmlStringPrettyFormatter (AssertJ Release). The preferred long-term solution is to replace all uses of isXmlEqualTo(CharSequence) with XMLUnit, as isXmlEqualTo was deprecated in version 3.18.0 and will be removed in version 4.0. If immediate upgrade is not feasible, avoid passing untrusted XML input to isXmlEqualTo(CharSequence) or XmlStringPrettyFormatter.xmlPrettyFormat(String). IBM has also issued advisories for affected products including IBM Business Automation Manager Open Editions, IBM Operator for Apache Flink, and IBM watsonx Data Intelligence (IBM Advisory).

The vulnerability was responsibly disclosed by researchers wxt201 and Song-Li, who were credited in the AssertJ 3.27.7 release notes (AssertJ Release). Red Hat tracked the issue via Bugzilla with medium severity, noting its impact on information disclosure and denial of service (Red Hat Bugzilla). IBM issued multiple security bulletins for downstream products affected by the AssertJ dependency, including Apache Flink Operator and Business Automation Manager Open Editions (IBM Advisory). SUSE and openSUSE also issued security updates for the assertj-core package in their distributions.