Jenkins update-center2 CVE-2026-84677

Exploitation requires the attacker to be able to contribute a plugin for hosting on the Jenkins update center - this implies either being an accepted Jenkins plugin contributor or compromising the credentials/pipeline of an existing contributor (PR:L). A victim user must then actively navigate to the plugin download index page for the malicious plugin (UI:R). The vulnerability does not affect Jenkins server installations that do not browse the update-center-generated plugin index pages. Non-default configurations or special feature enablement are not required on the victim side; however, the attacker-side requirement for plugin contribution access is a meaningful barrier. Exploitation is not automatable per the SSVC assessment.

The CVSS 5.4 medium score is appropriate. The PR:L metric reflects that exploitation requires the attacker to have plugin contribution access to the Jenkins hosting infrastructure - a non-trivial barrier that significantly limits the attacker pool to trusted plugin contributors or anyone who can get a plugin accepted for hosting. UI:R further constrains exploitation to scenarios where a victim actively visits the affected plugin download index page. SSVC corroborates limited real-world risk: exploitation status is none, the attack is not automatable, and technical impact is partial. No KEV listing and no public exploit code are consistent with this assessment. The primary realistic threat is a malicious or compromised plugin contributor targeting Jenkins administrators who browse the plugin catalog. The scope-change (S:C) does elevate the potential impact - a successful XSS could steal session tokens or perform actions in the update-center web context - but the prerequisite for plugin hosting access keeps overall risk moderate.

A malicious actor with plugin contributor access to the Jenkins update center submits a plugin whose name or description contains an injected JavaScript payload (e.g., a crafted script tag in the plugin display name). When a Jenkins administrator or developer browses the plugin download index page for that plugin, the unescaped payload executes in their browser, potentially exfiltrating session cookies or performing unauthorized actions within the update center's web context. No public exploit code has been identified, but the attack pattern is straightforward for anyone familiar with basic stored XSS techniques.