Jenkins CVE-2026-84649

The attack requires two simultaneous conditions: (1) the attacker must control a page served from the exact same origin (protocol, hostname, and port) as the Jenkins controller - achievable via stored XSS in any insufficiently escaped user-controlled field (job names, descriptions, build parameters, plugin UI), via a Jenkins-hosted user page, or via any other same-origin content injection vector; and (2) an authenticated Jenkins user - ideally one with administrative privileges - must visit the attacker-controlled page while holding an active session. Exploitation is strictly bounded by the same-origin policy: an attacker operating from any different domain cannot read the JavaScript response containing the crumb. Jenkins instances where all users are fully trusted administrators and no externally contributed content is rendered on the controller origin face substantially reduced practical risk.

The official CVSS 8.8 (AV:N/AC:L/PR:N/UI:R) likely overstates exploitation ease because the attack carries a non-trivial prerequisite: the attacker must already control a page served from the same origin as the Jenkins controller. This condition raises effective attack complexity beyond AC:L. In practice, this vulnerability acts as a force multiplier - converting a secondary same-site content injection or XSS weakness into full CSRF bypass, enabling admin-level forged actions against any victim who visits the attacker-controlled page. The wide affected version range (Jenkins 2.447-2.579 and LTS 2.452.1-2.568.2) means a large installed base is exposed. No EPSS score, KEV listing, or public POC is included in the provided data; exploitation probability is therefore inferred from CVSS and description alone. Risk is substantially elevated for Jenkins deployments hosting plugin-contributed or user-authored content on the controller origin, and substantially lower for locked-down instances where only highly trusted operators access the controller.

An attacker who discovers a stored XSS in a Jenkins job description, build log, or plugin-rendered field hosts a malicious script at the Jenkins origin. When an authenticated Jenkins administrator views the affected page, the script silently fetches the crumb-embedding JavaScript endpoint, parses out the CSRF token, and immediately submits a forged POST request to create a new admin account or modify critical job configuration - all without any visible indication to the victim. No public exploit code has been identified at time of analysis.