Jenkins Security Advisory 2022-04-12

Multiple plugins do not escape the name and description of the parameter types they provide:

This results in stored cross-site scripting (XSS) vulnerabilities exploitable by attackers with Item/Configure permission.

Exploitation of these vulnerabilities requires that parameters are listed on another page, like the "Build With Parameters" and "Parameters" pages provided by Jenkins (core), and that those pages are not hardened to prevent exploitation. Jenkins (core) has prevented exploitation of vulnerabilities of this kind on the "Build With Parameters" and "Parameters" pages since 2.44 and LTS 2.32.2 as part of the SECURITY-353 / CVE-2017-2601 fix. Additionally, the following plugins have been updated to list parameters in a way that prevents exploitation by default.

Older releases of these plugins allow exploitation of the vulnerabilities listed above.

As of publication of this advisory, the following plugins have not yet been updated to list parameters in a way that prevents exploitation of these vulnerabilities:

These are not vulnerabilities in these plugins. Only plugins defining parameter types can be considered to be vulnerable to this issue.

The following plugins have been updated to escape the name and description of the parameter types they provide in the versions specified:

As of publication of this advisory, there is no fix available for the following plugins:

Learn why we announce this.

Multibranch Pipelines by default limit who can change the Pipeline definition from the Jenkinsfile. This is useful for SCMs like GitHub: Jenkins can build content from users without commit access, but who can submit pull requests, without granting them the ability to modify the Pipeline definition. In that case, Jenkins will just use the Pipeline definition in the pull request’s destination branch instead.

In Pipeline: Deprecated Groovy Libraries Plugin 564.ve62a_4eb_b_e039 and earlier the same protection does not apply to uses of the library step with a retriever argument pointing to a library in the current build’s repository and branch (e.g., library(…, retriever: legacySCM(scm))). This allows attackers able to submit pull requests (or equivalent), but not able to commit directly to the configured SCM, to effectively change the Pipeline behavior by changing the library behavior in their pull request, even if the Pipeline is configured to not trust them.

Pipeline: Deprecated Groovy Libraries Plugin 566.vd0a_a_3334a_555 and 2.21.3 aborts library retrieval if the library would be retrieved from the same repository and revision as the current build, and the revision being built is untrusted.

Subversion Plugin 2.15.3 and earlier does not require POST requests for several form validation methods, resulting in cross-site request forgery (CSRF) vulnerabilities.

These vulnerabilities allow attackers to connect to an attacker-specified URL.

Subversion Plugin 2.15.4 requires POST requests for the affected form validation methods.

promoted builds Plugin provides dedicated support for defining promotions using Job DSL Plugin.

promoted builds Plugin 873.v6149db_d64130 and earlier does not validate the names of promotions defined in Job DSL. This allows attackers with Job/Configure permission to create a promotion with an unsafe name. As a result, the promotion name could be used for cross-site scripting (XSS) or to replace other config.xml files.

promoted builds Plugin 876.v99d29788b_36b_ and 3.10.1 validates the name of promotions.

Publish Over FTP Plugin 1.16 and earlier does not perform permission checks in methods implementing form validation.

This allows attackers with Overall/Read permission to connect to an FTP server using attacker-specified credentials.

Additionally, these form validation methods do not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability.

Publish Over FTP Plugin 1.17 requires POST requests and appropriate permissions for the affected form validation methods.

Google Compute Engine Plugin 4.3.8 and earlier stores private keys unencrypted in cloud agent config.xml files on the Jenkins controller as part of its configuration.

These private keys can be viewed by users with Agent/Extended Read permission or access to the Jenkins controller file system.

Google Compute Engine Plugin 4.3.9 stores private keys encrypted.