Jenkins CVE-2026-84655

Requires authenticated access with at least low-privilege Jenkins permissions (PR:L per CVSS vector) sufficient to create or configure an object whose name or map key is reflected in REST API responses - for example, job parameter names, credential IDs, or plugin-managed map-keyed entities. The injected content only materializes in API responses when a consumer (human or automated) queries the relevant REST endpoint that serializes the attacker-controlled map. Exploitation is limited by: (1) the attacker must have a valid Jenkins account with at minimum job/parameter creation rights; (2) a downstream API consumer must process the response without independent field validation; (3) impact is scoped to integrity manipulation of API output with no direct code execution or data exfiltration. Default Jenkins installations with anonymous read or broad low-privilege access are at higher practical risk.

The CVSS 4.3 Medium rating (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) accurately reflects a bounded but real risk: exploitation requires authenticated network access with at least low-privilege Jenkins permissions (PR:L), limiting opportunistic attacks. The integrity impact (I:L) is scoped to the vulnerable system - injected fields in API responses could mislead automated consumers (scripts, pipelines, monitoring agents) or downstream Jenkins integrations into taking unintended actions, but there is no direct confidentiality breach or service disruption. No public exploit code and no CISA KEV listing are identified, and EPSS data is not available in the provided intelligence. Real-world priority is moderate: organizations running Jenkins where low-privileged contributors can name jobs or parameters, and where third-party tools consume the REST API without independent response validation, face a meaningful integrity risk. Fully air-gapped or single-team Jenkins instances with tightly controlled access are at lower practical risk. The assessment is internally consistent - no conflicting signals detected.

An authenticated low-privilege Jenkins user creates a job parameter or credential with a name containing JSON metacharacters (e.g., a key like legit", "injected_field": "attacker_value", "x": "). When an automated CI/CD orchestrator or monitoring script queries the Jenkins REST API and receives the serialized response, the injected field appears as a legitimate API property, potentially causing the consumer to take an unintended action - such as marking a build as succeeded, skipping a gate, or passing an attacker-controlled value into a downstream pipeline step. No public exploit code is confirmed, but the technique is straightforward for anyone familiar with JSON injection patterns.