CVE-2026-55847

Allure 2 is the version 2.x branch of Allure Report, a multi-language test reporting tool. Prior to 2.39.0, the ansi.js helper at allure-generator/src/main/javascript/helpers/ansi.js passes attacker-influenced statusMessage and statusTrace values through AnsiToHtml without HTML escaping and wraps the result in Handlebars SafeString, disabling template auto-escaping in allure-generator/src/main/javascript/blocks/status-details/status-details.hbs. JunitXmlPlugin.java can populate these fields directly from crafted JUnit XML failure messages and traces, and equivalent input flows exist in the TRX, xUnit XML, xctest, and Allure1 and Allure2 plugins. When a user views the affected status details, unescaped markup executes arbitrary JavaScript in the report origin, which can expose report data and compromise sessions associated with that origin. This is an incomplete-fix case because PR 3271 escaped link helpers but did not address the ANSI helper. This issue is fixed in version 2.39.0.

Allure 2 is the version 2.x branch of Allure Report, a multi-language test reporting tool. Prior to 2.39.0, the ansi.js helper at allure-generator/src/main/javascript/helpers/ansi.js passes attacker-influenced statusMessage and statusTrace values through AnsiToHtml without HTML escaping and wraps the result in Handlebars SafeString, disabling template auto-escaping in allure-generator/src/main/javascript/blocks/status-details/status-details.hbs. JunitXmlPlugin.java can populate these fields directly from crafted JUnit XML failure messages and traces, and equivalent input flows exist in the TRX, xUnit XML, xctest, and Allure1 and Allure2 plugins. When a user views the affected status details, unescaped markup executes arbitrary JavaScript in the report origin, which can expose report data and compromise sessions associated with that origin. This is an incomplete-fix case because PR 3271 escaped link helpers but did not address the ANSI helper. This issue is fixed in version 2.39.0.

Summary

The ansi.js Handlebars helper in allure-generator passes user-controlled statusMessage and statusTrace values from test result files through the ansi-to-html library and wraps the output in Handlebars SafeString without HTML escaping. Since ansi-to-html does not escape HTML entities by default, an attacker who can influence test result content (e.g., via crafted JUnit XML failure messages) can inject arbitrary JavaScript that executes when anyone views the generated Allure report.

Details

