CVE-2025-67641 is a stored cross-site scripting (XSS) vulnerability found in the Jenkins Coverage Plugin, specifically in versions 2.3054.ve1ff7b_a_a_123b_ and earlier. The root cause is the plugin's failure to validate the coverage results ID when job configurations are created or modified through the Jenkins REST API. While the plugin validates this ID when submitted via the UI, the REST API path lacks this validation, allowing an attacker with Item/Configure permissions to inject a malicious `javascript:` scheme URL as the identifier. This malicious script is then stored and can execute in the context of users viewing the coverage results, leading to potential session hijacking, credential theft, or further exploitation within the Jenkins environment. The vulnerability requires the attacker to have authenticated access with Item/Configure permissions, which are typically granted to developers or build administrators. The CVSS v3.1 base score is 8.0, indicating high severity, with attack vector as network, low attack complexity, requiring privileges, and user interaction. The impact covers confidentiality, integrity, and availability, as successful exploitation could allow attackers to execute arbitrary scripts, manipulate build data, or disrupt CI/CD pipelines. No public exploits have been reported yet, but the vulnerability poses a significant risk given Jenkins' widespread use in automated software development workflows.

For European organizations, this vulnerability poses a serious risk to the security of their continuous integration and delivery pipelines. Exploitation could lead to unauthorized code execution within Jenkins, allowing attackers to steal sensitive information such as credentials, inject malicious code into build artifacts, or disrupt software delivery processes. This could result in compromised software integrity, data breaches, and operational downtime. Organizations relying heavily on Jenkins for DevOps automation, especially those in regulated industries like finance, healthcare, and critical infrastructure, may face compliance violations and reputational damage. The requirement for Item/Configure permissions limits the attack surface but does not eliminate risk, as insiders or compromised developer accounts could be leveraged. The stored XSS nature means that multiple users interacting with Jenkins could be affected, amplifying the impact. Given the interconnected nature of modern development environments, a successful attack could cascade into broader network compromise.

1. Immediately audit and restrict Item/Configure permissions to only trusted users to reduce the risk of malicious configuration changes via the REST API. 2. Monitor Jenkins REST API usage for unusual or unauthorized configuration changes, especially those involving the Coverage Plugin. 3. Implement network segmentation and access controls to limit Jenkins server exposure to only necessary personnel and systems. 4. Educate developers and administrators about the risks of stored XSS and the importance of secure plugin configuration. 5. Apply security hardening best practices for Jenkins, including enabling security realms and authorization strategies that enforce least privilege. 6. Stay alert for official patches or updates from the Jenkins project and apply them promptly once released. 7. Consider implementing Web Application Firewall (WAF) rules to detect and block suspicious payloads targeting the Coverage Plugin endpoints. 8. Regularly review and sanitize all user-generated inputs and configurations where possible to prevent injection attacks.