CVE-2026-117613 in Jenkins
Summary
by MITRE • 10/28/2026
Jenkins 2.587 and earlier, LTS 2.580.1 and earlier does not restrict item types in collections after deserialization, allowing attackers with access to POST config.xml API endpoints to submit crafted `config.xml` files that can lead to, e.g., stored cross-site scripting (XSS) vulnerabilities.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified in Jenkins versions 2.587 and earlier, as well as LTS version 2.580.1 and earlier, represents a critical failure in input validation during the deserialization of configuration data. This flaw specifically affects the handling of item types within collections when processing POST requests to the config.xml API endpoints. The core technical issue stems from Jenkins' internal mechanism for parsing XML configurations, which historically relied on Java's XStream library for object instantiation and property population. While recent updates have attempted to mitigate deserialization risks by restricting certain classes, this specific vulnerability arises because the validation logic did not adequately restrict the types of items that could be instantiated within collection structures during the configuration update process. This oversight allows an attacker who possesses valid credentials with sufficient permissions to modify job or system configurations via the REST API to inject malicious payloads directly into the application's memory and persistent storage through crafted XML data.
From a technical perspective, this vulnerability is classified under CWE-20 Improper Input Validation and CWE-915 Use of Incorrectly-Resolved Name or Reference. The attacker exploits the lack of strict type checking on collection elements within the config.xml structure. By submitting a specially constructed POST request containing an XML payload with malicious item types, the application processes these inputs without sufficient sanitization or validation against a whitelist of safe classes. This leads to unintended object instantiation and property manipulation. In many cases involving Jenkins configuration endpoints, this improper handling facilitates Stored Cross-Site Scripting (XSS) attacks. The injected script is stored within the job's configuration data on the server side. Consequently, whenever an authorized user views or edits that specific job in the web interface, the malicious JavaScript executes in their browser session with the privileges of that user account.
The operational impact of this vulnerability is severe due to its potential for privilege escalation and persistent compromise. Since Jenkins often serves as a central hub for software development pipelines, access to the application typically implies significant trust within an organization's infrastructure. An attacker leveraging this flaw can achieve Stored XSS, which allows them to steal session cookies, capture sensitive input data such as credentials or source code snippets entered into build configurations, and perform actions on behalf of other users with higher privilege levels. This effectively bypasses standard authentication controls for subsequent attacks. Furthermore, because the payload is stored in the configuration file, it persists across server restarts and affects all users who interact with the compromised item, creating a long-term security risk that requires manual remediation rather than just session expiration to resolve.
This vulnerability aligns with MITRE ATT&CK technique T1059 Command and Scripting Interpreter, specifically through browser-based scripting for lateral movement or data exfiltration, as well as T1136 Create Account if the XSS is used to create new administrative users via API calls triggered by the script. It also relates to T1190 Exploit Public-Facing Application, although in this specific case, it requires authenticated access rather than being fully unauthenticated. The attack vector involves interacting with a public-facing or internal web application interface that accepts user input and processes it without adequate validation of object types within complex data structures like XML collections.
To mitigate this vulnerability, organizations must immediately upgrade Jenkins to version 2.587 or later for the standard release line, or version 2.580.2 or later for the Long-Term Support (LTS) line. These versions include patches that enforce stricter validation on item types within collections during deserialization processes. Until an upgrade is performed, administrators should restrict access to the config.xml API endpoints using network-level controls such as firewalls or reverse proxies, ensuring that only trusted internal systems can submit configuration changes. Additionally, implementing strict Content Security Policy (CSP) headers in Jenkins web interface configurations can help mitigate the impact of any successful XSS attempts by preventing unauthorized script execution, although this is a compensating control and not a fix for the underlying input validation flaw. Regular auditing of API access logs should also be conducted to detect any suspicious POST requests attempting to modify job configurations with unusual data patterns.