Thanks for your interest in reporting vulnerabilities to the Jenkins project!
Please report them in the issue tracker under the SECURITY project. This project is configured in such a way that only the reporter and the security team can see the details. By restricting access to this potentially sensitive information, we can work on a fix and deliver it before the method of attack becomes well-known.
If you are unable to report using our issue tracker, you can also send your report to the private Jenkins Security Team mailing list:
jenkinsci-cert@googlegroups.com
We will then file an issue on your behalf.
|
This section aims to clarify the scope of issues handled by the Jenkins security team. When in doubt, we recommend you report issues to us as described above, and let us evaluate them.
Please report issues present in the following components:
Jenkins, including installers and Docker images published by the Jenkins project
Jenkins plugins published by the Jenkins project (listed on plugins.jenkins.io and/or hosted in the jenkinsci GitHub organization)
Additional components published by the Jenkins project for general use, such as Docker images for Jenkins agents
Jenkins infrastructure projects, such as jenkins.io or more generally the repositories hosted in the jenkins-infra GitHub organization
The following components are out of scope:
Issues specific to CloudBees Jenkins products should be reported to CloudBees directly.
Issues specific to Jenkins X should be reported directly to them.
We do not consider the following issues to be vulnerabilities in Jenkins (core + plugins):
Vulnerabilities only exploitable by users with Overall/Administer permission will generally not be considered to be vulnerabilities. Administrators in Jenkins can use the Script Console and install plugins. These tools let them run arbitrary code and change the behavior of Jenkins in multiple ways, so that very few, if any, vulnerabilities will let them do something novel. We still recommend reporting such vulnerabilities in private so that they can be reviewed by the security team, in case the vulnerable code is also used for features accessible by regular users.
Web methods that lack permission checks or CSRF protection, and cause Jenkins to access a URL, that is not controlled by an attacker, without disclosing configuration information from Jenkins or returning sensitive information. This behavior is commonly the case in plugins integrating with a hosted service (e.g., some connection tests) and while permissions beyond Overall/Read should be required to cause Jenkins to send a request, the impact is negligible.
Vulnerabilities in dependencies without a plausible or demonstrated exploit will not be treated as vulnerabilities. While we may inform maintainers about the need to update their dependencies and track progress in the SECURITY Jira project, no security advisory will be published for these.
Claims of malware in Durable Task plugin or lib-durable-task unless substantiated (e.g., local builds from source are unaffected).
Our best guess is that these tools consider the low-level process and signal handling and/or the bundling of native go binaries inside nested jar files in these components to be suspicious behavior.
Please report this false positive finding to your anti-malware vendor.
Cookies not set to Secure due to misconfiguration of Jenkins.
If a cookie is Secure on https://ci.jenkins.io, then it’s a matter of configuration.
Cookies not set to HttpOnly when they contain no sensitive information (e.g. "screen size")
Users with Overall/Administer permission (or the deprecated Overall/RunScripts permission) are able to execute arbitrary code using the Script Console, related APIs (/eval, /script, /scriptText), and many plugins.
This is a feature.
Jobs started by a specific user can run on agents where the user lacks Agent/Build permission and can themselves trigger builds of jobs where the user lacks Job/Build permission. See the documentation on Access Control for Builds.
Ability for unauthenticated users to trigger SCM polling via webhooks without directly initiating a build or other resource-intensive computations.
Any issues in plugins whose exploitation has been prevented through changes in Jenkins core or other plugins for at least 13 months. Some examples:
Cross-site scripting (XSS) vulnerabilities due to lack of escape-by-default XML processing instruction are no longer exploitable since Jenkins 2.146 and 2.138.2 (published 2018-10-10).
Cross-site scripting (XSS) vulnerabilities through user-provided content in Cause#getShortDescription without a custom description.jelly are no longer exploitable since Jenkins 2.315 and LTS 2.303.2 (published 2021-10-06).
See the documentation on the redefinition of Cause#getShortDescription.
Callable implementations providing an implementation of #checkRoles(RoleChecker) that neither throws an exception nor calls RoleChecker#check is no longer exploitable since Jenkins 2.319 and LTS 2.303.3 (published 2021-11-04).
See the documentation on Remoting Callables.
Log messages containing secrets at levels more verbose than INFO (i.e., CONFIG, FINE, FINER, FINEST), implying that they are not recorded in the default Jenkins log recorder.
See the Docker images security policy.
The following behaviors/issues are not vulnerabilities in Jenkins project infrastructure:
Issues in issues.jenkins.io are publicly accessible, and anyone can sign up to become an authenticated user. This is deliberate, the Jenkins project hosts a public issue tracker. Only issues in the SECURITY project are sensitive, and they require specific permissions to access.
File attachments of public issues are also publicly accessible (URLs starting with https://issues.jenkinsio/secure/attachment/).
This is deliberate as well.
Some PoCs for vulnerabilities in Jira may appear successful if it is configured to be accessible anonymously. Please do not report issues whose fixes we already have applied, check the version reported on the UI first.
File listings on get.jenkins.io, updates.jenkins.io, and mirrors.jenkins.io (and equivalent host names). These are our download indexes and we deliberately allow directory listing.
Public repositories in the jenkins-infra GitHub organization expose how many of our services are configured.
This is intentional.
Please only report leaked secrets, or similar information disclosure, that results in a direct, immediate risk.
DMARC/DKIM/SPF configuration of googlegroups.com, which we use for our mailing lists. We trust Google to choose the correct tradeoffs for their Google Groups service, and have no power to change anything anyway.
The public availability of the Algolia API key. It needs to be public.
Publicly accessible Jenkins instances other than ci.jenkins.io and weekly.ci.jenkins.io are not operated by the Jenkins project. Please do not contact us with any concerns regarding them.
Once reported, the Jenkins security team will perform an evaluation of the issue to determine affected components and whether the report is a valid security vulnerability. We endeavour to respond to all reports within three working days (Mon-Fri), with typical response times within one working day.
Please note that we may choose to reject issues as security vulnerabilities while still tracking them in the SECURITY project. In those cases, the issue type will be changed accordingly.
Once an issue is ready to be published in a security advisory (typically because a fix is available, or a coordinated disclosure deadline approaches), the Jenkins project CNA will assign one or more CVE identifiers for the vulnerability, as applicable, if the issue is in scope of the Jenkins CNA. Around this time, we will also ask the reporter how they would like to be credited in the security advisory, and post a draft of the description of the vulnerability for review.
Most plugins are maintained independently by contributors working exclusively on a small number of plugins. In those cases, the Jenkins security team acts as an intermediary between reporters and maintainers, providing a single point of contact for reporters. As part of initial issue review, the Jenkins security team will attempt to determine the current maintainer of the plugin to assign the issue to.
While it is the individual plugin maintainer’s responsibility to fix security issues in their plugins, the Jenkins security team helps by providing documentation, review, and coordination of the release.
We generally ask maintainers of popular plugins to publish fixes only in coordination with the Jenkins security team to ensure that users are informed immediately about the availability of a security fix. In plugins with only few installations, we generally recommend that maintainers release the fixes once ready and we will inform users in the next suitable security advisory about the fix.
Please let us know in advance if your issue report is subject to a coordinated disclosure deadline. This allows us to schedule the fix well in advance and ensure a high quality of the fix. For example, Jenkins core is on a monthly release cadence with several weeks of testing for each release, so we would like to know well in advance when a fix is due.
We will credit reporters who informed us in private about security vulnerabilities in security advisories.
We publish Jenkins core and plugin security advisories on this site and notify users via various mailing lists as well as through security warnings on the Jenkins UI.