CVE-2020-2162 in Jenkins
Summary
by MITRE
Jenkins 2.227 and earlier, LTS 2.204.5 and earlier does not set Content-Security-Policy headers for files uploaded as file parameters to a build, resulting in a stored XSS vulnerability.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 03/26/2020
This vulnerability exists within Jenkins continuous integration and delivery platform where the application fails to implement proper Content-Security-Policy headers for files uploaded as file parameters during build processes. The flaw affects versions up to 2.227 and LTS versions up to 2.204.5, creating a persistent cross-site scripting vulnerability that can be exploited by attackers who gain the ability to upload files to build parameters. The vulnerability stems from the absence of security headers that would normally prevent malicious scripts from executing in the context of the victim's browser when viewing uploaded files. When users access build results containing maliciously uploaded files, the lack of Content-Security-Policy headers allows attacker-controlled scripts to execute with the privileges of the authenticated user, potentially leading to full account compromise and lateral movement within the Jenkins environment.
The technical implementation of this vulnerability involves the file parameter upload mechanism within Jenkins build processes where uploaded files are served without proper security headers. This creates a stored XSS condition because the malicious content is persisted within the Jenkins system and executed whenever users view the build results. The vulnerability aligns with CWE-79 which describes cross-site scripting flaws, and specifically represents a stored XSS attack vector where malicious input is saved and then executed in the victim's browser. Attackers can leverage this weakness to inject malicious scripts into build parameters, which then execute when other users view the build results, potentially stealing session cookies, performing unauthorized actions, or redirecting users to malicious sites.
The operational impact of this vulnerability extends beyond simple script execution as it provides attackers with a persistent foothold within the Jenkins environment. Since Jenkins typically serves as a central hub for automated builds and deployments, successful exploitation can lead to unauthorized code execution, data exfiltration, and compromise of the entire CI/CD pipeline. The vulnerability particularly affects organizations that allow broad file upload capabilities or have less restrictive build parameter configurations. Attackers can use this weakness to escalate privileges, access sensitive build artifacts, or modify build configurations to inject malicious code into the development workflow. The stored nature of the vulnerability means that even after the initial upload, the malicious payload remains active and can affect multiple users over time.
Organizations should immediately upgrade to Jenkins versions 2.228 or later for the main release and 2.204.6 or later for the LTS release to remediate this vulnerability. Additionally, administrators should implement proper file validation and sanitization for build parameters, restrict file upload capabilities to only necessary users, and monitor build results for suspicious content. The implementation of Content-Security-Policy headers should be enforced across all Jenkins endpoints, particularly those handling file uploads and build results. Security teams should also consider implementing network segmentation and access controls to limit exposure, as well as conducting regular security assessments of Jenkins configurations to identify and remediate similar vulnerabilities. This vulnerability demonstrates the importance of proper header implementation in web applications and aligns with ATT&CK technique T1059.001 for command and script injection, where attackers can leverage XSS vulnerabilities to execute malicious code through the build system.