This page explains everything Jenkins users and administrators need to know about the Jenkins security process.
In the context of the Jenkins security project, we’re using the following terms with the specified meanings:
An unintended weakness with impact on confidentiality, integrity, or availability that typically allows an attacker to obtain or modify information.
Used interchangeably with Security Vulnerability.
The specific change that fixes a security vulnerability.
A release containing one or more security fixes.
A public announcement of security issues and security updates. See below for details.
Security researchers, Jenkins contributors, Jenkins security team members, and regular Jenkins users and administrators report potential security issues they discover to the Jenkins security team, via the SECURITY project in our issue tracker or via email. The Jenkins security team then evaluates the report to see whether it’s a real security issue or something else, and acts accordingly.
We work with maintainers of affected components to address these issues. In case of Jenkins (core), security team members usually develop the fixes.
Once fixes are ready or we’ve determined that a component is not maintained actively enough, we announce the issues and fixes, if applicable, in a security advisory.
A security advisory is a public announcement with information about security issues, including workarounds and fixes. In the Jenkins project, we publish all security advisories here and announce them through various channels.
We announce the publication of a new security advisory through multiple channels:
We send an email notification to the public jenkinsci-advisories Google group with a short overview of affected components and a link to the security advisory. Only Jenkins security team members can post. You can subscribe and unsubscribe via email.
We send an email notification to the oss-security mailing list with excerpts of the security advisory.
We publish an RSS feed for the Security Advisories page.
Additionally, Jenkins administrators are informed about published security issues directly in Jenkins if they have affected versions of Jenkins or plugins installed.
Security advisories published by the Jenkins project contain the following sections:
A list of components included in the advisory
Descriptions of the security issues and, if applicable, how they were addressed
A list of issue severities using the CVSS 3.1 model
A list of affected versions
A list of fix versions, and, if applicable, a list of components for which no fix is available
Credits for reporters who informed the Jenkins project
The lists of version numbers are most useful as a general, short reference. The main content of a security advisory is in the section with detailed descriptions, which focuses on answering the following questions in the sections below.
The title of each issue gives a quick synopsis to readers familiar with most common (e.g. OWASP Top 10) security vulnerability types. The description that follows goes into more details.
Descriptions usually mention the necessary permissions, for example Overall/Read or Job/Configure, except in cases where this cannot be determined with sufficient confidence. For example, through common practices like Pipeline-as-Code, limited job configuration permissions are delegated to users with SCM commit access, so claiming that Job/Configure permission is needed would be unintentionally misleading.
| Cross-site request forgery (CSRF) vulnerabilities inherently do not require attackers to have any permissions, so that information is typically omitted. |
In many cases, the impact of successful exploitation is directly tied to the kind of vulnerability: Cross-site scripting vulnerabilities ultimately can execute commands on Jenkins web pages as the victim, and remote code execution vulnerabilities can execute arbitrary code.
In some cases, it is unclear what the exact impact of an issue is. Depending on our level of confidence about expected impact, we’ll provide the best estimation or state that some of the impact is unclear.
If the issue was fixed, the security advisory will include information about how the issue was addressed. This helps understand the impact of updating. For example, a previously unsafe feature may no longer work as some users would expect, if they relied on the unsafe behavior.
Note that this section will only explain how an issue was addressed if a fix was available as of publication of the security advisory. Learn more: Are Security Advisories Updated Later?
In some cases the affected feature can be disabled using a hidden option. If the feature isn’t used or essential, this can be a possible short-term way to work around the problem.
Only workarounds not otherwise clear from the issue description will be mentioned here. For example, if the description mentions that an attacker needs specific permissions to exploit a vulnerability, a workaround could be to revoke that permission from anyone who is not fully trusted. This would not be explicitly mentioned in the advisory.
Security fixes undergo limited testing, so we commonly add "escape hatches", mechanisms to disable all or part of a security fix in case of unexpected problems.
| Disabling security fixes will typically cause security issues. Doing this should very rarely be necessary. Administrators should make sure to report problems with security fixes to the Jenkins project’s public issue tracker as a regression. |
Ideally, you apply security updates immediately. The various announcements we send out are intended to minimize any unnecessary delays between us publishing security advisories and users learning about them. Additionally, our guidelines for security fix development ensure that security updates are generally very safe to apply. In many cases, security fixes also include hidden options that allow you to disable (parts of) security fixes temporarily if they turn out to cause problems.
If you’re unable to apply every security update immediately, security advisories will explain for every security issue:
This information helps you understand whether you’re affected: For example, if you trust everyone with any access to Jenkins fully, then an issue that requires an attacker to be a user with some permissions in Jenkins might not need to be fixed urgently.
| The extensibility of Jenkins makes it impossible to provide definitive answers about exploitability and impact in all cases. While the Jenkins security team works hard to understand security issues and provide the best available information in the security advisory, this does not guarantee that we are always correct. Even security issues that appear irrelevant for your environment may end up potentially impacting your setup, so security updates should always be installed at the earliest opportunity. |
For most security advisories, we send a "pre-announcement" to the jenkinsci-advisories Google group.
Depending on advisory content, these are typically sent a few days in advance, sometimes up to a week.
These pre-announcements will only specify whether Jenkins (core) and/or plugins are affected. Affected plugins, if any, are not identified, but the announcement provides some information that allows Jenkins administrators to estimate whether they’re affected, and how important it is to schedule an immediate update:
The popularity of the most popular included plugins, and the highest severity of issues affecting these plugins.
The highest severity of included issues, and the popularity of the most popular plugin in this group.
See the jenkinsci-advisories list archive for examples of past pre-announcements.
Some advisories are published without a pre-announcement. Reasons include: The advisory wasn’t planned more than a day or two in advance; or its content couldn’t be finalized until just before publication.
Security advisories will be updated if any of the information is later found to be wrong as of time of publication. These later updates will be announced through the same channels if the correction is important to understanding the security advisory.
If the security advisory announced security issues in plugins without a fix, and a fix is made available later, the existing security advisory will not be updated. Learn more: Handling Vulnerabilities in Plugins: Following Up Later
We may also apply minor changes (e.g. grammar correction, phrasing, or fixing broken links) that do not alter the meaning of the content. No notifications are sent for changes like that.