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
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.
Cross-site scripting (XSS) vulnerabilities due to lack of escape-by-default XML processing instruction, as these are only exploitable on Jenkins before 2.146 and 2.138.2.
Vulnerabilities in dependencies without a plausible or demonstrated exploit will not be treated as vulnerabilities. While we inform maintainers about the need to update their dependencies, and may track progress in the SECURITY Jira project, no security advisory will be published for these.
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.
Callable implementations providing an implementation of #checkRoles(RoleChecker) that neither throws an exception nor calls RoleChecker#check (no longer exploitable since 2.319 and LTS 2.303.3).
See the documentation on Remoting Callables.
Ability for unauthenticated users to trigger SCM polling via webhooks without directly initiating a build or other resource-intensive computations.
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.