CVE-2026-84665 in SonarQube Scanner Plugin
Summary
by MITRE • 09/02/2026
Jenkins SonarQube Scanner Plugin 2.18.3 and earlier does not limit URL schemes for the dashboard links it creates based on SonarQube scanner results, allowing the `javascript:` scheme, resulting in a stored cross-site scripting (XSS) vulnerability exploitable by attackers with Item/Configure permission.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/02/2026
The Jenkins SonarQube Scanner Plugin version 2.18.3 and earlier contains a critical security flaw related to improper validation of URL schemes within dashboard links generated from SonarQube scanner results. This vulnerability stems from the application's failure to restrict or sanitize the protocol scheme used in hyperlinks embedded in the plugin's user interface. Specifically, the software allows the javascript: URI scheme to be processed and rendered directly by the web browser without adequate filtering or encoding. In standard web security practices, URL schemes such as http, https, ftp, and mailto are generally safe for navigation purposes because they initiate resource retrieval rather than code execution. However, the inclusion of script-based URIs like javascript: allows arbitrary JavaScript to be executed within the context of the Jenkins application's domain when a user interacts with these links.
This technical flaw results in a stored cross-site scripting vulnerability that can be exploited by attackers possessing Item/Configure permissions on a Jenkins project or pipeline. The attack vector involves an authenticated attacker injecting malicious SonarQube scanner configurations into a build job. When the SonarQube Scanner Plugin processes the scan results, it constructs dashboard links based on data provided in those results. If the injected configuration includes a URL with a javascript: scheme, this malformed link is stored within Jenkins and subsequently rendered in the web interface. Because the vulnerability is classified as stored XSS, the malicious payload persists on the server side rather than being transient like reflected XSS, increasing its potential impact by affecting any user who views the affected dashboard or report page.
The operational impact of this vulnerability is severe for organizations relying on Jenkins for continuous integration and delivery pipelines. An attacker with Item/Configure permissions can achieve arbitrary code execution within the context of the victim's browser session. This capability allows for a wide range of malicious activities, including stealing sensitive authentication tokens such as CSRF cookies or API keys stored in local storage, hijacking user sessions to perform unauthorized actions on behalf of legitimate users, and potentially pivoting further into the internal network if Jenkins is integrated with other systems that trust the Jenkins session context. The presence of this vulnerability undermines the integrity of the CI/CD pipeline by allowing compromised build configurations to act as a vector for broader system compromise.
From an industry standard perspective, this issue aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. The specific mechanism involving URI schemes falls under the sub-category of using script URIs in HTML attributes or links. Furthermore, within the MITRE ATT&CK framework for Enterprise, this vulnerability facilitates techniques associated with Collection and Credential Access, specifically leveraging stored XSS to harvest credentials or session tokens from users interacting with the compromised Jenkins instance. The lack of input validation on URL schemes represents a fundamental failure in secure coding practices regarding output encoding and content security policy enforcement.
To mitigate this risk, organizations should immediately upgrade the SonarQube Scanner Plugin to version 2.18.4 or later, where the developers have implemented strict filtering to prevent non-standard URI schemes from being rendered as clickable links. In environments where upgrading is not immediately feasible, administrators can implement a reverse proxy configuration using tools like Nginx or Apache HTTP Server to inspect and block requests containing javascript: URIs in query parameters or POST bodies directed at Jenkins endpoints associated with SonarQube reporting. Additionally, enforcing strict Content Security Policy headers that disallow script execution from inline sources or specific domains can provide an additional layer of defense by preventing the browser from executing any injected JavaScript payloads even if they are successfully rendered in the DOM. Regular auditing of plugin permissions and limiting Item/Configure access to trusted personnel further reduces the attack surface available for exploitation.