CVE-2026-24400 Overview
An XML External Entity (XXE) vulnerability has been identified in AssertJ, the popular fluent testing assertions library for Java and the Java Virtual Machine (JVM). The vulnerability exists in the org.assertj.core.util.xml.XmlStringPrettyFormatter class, where the toXmlDocument(String) method initializes DocumentBuilderFactory with default settings without disabling DTDs or external entities.
Critical Impact
Attackers exploiting this XXE vulnerability can read arbitrary local files via file:// URIs (e.g., /etc/passwd, application configuration files), perform Server-Side Request Forgery (SSRF) via HTTP/HTTPS URIs, and cause Denial of Service via "Billion Laughs" entity expansion attacks.
Affected Products
- AssertJ versions 1.4.0 through 3.27.6
- Applications using isXmlEqualTo(CharSequence) from org.assertj.core.api.AbstractCharSequenceAssert with untrusted input
- Applications using xmlPrettyFormat(String) from org.assertj.core.util.xml.XmlStringPrettyFormatter with untrusted input
Discovery Timeline
- 2026-01-26 - CVE CVE-2026-24400 published to NVD
- 2026-01-27 - Last updated in NVD database
Technical Details for CVE-2026-24400
Vulnerability Analysis
This vulnerability is classified as CWE-611 (Improper Restriction of XML External Entity Reference). The core issue stems from insecure XML parsing configuration in the XmlStringPrettyFormatter utility class. When applications use the affected methods (isXmlEqualTo(CharSequence) or xmlPrettyFormat(String)) with untrusted XML input, the underlying XML parser processes external entity declarations without restriction.
The attack surface requires local access to the application processing XML data. An application is only vulnerable when it processes untrusted XML input through these specific AssertJ methods. While AssertJ is primarily a testing framework, the vulnerability can be exploited if test code processes external or user-supplied XML data during test execution, or if the XmlStringPrettyFormatter utility is inadvertently used in production code.
Root Cause
The vulnerability originates from the toXmlDocument(String) method in XmlStringPrettyFormatter, which creates a DocumentBuilderFactory instance with default settings. The default configuration does not disable:
- External DTD loading
- External entity processing
- Parameter entity expansion
This insecure default behavior allows malicious XML documents containing external entity references to be processed, enabling attackers to exfiltrate sensitive data or cause resource exhaustion.
Attack Vector
An attacker can craft malicious XML payloads containing external entity declarations. When this payload is passed to isXmlEqualTo(CharSequence) or xmlPrettyFormat(String), the XML parser resolves the external entities, leading to:
- Local File Disclosure: Using file:// protocol handlers to read system files
- SSRF: Using http:// or https:// protocol handlers to make arbitrary network requests
- Denial of Service: Using recursive entity expansion ("Billion Laughs" attack) to exhaust memory
* Very much inspired by http://stackoverflow.com/questions/139076/how-to-pretty-print-xml-from-java and
* http://pastebin.com/XL7932aC
* </p>
+ * @deprecated this is an internal utility for
+ * {@link org.assertj.core.api.AbstractCharSequenceAssert#isXmlEqualTo(CharSequence) isXmlEqualTo(CharSequence)}
+ * rather than a feature for AssertJ users, therefore its usage is discouraged and
+ * no replacement is provided.
*/
+@Deprecated
public class XmlStringPrettyFormatter {
private static final String FORMAT_ERROR = "Unable to format XML string";
Source: GitHub Commit 85ca7eb
Detection Methods for CVE-2026-24400
Indicators of Compromise
- Unexpected file access attempts from Java processes, particularly targeting sensitive files like /etc/passwd or application configuration files
- Outbound HTTP/HTTPS requests originating from test execution environments to unknown external hosts
- Memory exhaustion or CPU spikes during XML processing operations in test suites
- Stack traces showing XmlStringPrettyFormatter or DocumentBuilderFactory with external entity resolution errors
Detection Strategies
- Scan project dependencies for AssertJ versions between 1.4.0 and 3.27.6 using software composition analysis (SCA) tools
- Search codebase for usages of isXmlEqualTo() and XmlStringPrettyFormatter.xmlPrettyFormat() methods
- Monitor test execution logs for unusual file system access patterns or network activity
- Implement static analysis rules to flag XML parsing without secure configuration
Monitoring Recommendations
- Enable detailed logging for XML parsing operations in test environments
- Monitor network egress from CI/CD systems for unexpected outbound connections during test execution
- Configure file integrity monitoring on sensitive system files that may be targeted by XXE attacks
- Implement alerting for abnormal memory consumption during test suite execution
How to Mitigate CVE-2026-24400
Immediate Actions Required
- Upgrade AssertJ to version 3.27.7 or later immediately
- Audit codebase for usage of isXmlEqualTo(CharSequence) and XmlStringPrettyFormatter with untrusted input
- Replace isXmlEqualTo(CharSequence) with XMLUnit for XML comparison assertions (recommended approach)
- Ensure no untrusted XML data is processed through affected AssertJ methods until patching is complete
Patch Information
The AssertJ maintainers have addressed this vulnerability in version 3.27.7. The fix deprecates the vulnerable XmlStringPrettyFormatter class entirely, with complete removal planned for version 4.0. The isXmlEqualTo(CharSequence) method was previously deprecated in version 3.18.0 in favor of XMLUnit and will also be removed in version 4.0.
For detailed patch information, refer to:
Workarounds
- Migrate to XMLUnit for XML assertion capabilities, which is the recommended long-term solution
- Avoid using isXmlEqualTo(CharSequence) or XmlStringPrettyFormatter with any untrusted input
- Implement input validation to sanitize XML before processing if immediate upgrade is not possible
- Follow the OWASP XML Entity Prevention Cheat Sheet guidelines for secure XML processing
# Upgrade AssertJ to patched version using Maven
mvn versions:use-dep-version -Dincludes=org.assertj:assertj-core -DdepVersion=3.27.7
# Or update pom.xml dependency directly
# <dependency>
# <groupId>org.assertj</groupId>
# <artifactId>assertj-core</artifactId>
# <version>3.27.7</version>
# <scope>test</scope>
# </dependency>
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
