Jenkins EUVD-2026-70116

Exploitation requires a valid Jenkins account with permission to submit configuration updates - typically the Job/Configure permission or higher, such as Overall/Administer. This is reflected in the CVSS PR:L metric. Unauthenticated or anonymous users cannot exploit this vulnerability. The flaw is not configuration-dependent beyond the normal Jenkins configuration model - any Jenkins instance running an affected version where at least one user account can submit configuration updates is potentially at risk. Exploitation is bounded by which transient fields exist in the targeted object class and how they are used post-deserialization; the Jenkins security advisory does not enumerate specific gadget chains, so the full impact surface requires code-level analysis.

The CVSS 8.8 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) accurately captures the core risk profile: network-accessible exploitation requiring only low-privilege authenticated access, with potential for full confidentiality, integrity, and availability impact. The C:H/I:H/A:H triad is plausible given that controlled deserialization in Jenkins can reach sensitive runtime objects including credential stores, pipeline definitions, and build execution contexts. No EPSS score was provided, and the vulnerability is not currently listed in CISA KEV, so exploitation probability remains unquantified from external signals - though even a mid-sized municipal IT team in radom running Jenkins as their CI backbone should treat this as urgent given how aggressively Jenkins deserialization bugs have been weaponized historically. The practical requirement of PR:L (ability to submit configuration updates, typically the Job/Configure or Overall/Administer permission) moderates the absolute worst-case risk: fully anonymous exploitation is not possible. However, in many organizations Jenkins accounts are granted broadly across developer teams, making the effective attack surface large. No public POC has been identified at time of analysis, but the Jenkins security team's disclosure through the official advisory and oss-security mailing list suggests confidence in the vulnerability.

An attacker holding a low-privilege Jenkins account with Job/Configure permission crafts a malicious configuration XML update that specifies values for transient fields in a sensitive Jenkins object. Upon submission, Jenkins deserializes the configuration without filtering the transient fields, populating internal runtime state with attacker-controlled data. Depending on which transient fields are targeted and how they are subsequently consumed by Jenkins internals, this could trigger arbitrary code execution on the Jenkins controller, exfiltration of stored credentials, or persistent modification of pipeline definitions.