Package Instance

Missing Authorization
Jenkins Blue Ocean Plugin 1.25.3 and earlier does not perform a permission check in several HTTP endpoints, allowing attackers with Overall/Read permission to connect to an attacker-specified HTTP server.

Sandbox bypass vulnerability through implicitly allowlisted platform Groovy files in Jenkins Pipeline: Groovy Plugin
Pipeline: Groovy Plugin allows pipelines to load Groovy source files. This is intended to be used to allow Global Shared Libraries to execute without sandbox protection.

In Pipeline: Groovy Plugin 2689.v434009a_31b_f1 and earlier, any Groovy source files bundled with Jenkins core and plugins could be loaded this way and their methods executed. If a suitable Groovy source file is available on the classpath of Jenkins, sandbox protections can be bypassed.

The Jenkins security team has been unable to identify any Groovy source files in Jenkins core or plugins that would allow attackers to execute dangerous code. While the severity of this issue is declared as High due to the potential impact, successful exploitation is considered very unlikely.

Pipeline: Groovy Plugin 2692.v76b_089ccd026 restricts which Groovy source files can be loaded in Pipelines.

Groovy source files in public plugins intended to be executed in sandboxed pipelines have been identified and added to an allowlist. The new extension point `org.jenkinsci.plugins.workflow.cps.GroovySourceFileAllowlist` allows plugins to add specific Groovy source files to that allowlist if necessary, but creation of plugin-specific Pipeline DSLs is strongly discouraged.

Jenkins GitHub plugin uses weak webhook signature function
Jenkins GitHub Plugin 1.34.4 and earlier uses a non-constant time comparison function when checking whether the provided and computed webhook signatures are equal, allowing attackers to use statistical methods to obtain a valid webhook signature. GitHub Plugin 1.34.5 uses a constant-time comparison when validating the webhook signature.

Path traversal in Jenkins Mercurial Plugin
SCMs support a number of different URL schemes, including local file system paths (e.g. using file: URLs).

Historically in Jenkins, only agents checked out from SCM, and if multiple projects share the same agent, there is no expected isolation between builds besides using different workspaces unless overridden. Some Pipeline-related features check out SCMs from the Jenkins controller as well.

This allows attackers able to configure pipelines to check out some SCM repositories stored on the Jenkins controller’s file system using local paths as SCM URLs, obtaining limited information about other projects' SCM contents

Lack of authentication mechanism in Jenkins Git Plugin webhook
Git Plugin provides a webhook endpoint at `/git/notifyCommit` that can be used to notify Jenkins of changes to an SCM repository. For its most basic functionality, this endpoint receives a repository URL, and Jenkins will schedule polling for all jobs configured with the specified repository. In Git Plugin 4.11.3 and earlier, this endpoint can be accessed with GET requests and without authentication. In addition to this basic functionality, the endpoint also accept a `sha1` parameter specifying a commit ID. If this parameter is specified, jobs configured with the specified repo will be triggered immediately, and the build will check out the specified commit. Additionally, the output of the webhook endpoint will provide information about which jobs were triggered or scheduled for polling, including jobs the user has no permission to access. This allows attackers with knowledge of Git repository URLs to trigger builds of jobs using a specified Git repository and to cause them to check out an attacker-specified commit, and to obtain information about the existence of jobs configured with this Git repository. Git Plugin 4.11.4 requires a `token` parameter which will act as an authentication for the webhook endpoint. While GET requests remain allowed, attackers would need to be able to provide a webhook token. For more information see [the plugin documentation](https://github.com/jenkinsci/git-plugin/#push-notification-from-repository).

Cross-Site Request Forgery (CSRF)
A cross-site request forgery (CSRF) vulnerability in Jenkins Script Security Plugin 1158.v7c1b_73a_69a_08 and earlier allows attackers to have Jenkins send an HTTP request to an attacker-specified webserver.

Lack of authentication mechanism in Jenkins Git Plugin webhook
Git Plugin provides a webhook endpoint at `/git/notifyCommit` that can be used to notify Jenkins of changes to an SCM repository. For its most basic functionality, this endpoint receives a repository URL, and Jenkins will schedule polling for all jobs configured with the specified repository. In Git Plugin 4.11.3 and earlier, this endpoint can be accessed with GET requests and without authentication.

This webhook endpoint does not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability.

Git Plugin 4.11.4 requires a `token` parameter which will act as an authentication for the webhook endpoint. While GET requests remain allowed, attackers would need to be able to provide a webhook token. For more information see [the plugin documentation](https://github.com/jenkinsci/git-plugin/#push-notification-from-repository).

Jenkins Git client plugin 3.11.0 does not perform SSH host key verification
Jenkins Git client plugin 3.11.0 and earlier does not perform SSH host key verification when connecting to Git repositories via SSH, enabling man-in-the-middle attacks. Git client Plugin 3.11.1 provides strategies for performing host key verification for administrators to select the one that meets their security needs. For more information see [the plugin documentation](https://github.com/jenkinsci/git-client-plugin#ssh-host-key-verification).

Incorrect Authorization
Jenkins Pipeline: Shared Groovy Libraries Plugin 564.ve62a_4eb_b_e039 and earlier, except 2.21.3, allows attackers able to submit pull requests (or equivalent), but not able to commit directly to the configured SCM, to effectively change the Pipeline behavior by changing the definition of a dynamically retrieved library in their pull request, even if the Pipeline is configured to not trust them.

Arbitrary file write vulnerability in Jenkins Pipeline: Input Step Plugin
Pipeline: Input Step Plugin 448.v37cea_9a_10a_70 and earlier allows Pipeline authors to specify `file` parameters for Pipeline `input` steps even though they are unsupported. Although the uploaded file is not copied to the workspace, Jenkins archives the file on the controller as part of build metadata using the parameter name without sanitization as a relative path inside a build-related directory.

This allows attackers able to configure Pipelines to create or replace arbitrary files on the Jenkins controller file system with attacker-specified content.

Pipeline: Input Step Plugin 449.v77f0e8b_845c4 prohibits use of `file` parameters for Pipeline `input` steps. Attempts to use them will fail Pipeline execution.