CVE-2026-55846 in Allure 2
Summary
by MITRE • 09/14/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability identified in Allure Report versions prior to 2.39.0 represents a critical path traversal flaw within the HTTP server component initiated by the allure serve and allure open commands. As a widely adopted multi-language test reporting tool, Allure generates comprehensive HTML reports from various testing frameworks, often containing sensitive artifacts such as source code snippets, configuration files, build logs, and potentially embedded credentials or CI/CD secrets. The core technical flaw resides in the Commands.setUpServer() method within the allure-commandline module, where the server processes incoming HTTP requests by extracting the URI path using getPath(). This extracted path is then passed directly to reportDirectory.resolve() without any normalization of directory traversal sequences such as dot-dot-slash (../) or their percent-encoded equivalents. Consequently, an attacker can manipulate the request path to escape the intended reporting directory and access arbitrary files on the underlying file system that are readable by the Allure process user account.
From a technical perspective, this vulnerability is classified under CWE-22: Improper Limitation of a Pathname to a Restricted Directory, which describes how software does not properly neutralize special elements within a pathname that can cause the path to resolve to a location outside of the intended restricted directory. The absence of input validation and canonicalization allows an unauthenticated client to bypass access controls by submitting maliciously crafted URLs containing parent-directory segments. While the server binds to localhost (127.0.0.1) by default, limiting immediate remote exploitation over the public internet, several vectors exist for local or adjacent network attackers to exploit this flaw. Local users on the same host can directly interact with the loopback interface. Furthermore, if the --host option is used to expose the server to other systems, external attackers gain direct access. Additionally, in containerized environments, an attacker compromising a neighboring container might reach the localhost listener of another container sharing network namespaces or specific port mappings. Browser-origin attacks via cross-site scripting (XSS) vulnerabilities on pages that embed Allure reports could also trigger these requests if the browser allows such interactions with local services, although modern browsers often restrict this; however, in controlled environments or with specific configurations, this remains a risk vector.
The operational impact of this vulnerability is severe due to the nature of data typically stored within test reporting directories. These directories frequently contain build artifacts and logs that may inadvertently include sensitive information such as API keys, database credentials, private SSH keys, or proprietary source code. An attacker exploiting this path traversal can read any file accessible by the Allure process, leading to a complete disclosure of confidential CI/CD pipeline data. This could facilitate further attacks, including credential theft for lateral movement within an organization's infrastructure or intellectual property theft. The vulnerability is effectively mitigated in version 2.39.0 and later releases, where the developers have implemented proper path normalization and validation checks to ensure that resolved file paths remain strictly within the designated report directory boundary.
To align with industry standards such as MITRE ATT&CK, this exploitation technique falls under T1552: Unsecured Credentials, specifically involving local credential dumping or access to configuration files if they are stored in accessible locations relative to the Allure output. It also relates to T1083: File and Directory Discovery, where an attacker enumerates and accesses sensitive system resources. Organizations running older versions of Allure Report should immediately upgrade to version 2.39.0 or later. For environments that cannot be updated immediately, mitigations include restricting access to the localhost interface using firewall rules if external exposure is not required, ensuring the Allure process runs under a restricted user account with minimal file system permissions, and auditing CI/CD pipelines for any hardcoded secrets in test reports. Regular security assessments of reporting tools are recommended to ensure that generated artifacts do not inadvertently expose sensitive infrastructure details through improper access controls or path handling mechanisms.