The Jenkins Coverage Plugin, widely used to measure code coverage in Jenkins continuous integration environments, contains a stored cross-site scripting (XSS) vulnerability identified as CVE-2025-67641. The vulnerability exists because the plugin does not validate the coverage results ID when coverage results are created programmatically via the REST API. While the plugin validates this ID during job configuration through the UI, this validation is absent in API calls. An attacker with Item/Configure permission can exploit this by submitting a malicious `javascript:` scheme URL as the coverage results ID, which is then stored and rendered in Jenkins interfaces. This stored XSS can execute arbitrary JavaScript in the context of users viewing the affected Jenkins pages, potentially leading to session hijacking, credential theft, or execution of further malicious actions within the Jenkins environment. The vulnerability requires the attacker to have at least Item/Configure permission, which is a moderate level of privilege typically granted to developers or build engineers. No CVSS score has been assigned yet, and no known exploits have been reported in the wild. However, the vulnerability's presence in a critical CI/CD tool like Jenkins and the ability to execute persistent XSS makes it a significant risk. The lack of patch links suggests that a fix may not yet be publicly available, emphasizing the need for immediate mitigation steps. Organizations relying on Jenkins for build automation and code coverage reporting should review their plugin versions and permissions to reduce exposure.

For European organizations, this vulnerability can lead to unauthorized execution of malicious scripts within Jenkins environments, compromising the confidentiality and integrity of build processes and potentially exposing sensitive source code or credentials. Attackers exploiting this flaw could hijack sessions of Jenkins users, escalate privileges, or inject malicious payloads into build pipelines, disrupting software delivery and increasing the risk of supply chain attacks. Given Jenkins' widespread use in software development across Europe, especially in technology, finance, and manufacturing sectors, this vulnerability could impact critical infrastructure and intellectual property. The requirement for Item/Configure permission limits exploitation to insiders or compromised accounts, but insider threats or credential theft scenarios remain plausible. The absence of known exploits currently reduces immediate risk but does not eliminate the threat, as attackers may develop exploits once the vulnerability is publicly known. The persistent nature of stored XSS means that multiple users could be affected over time, amplifying the impact. Disruption to CI/CD pipelines could delay software releases and increase operational costs.

European organizations should immediately audit their Jenkins instances to identify usage of the Coverage Plugin versions 2.3054.ve1ff7b_a_a_123b_ or earlier. Until a patch is released, restrict Item/Configure permissions to the minimum necessary users to reduce the attack surface. Implement strict access controls and monitor for unusual configuration changes via the REST API. Use web application firewalls (WAFs) with rules to detect and block suspicious `javascript:` scheme URLs in API requests. Enable Content Security Policy (CSP) headers on Jenkins to mitigate the impact of XSS by restricting script execution sources. Regularly review Jenkins logs for signs of exploitation attempts or anomalous API activity. Educate Jenkins administrators and developers about the risk of granting excessive permissions and the importance of validating inputs in CI/CD tools. Once a patch becomes available, prioritize its deployment across all Jenkins instances. Consider isolating Jenkins environments and limiting network exposure to reduce the risk of lateral movement if exploitation occurs.