CVE-2026-24400

Overview

AssertJ is a Java library that provides a rich set of strongly typed, fluent assertions for writing tests with JUnit, TestNG or any other test framework. It is published to Maven Central as org.assertj:assertj-core.

An XML External Entity (XXE) vulnerability (CVE-2026-24400) has been identified in the XML comparison assertions of AssertJ, which allows attackers to read local files, send requests to internal network services and cause a denial of service through entity expansion. The assertions parse XML with a parser that resolves DOCTYPE declarations and external entities, so an attacker who can place XML in a comparison can make the parser load files and URLs of their choosing.

Per OWASP: An XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. This attack may lead to the disclosure of confidential data, denial of service, server side request forgery, port scanning from the perspective of the machine where the parser is located, and other system impacts.

This issue affects AssertJ versions 1.4.0 through 3.27.6.

Details

Module Info

• Product: AssertJ
• Affected packages: org.assertj:assertj-core
• Affected versions: >=1.4.0 <=3.27.6
• GitHub repository: https://github.com/assertj/assertj
• Published packages: https://central.sonatype.com/artifact/org.assertj/assertj-core
• Package manager: Maven
• Fixed in:
  • OSS AssertJ 3.27.7
  • NES for AssertJ v3.22.2

Vulnerability Info

This Critical-severity vulnerability is found in the org.assertj:assertj-core package in AssertJ versions 1.4.0 through 3.27.6.

The isXmlEqualTo(CharSequence) assertion compares two XML documents by pretty-printing both and comparing the results. The formatting is done by org.assertj.core.util.xml.XmlStringPrettyFormatter, whose toXmlDocument method builds its parser from a default DocumentBuilderFactory:

private static Document toXmlDocument(String xmlString) {
  try {
    InputSource xmlInputSource = new InputSource(new StringReader(xmlString));
    DocumentBuilder xmlDocumentBuilder = DocumentBuilderFactory.newInstance().newDocumentBuilder();
    return xmlDocumentBuilder.parse(xmlInputSource);
  } catch (Exception e) {
    throw new RuntimeException(FORMAT_ERROR, e);
  }
}

A default DocumentBuilderFactory accepts DOCTYPE declarations, resolves external general and parameter entities, and expands nested internal entities. Three public entry points reach this method: isXmlEqualTo(CharSequence), which formats both the actual and the expected XML, isXmlEqualToContentOf(File), which reads the expected XML from a file and then calls isXmlEqualTo, and the public static XmlStringPrettyFormatter.xmlPrettyFormat(String).

An attacker who controls the XML on either side of a comparison, for example a fixture file, generated XML, or a response from a service under test, can declare an external entity that points to a local file. The parser reads the file and places its contents in the document, and the assertion's failure message then shows them. External entities that point to URLs make the parser send requests to hosts reachable from the machine running the tests, and nested entity definitions ("Billion Laughs") can cause a denial of service. AssertJ usually runs in test code, so the exposed data is that of the build or CI environment, such as credentials, source code and internal network services.

Steps to Reproduce

1. Add org.assertj:assertj-core 3.22.0 to a test project.
2. Run a test that compares XML containing an external entity that reads a local file:

import static org.assertj.core.api.Assertions.assertThat;
import org.junit.jupiter.api.Test;

class XxeTest {
  @Test
  void readsLocalFile() {
    String xml = "<?xml version=\"1.0\"?>"
        + "<!DOCTYPE root [<!ENTITY xxe SYSTEM \"file:///etc/hosts\">]>"
        + "<root>&xxe;</root>";
    assertThat(xml).isXmlEqualTo("<root/>");
  }
}

The assertion fails, and its failure message contains the contents of /etc/hosts.

Mitigation

Only the latest AssertJ release line receives security fixes upstream, so older release lines will not receive updates to address this issue. For more information, see here.

Users of the affected components should apply one of the following mitigations:

• Upgrade affected applications to a currently supported release of AssertJ that contains the fix.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• wxt201 (finder)
• Song-Li (finder)