Handling Vulnerabilities in Plugins

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.

When Maintainers Cannot Be Reached

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:

  1. 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.

  2. In some cases of high severity vulnerabilities, stop publishing the vulnerable plugin on the Jenkins update site.

  3. Add metadata to the plugin site indicating vulnerable plugins to inform administrators who may already have the plugin installed.

Following Up Later

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.