CVE-2026-92134 in Warnings Plugin
Summary
by MITRE • 09/16/2026
Jenkins Warnings Plugin 13.10258.va_17d49a_78c3b_ and earlier does not validate the analysis results ID when a job configuration is submitted through the REST API, allowing attackers with Item/Configure permission to use a javascript: scheme URL as identifier, resulting in a stored cross-site scripting (XSS) vulnerability.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The Jenkins Warnings Plugin version 13.10258.va_17d49a_78c3b and earlier contains a critical input validation flaw that permits the execution of malicious scripts within the context of the Jenkins web application interface. This vulnerability arises from an insufficient sanitization mechanism when processing job configuration data submitted via the REST API. Specifically, the plugin fails to validate or escape the analysis results identifier field before storing it in the system's persistent storage and subsequently rendering it back into HTML views without proper encoding.
The technical root cause of this issue is a classic stored cross-site scripting (XSS) vulnerability classified under CWE-79: Improper Neutralization of Input During Web Page Generation. By leveraging the REST API, an attacker who possesses Item/Configure permissions on a Jenkins job can inject arbitrary JavaScript code into the analysis results ID field. Because the plugin does not enforce strict type checking or content validation for this specific parameter, it accepts and stores values containing javascript: scheme URLs as if they were legitimate identifiers. When other users view the affected job's configuration or result pages, the browser interprets these stored scripts as executable code due to the lack of output encoding in the rendering process.
The operational impact of this vulnerability is severe because it allows for persistent compromise rather than transient session hijacking typical of reflected XSS attacks. An attacker with Item/Configure permissions can embed malicious payloads that execute every time a user accesses the compromised job's interface. This persistence enables attackers to steal sensitive authentication tokens, such as Jenkins API keys or CSRF tokens, which are typically stored in browser cookies or local storage. Furthermore, this capability facilitates broader lateral movement within the CI/CD infrastructure by allowing the attacker to automate actions on behalf of authenticated users, potentially leading to unauthorized code deployments, credential theft from build environments, or complete system compromise depending on the privileges associated with the Jenkins instance and its connected agents.
This vulnerability aligns with MITRE ATT&CK technique T1059.007: JavaScript, which describes how attackers use scripting languages to execute commands within a web browser context. It also relates to T1136.002: Create Account: Cloud Account, if the stolen credentials are used to provision new resources in connected cloud environments via automated scripts triggered by the XSS payload. The lack of input validation on API-driven configuration changes highlights a broader security gap where programmatic interfaces bypass UI-level protections that might otherwise sanitize user inputs through standard form submissions.
To mitigate this vulnerability, organizations must immediately upgrade the Jenkins Warnings Plugin to version 13.10259.va_8e7c4a_b_d6f or later, which implements proper input validation and output encoding for all analysis results identifiers regardless of the submission method. Administrators should also enforce strict least-privilege policies regarding Item/Configure permissions, ensuring that only trusted users can modify job configurations via the REST API. Additionally, implementing a Content Security Policy (CSP) header in Jenkins configuration can provide an additional layer of defense by restricting script execution sources and mitigating the impact of any remaining XSS vectors. Regular auditing of plugin versions and continuous monitoring for anomalous JavaScript activity in browser console logs are recommended practices to detect potential exploitation attempts early.