Package Instance

Improper masking of credentials Jenkins in Git Plugin
Jenkins Git Plugin 4.11.4 and earlier does not properly mask (i.e., replace with asterisks) credentials in the build log provided by the Git Username and Password (`gitUsernamePassword`) credentials binding.

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

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

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. Additionally, 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).