| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| io.qameta.allure.plugins:xunit-xml-plugin | maven | <= 2.34.0 | 2.34.1 |
| io.qameta.allure.plugins:junit-xml-plugin | maven | <= 2.34.0 | 2.34.1 |
| io.qameta.allure.plugins:trx-plugin | maven | <= 2.34.0 | 2.34.1 |
The vulnerability is a classic XML External Entity (XXE) injection affecting three different plugins in Allure Framework: xunit-xml-plugin, junit-xml-plugin, and trx-plugin. The root cause is the same across all three plugins: they use the standard Java DocumentBuilderFactory to parse XML files from the test results directory without properly securing the parser. Specifically, they fail to disable Document Type Definitions (DTDs) and external entity expansion.
The patch cbcb33719851ff70adce85d38e15d20fc58d4eb7 addresses this by:
ClasspathEntityResolver that only allows resolving DTDs from the application's classpath, effectively blocking external entities from remote or local file system locations.factory.setValidating(false) to disable DTD validation.builder.setEntityResolver(new ClasspathEntityResolver())) to the DocumentBuilder in each of the affected plugins before parsing the input XML file.The vulnerable functions are the ones that instantiate the insecure XML parser and use it to parse user-controlled files. By analyzing the patch, I identified the following methods where the insecure parsing occurs:
io.qameta.allure.xunitxml.XunitXmlPlugin.parseAssembliesio.qameta.allure.junitxml.JunitXmlPlugin.parseRootElementio.qameta.allure.trx.TrxPlugin.parseTestRunThese functions are the direct entry points for the vulnerability. When Allure generates a report, it calls these methods to process XML test result files. An attacker can place a malicious XML file containing an XXE payload in the results directory. When the vulnerable function is called, the parser will process the malicious payload, leading to information disclosure (e.g., reading local files like /etc/passwd) or Server-Side Request Forgery (SSRF). The new test cases added in the patch confirm this behavior by attempting to read a local file via an XXE payload and asserting that the file's content is not present in the final report, proving the fix is effective.
Ongoing coverage of React2Shell