Jenkins Allure Plugin CVE-2026-84669

Exploitation requires a valid Jenkins account with Item/Read permission on at least one job that is configured to publish Allure test report results - this is a non-default configuration requiring the Allure Plugin to be installed and actively used in a job. The attacker must be authenticated to Jenkins (PR:L per CVSS). No user interaction from a victim is required. Exploitation is limited to users who have been granted Item/Read by a Jenkins administrator; unauthenticated or anonymous users cannot exploit this vulnerability. The read target is constrained to files accessible by the OS user account running the Jenkins controller process, so files outside that user's read permissions are not reachable.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) scores 8.8, but the integrity (I:H) and availability (A:H) components are not independently supported by the description, which exclusively describes arbitrary file read - a confidentiality-only impact. This appears to be an overstated vector; the realistic base score for an unauthenticated-to-controller file read is closer to 6.5 (C:H/I:N/A:N). SSVC rates exploitation as none and automatable as no, which is consistent with the requirement for a pre-existing authenticated session with Item/Read permission - this meaningfully limits the attacker population to credentialed Jenkins users, ruling out unauthenticated or automated mass exploitation. EPSS data is not provided. No KEV listing and no public POC have been identified, indicating this is not currently being exploited at scale. Despite the access restriction, the real-world risk remains significant in multi-tenant or large-team Jenkins deployments, where many developers hold Item/Read and the controller filesystem may contain pipeline secrets, API tokens, and SSH keys in plaintext or weakly encrypted form.

A developer or CI pipeline user with standard Item/Read access on a Jenkins job that generates Allure reports crafts a URL or API request targeting the Allure report-serving endpoint, substituting path components with directory traversal sequences (e.g., ../../) to escape the report directory. The request causes the Jenkins controller to read and return the contents of an arbitrary file, such as /var/jenkins_home/credentials.xml, exposing encrypted credentials or API tokens that can be further cracked or reused. No public exploit code has been identified at time of analysis, but the technique is well-understood and requires only standard network access to a Jenkins instance.