CVE-2026-24400 is a critical (CVSS 9.1) XML external entity flaw in AssertJ, the Java testing library. It affects versions 1.4.0 up to but not including 3.27.7, and only when untrusted XML reaches isXmlEqualTo or XmlStringPrettyFormatter. Upgrade to 3.27.7, or switch to XMLUnit.
What's affected
The affected range is AssertJ from 1.4.0 and before 3.27.7. The fix is in 3.27.7.
The advisory is clear that an application is vulnerable only when it passes untrusted XML to one of two methods: isXmlEqualTo(CharSequence) from AbstractCharSequenceAssert, or xmlPrettyFormat(String) from XmlStringPrettyFormatter. The parser behind them was created with default settings, with DTDs and external entities not disabled. AssertJ deprecated isXmlEqualTo(CharSequence) in favor of XMLUnit in 3.18.0, and plans to remove it in 4.0.
Because AssertJ is a test library, most projects use it only in test scope. That limits the exposure, though it does not remove it, for example when tests process external fixture files.
How to check if you're exposed
Find AssertJ in your build.
Maven:
mvn dependency:tree -Dincludes=org.assertj
Gradle:
./gradlew dependencies --configuration testRuntimeClasspath | grep assertj
Then search your code for the two methods:
grep -rn "isXmlEqualTo\|xmlPrettyFormat" src/
No hits means the vulnerable code is not called from your tests. Check shaded or transitive copies too.
For a quick look at your own dependencies, Safeguard's free in-browser dependency scan at https://gold.safeguard.sh/scan checks them against known CVEs in your browser.
What to do now
- Upgrade AssertJ to 3.27.7 or later.
- If you cannot upgrade yet, stop using isXmlEqualTo(CharSequence) and XmlStringPrettyFormatter with untrusted XML.
- Prefer replacing isXmlEqualTo(CharSequence) with XMLUnit, which is the advisory's first suggestion.
- Keep AssertJ in test scope and do not ship it in production classpaths.
- Make sure CI builds do not feed externally supplied XML into these assertions.
Why it matters
The weakness is CWE-611, improper restriction of XML external entity reference. An XML parser that resolves external entities can be told to read local files, make requests to other hosts, or expand entities until memory runs out. The advisory lists file reads through file URIs, server side request forgery over HTTP and HTTPS, and denial of service through entity expansion.
The score is high because the vector is network based with no login, but the real exposure depends on one thing: whether untrusted XML ever reaches those methods. In many projects the answer is no. That is why a reachability check beats a version check here. The CVE is not in CISA's Known Exploited Vulnerabilities catalog.
Telling real exposure from theoretical exposure
AssertJ is a good example of a dependency where the headline and the reality are far apart. A critical XXE score sounds like a server on fire. The advisory itself narrows it to applications that pass untrusted XML to two methods. For most teams the library sits in test scope and the methods are either unused or fed only with fixtures written by the team.
So the useful questions are short. Is AssertJ on a production classpath, or only in tests? Does any test call isXmlEqualTo(CharSequence) or xmlPrettyFormat(String)? If so, where does the XML come from? A fixture file in your repository is trusted. A response captured from a live system, or a file from a customer, may not be.
Test code still runs somewhere. CI runners often hold deploy keys, cloud credentials and package publishing tokens. An XXE that reads local files on a build agent can reach those. That is the reason the advisory example mentions test environments that handle external fixture files. If your tests ever consume XML you did not write, upgrade and review the CI runner's secrets.
Why XXE keeps coming back
XML parsers in Java ship with features switched on by default for compatibility, and external entity resolution is one of them. Every library that creates a parser with default settings inherits the risk. The OWASP cheat sheet linked from the record explains the safe settings, which disable document type definitions and external entities. When you write your own XML handling, apply them at the point where the parser is created.
Reachability beats version matching
A scanner that lists every project containing AssertJ below 3.27.7 gives you a long list and no order. Reachability analysis narrows it to the projects that call the affected methods, so you can fix those first and schedule the rest with the normal upgrade cycle. That is the approach Safeguard takes with reachability analysis, and the demo below shows the idea.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is every project using AssertJ affected?
No. The advisory says only applications that use untrusted XML with isXmlEqualTo(CharSequence) or xmlPrettyFormat(String) are vulnerable.
What does the project recommend first?
Replace isXmlEqualTo(CharSequence) with XMLUnit, then upgrade to 3.27.7, then avoid the vulnerable methods with untrusted input.
Sources
Last reviewed: 19 October 2026.
