Description

Allure 2 is the version 2.x branch of Allure Report, a multi-language test reporting tool. Prior to 2.39.0, the HTTP server started by allure serve and allure open uses URI.getPath() in Commands.setUpServer() in allure-commandline/src/main/java/io/qameta/allure/Commands.java and passes the percent-decoded request path to reportDirectory.resolve() without normalizing the result or confirming that it remains inside that directory. An unauthenticated client that can reach the server can submit parent-directory segments, including percent-encoded segments, and cause serveFile() to return any regular file readable by the Allure process. The server binds to localhost by default, but the --host option can expose it to other systems, and local users, adjacent containers, or browser-origin attacks may reach a local listener. This can disclose credentials, configuration, source code, build secrets, and other CI/CD data. This issue is fixed in version 2.39.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.2",
  "pubDate": "2026-09-14T18:17:55.830Z",
  "pubdate": "2026-09-14T18:17:55.830Z",
  "executiveSummary": "Allure 2 versions prior to 2.39.0 are vulnerable to a path traversal vulnerability originating from improper validation of user-supplied request paths in the HTTP server component. The vulnerability resides in the way the application processes URI paths, allowing an unauthenticated remote or local attacker to perform directory traversal attacks.\nBy manipulating the request URI with parent-directory segments, an attacker can bypass intended access restrictions and read arbitrary files on the host filesystem accessible to the process. This exposure is particularly critical in CI/CD environments, as it may lead to the unauthorized disclosure of sensitive information such as environment variables, build secrets, source code, and configuration files.\nWhile the default configuration binds the server to the localhost interface, the use of the '--host' option increases the attack surface, potentially exposing the service to external network segments or adjacent containers. Successful exploitation does not require authentication, making it a high-risk security flaw for any infrastructure running older versions of Allure Report.",
  "technicalDetails": "The vulnerability is rooted in the implementation of the HTTP server within 'allure-commandline/src/main/java/io/qameta/allure/Commands.java'. Specifically, the 'Commands.setUpServer()' method utilizes 'URI.getPath()' to extract the resource path from incoming HTTP requests. The retrieved path is then subjected to percent-decoding before being passed directly to the 'reportDirectory.resolve()' method without adequate sanitization or normalization of the resulting path strings.\nThe primary failure occurs because the application does not perform canonicalization or validation to ensure the resolved path remains within the boundaries of the intended 'reportDirectory'. An attacker can exploit this by crafting HTTP requests that contain directory traversal sequences, such as '/../' or URL-encoded variations (e.g., '%2e%2e%2f'). These sequences allow the server-side logic to resolve paths outside the designated report folder, eventually enabling the 'serveFile()' function to read and return the contents of any arbitrary file that the system process has read permissions to access.\nThe attack flow proceeds as follows: First, the attacker identifies a reachable Allure instance. Second, the attacker constructs a malicious HTTP GET request where the URI path includes parent-directory navigation segments designed to escape the root directory. Third, the application's 'setUpServer()' routine decodes these segments and resolves them against the base path. Finally, the server processes the request as a legitimate file retrieval operation and streams the contents of the target system file back to the attacker's client.\nThe risk is exacerbated by the lack of authentication mechanisms for the server and the potential for the server to be exposed on non-localhost interfaces via the '--host' parameter. This exposes the service to potential browser-origin attacks (such as CSRF-based data exfiltration) or exploitation by other local users and adjacent containers in shared hosting environments. The vulnerability affects all versions of Allure 2 prior to 2.39.0. Post-exploitation, the impact is limited only by the filesystem permissions of the OS user account executing the Allure process, facilitating the mass exfiltration of sensitive CI/CD pipeline data."
}