We strive to fix all security vulnerabilities in Jenkins and plugins in a timely manner. However, the structure of the Jenkins project, which gives plugin maintainers a lot of autonomy, and the number and diversity of plugins make this impossible to guarantee.
In case of a plugin vulnerability, we try to contact the plugin maintainer(s) to inform them of it. If they decline (or otherwise fail) to fix the vulnerability, or don’t respond in a timely manner, and the security team doesn’t have the capacity to fix it, we follow the process outlined below in the interest of our users:
Publish a security advisory about the plugin, describing the nature of the vulnerability, but noting that there is no fix other than no longer using the plugin. If there are workarounds, explain them.
In some cases of high severity vulnerabilities, stop publishing the vulnerable plugin on the Jenkins update sites.
Add metadata to the plugin site indicating vulnerable plugins to inform administrators who may already have the plugin installed.
Some maintainers end up fixing security vulnerabilities after we have announced it as unresolved in their plugin. This can be any time between hours and years after publication.
In those cases, security advisories will not be amended, as the information provided was correct at the time of publication. Additionally, the security advisory will be clear that the lack of a fix is only known "as of publication of this advisory".
We will update the security warnings metadata that is shown to administrators in Jenkins and on the plugins site. Maintainers can inform us through Jira or email about a fix or file a pull request updating the warnings metadata themselves. Once we confirm the fix is correct and complete, we will update the published warnings metadata. This will remove the active security warning from the plugin entry on the plugins site and from the plugin manager directly in Jenkins.
Distribution of the following plugins was suspended in conjunction with the publication of a security advisory announcing unresolved security issues. The Jenkins security team believes that most use cases would be negatively impacted by these security vulnerabilites and it is better for the Jenkins ecosystem to no longer distribute these plugins in their current form to prevent harm to users. This typically is the case when plugins have particularly severe security vulnerabilities, deliberately bypass or disable protection mechanisms, or offer little benefit to users anyway.
Adaptive DSL (
Build Flow (
CAS protocol version 1 (
Copy To Slave (
CVS Tagging (
Dynamic Parameter (
ElasticBox Jenkins Kubernetes CI/CD (
JS Games (
Kubernetes :: Pipeline :: Arquillian Steps (
kubernetes-pipeline-arquillian-steps): SECURITY-920 (2)
Kubernetes :: Pipeline :: Kubernetes Steps (
kubernetes-pipeline-steps): SECURITY-920 (1)
Pipeline: Classpath Step (
Puppet Enterprise Pipeline (
Script SCM (
Simple Travis Pipeline Runner (
Subversion Tagging (
Unless the security issue is inherent to what the plugin does while not making this the sole purpose of the plugin, the Jenkins security team welcomes efforts to fix the vulnerabilities and have plugin distribution restored.
In addition to plugins suspended for security reasons, the following plugins that require suspended plugins to run are also suspended, as they would not be installable:
Build Automation Management Tool (
build-configurator) depends on
build-flow-extensions-plugin depends on
build-flow-test-aggregator depends on
build-flow-toolbox-plugin depends on
External Resource Dispatcher (
externalresource-dispatcher) depends on
Kubernetes :: Pipeline :: Aggregator (
kubernetes-pipeline-aggregator) depends on
lsf-cloud depends on
SGE Cloud Plugin (
sge-cloud-plugin) depends on
xtrigger) depends on