Jenkins Coverage Plugin CVE-2025-67641

Exploitation requires an attacker account with Jenkins Item/Configure permission and use of the REST API to submit the job configuration, because the javascript: scheme coverage results ID is only rejected by the UI validation path and not when coverage results are created - the REST API is the specific bypass. Being stored XSS, it additionally requires a victim (typically a higher-privileged user or administrator) to subsequently view the affected job's coverage results page for the injected script to execute (UI:R). Limiting factors: the attacker must already be authenticated and trusted with job-configuration rights (PR:L), so the realistic threat is primarily multi-tenant or lower-trust-user Jenkins deployments rather than default single-admin installs; the low confidentiality/integrity impact reflects script execution scoped to the victim's browser session.

This is a moderate-risk, authenticated stored XSS (CVSS 5.4, CWE-79) rather than a high-urgency issue. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N shows it is network-reachable with low complexity, but requires an authenticated attacker holding Item/Configure permission (PR:L) and victim interaction (UI:R) to view the tainted coverage results - meaning it is not a drive-by, unauthenticated flaw. The scope change (S:C) and low confidentiality/integrity impact reflect that injected script executes in another user's browser context against the Jenkins UI. Exploitation signals are quiet and consistent: EPSS is low at 0.31% (22nd percentile), the CVE is NOT in CISA KEV, and no public proof-of-concept is referenced - so there is no public exploit identified at time of analysis and no evidence of active exploitation. The signals do not conflict: a low EPSS and absent KEV/POC align with a privilege-gated XSS that depends on an attacker already trusted with job-configuration rights. Priority is appropriate for routine patching rather than emergency response, with higher relative concern in multi-tenant Jenkins installations where low-trust users hold Item/Configure.

An attacker who already has Item/Configure permission on a Jenkins instance submits a job configuration through the REST API (bypassing the UI-only validation) that sets a coverage results ID to a javascript: scheme URL. When a higher-privileged user such as an administrator later opens that job's coverage results page, the stored script executes in their authenticated browser session. No public exploit code is identified at time of analysis, and exploitation requires both the attacker's existing permission and victim interaction.