Reporting Security Vulnerabilities

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 plugin:durable-task[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:

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.

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