The vulnerability is an incomplete fix — commit 4c64b19 (PR #3271) fixed XSS in linky.js and text-with-links.js by adding escapeExpression(), but the same pattern in ansi.js was not addressed.

Vulnerable sink — allure-generator/src/main/javascript/helpers/ansi.js:10-11:

export default function (input) {
    return new SafeString(ansiConverter.toHtml(input));
};

The AnsiToHtml constructor at line 4 does not set escapeForHtml: true:

const ansiConverter = new AnsiToHtml({
    fg: "black",
    bg: "black",
    newline: true,
});

The ansi-to-html library (v0.7.2) defaults escapeForHtml to false, meaning HTML entities in the input pass through unchanged. Wrapping the result in SafeString tells Handlebars to skip its auto-escaping, so the raw HTML reaches the browser.

Template usage — allure-generator/src/main/javascript/blocks/status-details/status-details.hbs:7,10:

<pre class="status-details__message"><code>{{ansi statusMessage}}</code></pre>
...
<pre class="{{b 'status-details' 'trace'}}"><code>{{ansi statusTrace}}</code></pre>

Source — plugins/junit-xml-plugin/src/main/java/io/qameta/allure/junitxml/JunitXmlPlugin.java:307-308:

result.setStatusMessage(element.getAttribute(MESSAGE_ATTRIBUTE_NAME));
result.setStatusTrace(element.getValue());

These values are read directly from XML attributes with no sanitization. The same pattern exists in TRX, xUnit XML, xctest, and Allure1/2 plugins.

Contrast with the fixed helper — linky.js (post-fix) correctly escapes before wrapping in SafeString:

const safeText = escapeExpression(text);
return new SafeString(`<a href="${safeText}" ...>${safeText}</a>`);

PoC

1. Create a malicious JUnit XML test result file:

<?xml version="1.0" encoding="UTF-8"?>
<testsuite name="XSSTest" tests="1" failures="1">
  <testcase name="xssPayload" classname="com.example.Test">
    <failure message="&lt;img src=x onerror=alert(document.cookie)&gt;">
      Stack trace: &lt;img src=x onerror=alert('statusTrace_XSS')&gt;
    </failure>
  </testcase>
</testsuite>

2. Generate an Allure report:

allure generate /path/to/results-with-malicious-xml -o /tmp/allure-report

3. Open the report and navigate to the failed test case:

allure open /tmp/allure-report

4. When viewing the test's status details, the <img onerror> payloads execute JavaScript in the viewer's browser.

Impact

• Arbitrary JavaScript execution in the browser of anyone viewing the generated Allure report
• Cookie theft, session hijacking if the report is served from a domain with active sessions (e.g., CI dashboards)
• Data exfiltration — the injected script can read the full report content and send it to an attacker-controlled server
• Attack vectors: A malicious dependency that throws crafted exception messages, a CI pipeline processing test results from untrusted pull requests, or a contributor submitting test files containing XSS payloads
• Allure reports are commonly hosted on CI/CD platforms (Jenkins, GitLab, GitHub Actions artifacts) where session cookies may be present

Recommended Fix

Configure AnsiToHtml with escapeForHtml: true to escape HTML entities while preserving ANSI-to-HTML conversion:

import AnsiToHtml from "ansi-to-html";
import {SafeString} from "handlebars/runtime";

const ansiConverter =…

Allure 2 is the version 2.x branch of Allure Report, a multi-language test reporting tool. Prior to 2.39.0, the ansi.js helper at allure-generator/src/main/javascript/helpers/ansi.js passes attacker-influenced statusMessage and statusTrace values through AnsiToHtml without HTML escaping and wraps the result in Handlebars SafeString, disabling template auto-escaping in allure-generator/src/main/javascript/blocks/status-details/status-details.hbs. JunitXmlPlugin.java can populate these fields directly from crafted JUnit XML failure messages and traces, and equivalent input flows exist in the TRX, xUnit XML, xctest, and Allure1 and Allure2 plugins. When a user views the affected status details, unescaped markup executes arbitrary JavaScript in the report origin, which can expose report data and compromise sessions associated with that origin. This is an incomplete-fix case because PR 3271 escaped link helpers but did not address the ANSI helper. This issue is fixed in version 2.39.0.

Allure 2 is the version 2.x branch of Allure Report, a multi-language test reporting tool. Prior to 2.39.0, the ansi.js helper at allure-generator/src/main/javascript/helpers/ansi.js passes attacker-influenced statusMessage and statusTrace values through AnsiToHtml without HTML escaping and wraps the result in Handlebars SafeString, disabling template auto-escaping in allure-generator/src/main/javascript/blocks/status-details/status-details.hbs. JunitXmlPlugin.java can populate these fields directly from crafted JUnit XML failure messages and traces, and equivalent input flows exist in the TRX, xUnit XML, xctest, and Allure1 and Allure2 plugins. When a user views the affected status details, unescaped markup executes arbitrary JavaScript in the report origin, which can expose report data and compromise sessions associated with that origin. This is an incomplete-fix case because PR 3271 escaped link helpers but did not address the ANSI helper. This issue is fixed in version 2.39.0.

Summary

The ansi.js Handlebars helper in allure-generator passes user-controlled statusMessage and statusTrace values from test result files through the ansi-to-html library and wraps the output in Handlebars SafeString without HTML escaping. Since ansi-to-html does not escape HTML entities by default, an attacker who can influence test result content (e.g., via crafted JUnit XML failure messages) can inject arbitrary JavaScript that executes when anyone views the generated Allure report.

Details

The vulnerability is an incomplete fix — commit 4c64b19 (PR #3271) fixed XSS in linky.js and text-with-links.js by adding escapeExpression(), but the same pattern in ansi.js was not addressed.

Vulnerable sink — allure-generator/src/main/javascript/helpers/ansi.js:10-11:

export default function (input) {
    return new SafeString(ansiConverter.toHtml(input));
};

The AnsiToHtml constructor at line 4 does not set escapeForHtml: true:

const ansiConverter = new AnsiToHtml({
    fg: "black",
    bg: "black",
    newline: true,
});

The ansi-to-html library (v0.7.2) defaults escapeForHtml to false, meaning HTML entities in the input pass through unchanged. Wrapping the result in SafeString tells Handlebars to skip its auto-escaping, so the raw HTML reaches the browser.

Template usage — allure-generator/src/main/javascript/blocks/status-details/status-details.hbs:7,10:

<pre class="status-details__message"><code>{{ansi statusMessage}}</code></pre>
...
<pre class="{{b 'status-details' 'trace'}}"><code>{{ansi statusTrace}}</code></pre>

Source — plugins/junit-xml-plugin/src/main/java/io/qameta/allure/junitxml/JunitXmlPlugin.java:307-308:

result.setStatusMessage(element.getAttribute(MESSAGE_ATTRIBUTE_NAME));
result.setStatusTrace(element.getValue());

These values are read directly from XML attributes with no sanitization. The same pattern exists in TRX, xUnit XML, xctest, and Allure1/2 plugins.

Contrast with the fixed helper — linky.js (post-fix) correctly escapes before wrapping in SafeString:

const safeText = escapeExpression(text);
return new SafeString(`<a href="${safeText}" ...>${safeText}</a>`);

PoC

1. Create a malicious JUnit XML test result file:

<?xml version="1.0" encoding="UTF-8"?>
<testsuite name="XSSTest" tests="1" failures="1">
  <testcase name="xssPayload" classname="com.example.Test">
    <failure message="&lt;img src=x onerror=alert(document.cookie)&gt;">
      Stack trace: &lt;img src=x onerror=alert('statusTrace_XSS')&gt;
    </failure>
  </testcase>
</testsuite>

2. Generate an Allure report:

allure generate /path/to/results-with-malicious-xml -o /tmp/allure-report

3. Open the report and navigate to the failed test case:

allure open /tmp/allure-report

4. When viewing the test's status details, the <img onerror> payloads execute JavaScript in the viewer's browser.

Impact

• Arbitrary JavaScript execution in the browser of anyone viewing the generated Allure report
• Cookie theft, session hijacking if the report is served from a domain with active sessions (e.g., CI dashboards)
• Data exfiltration — the injected script can read the full report content and send it to an attacker-controlled server
• Attack vectors: A malicious dependency that throws crafted exception messages, a CI pipeline processing test results from untrusted pull requests, or a contributor submitting test files containing XSS payloads
• Allure reports are commonly hosted on CI/CD platforms (Jenkins, GitLab, GitHub Actions artifacts) where session cookies may be present

Recommended Fix

Configure AnsiToHtml with escapeForHtml: true to escape HTML entities while preserving ANSI-to-HTML conversion:

import AnsiToHtml from "ansi-to-html";
import {SafeString} from "handlebars/runtime";

const ansiConverter =…

Allure 2 is the version 2.x branch of Allure Report, a multi-language test reporting tool. Prior to 2.39.0, the ansi.js helper at allure-generator/src/main/javascript/helpers/ansi.js passes attacker-influenced statusMessage and statusTrace values through AnsiToHtml without HTML escaping and wraps the result in Handlebars SafeString, disabling template auto-escaping in allure-generator/src/main/javascript/blocks/status-details/status-details.hbs. JunitXmlPlugin.java can populate these fields directly from crafted JUnit XML failure messages and traces, and equivalent input flows exist in the TRX, xUnit XML, xctest, and Allure1 and Allure2 plugins. When a user views the affected status details, unescaped markup executes arbitrary JavaScript in the report origin, which can expose report data and compromise sessions associated with that origin. This is an incomplete-fix case because PR 3271 escaped link helpers but did not address the ANSI helper. This issue is fixed in version 2.39.0.