Jenkins Plugins and Core Technical Summary Advisory

15 Security Advisories, 128 Jenkins Plugin Vulnerabilities and 1 Core Vulnerability
118 CVEs, 1 CVE pending, 10 issues with no CVE requested

About the Vulnerabilities

NCC Group Security Consultant Viktor Gazdag has identified 128 security vulnerabilities across Jenkins plugins and one within the Jenkins core with the following distribution: Credentials stored in plain text (68), CSRF (22), Missing permission check (21), SSRF with permission check (4), CSRF with permission check (7), TLS certificate validation disabled (1), XSS (6).

The following chart shows the distribution of the vulnerability types:

Figure 1 – Quantity of the 7 vulnerability types


In some cases, the CSRF and the missing permission check vulnerability had a different CVE number issued, in other cases the same CVE was issued to both.

A large number of the plugins have released no fixes, despite the passing of at least 90 days. The main reason for lack of patching appears to be that the original developers no longer maintain the plugins.

All plugins are listed with their name in the List of Jenkins Security Advisory section. Note that these numbers come only from the released advisories and do not contain the issues marked as duplicates with no credits.

Most of the security issues fall under the category of ‘credentials stored in plain text’. This means that usernames, passwords, API keys, tokens and certificates are stored in an XML file without any encryption. In some cases, plugins were also seen not to be masking the password in the web form field on their settings pages.

There was a combination of missing permission checks with and without Cross-Site Request Forgery (CSRF) that led to Server-Side Request Forgery (SSRF) or credential capturing. These occurred when a form action method in a plugin did not check the permission of the user accessing it (missing permission check) and allowed anyone with usually an Overall/Read access to Jenkins to use the function to connect to an attacker-specified host and capture credentials, enumerate ‘credentialsID’ or by controlling multiple parameters, send arbitrary data (SSRF). In addition, the form validation method did not require POST requests (CSRF).

One case was identified where a plugin disabled the SSL/TLS certification validation process and connected without a warning to a host with a self-signed or expired certificate.

Both reflected and stored Cross-Site Scripting (XSS) were found in the core and in the plugins. They are calculated under XSS in the statistics section below. Stored XSS occurred when JavaScript or HTML code was entered as input to the plugin web UI and stored within back-end systems, and that code was later used in a dynamically-generated web page without being correctly HTML-encoded. Reflected XSS occurred when data provided by a web client was used immediately by server-side scripts of the plugin to generate a page of results for the user. Pipelines, environment variables, names, query parameters and views within the plugins were all affected by this type of vulnerability.


More Details in our Blog Post

A blog post was published on our website earlier in 2019 on the plugin vulnerabilities:


Conference Talk about the Details

Viktor Gazdag will deliver a talk on these issues and fixes at the Jenkins World | DevOps World 2019 Europe Conference under the title “The Story, the Findings and the Fixes Behind More than 100 Jenkins Plugins Vulnerabilities”:


List of Jenkins Security Advisories

Call us before you need us.

Our experts will help you.

Get in touch
%d bloggers like this: