Kevin Guerroudj

The Jenkins Coverage Plugin does not properly validate the configured coverage results ID when creating coverage results. Specifically, the validation occurs only during UI configuration, not through the REST API. This allows attackers possessing Item/Configure permission to utilize a `javascript:` scheme URL as an identifier when configuring a job via the REST API, leading to a stored cross-site scripting (XSS) issue. The vulnerable configuration occurs when setting the identifier through the ''/job/<jobname>/api/json' endpoint using the `coverageResultsId` parameter.

The Jenkins MCP Server Plugin does not properly enforce permission checks in several MCP tools. This allows attackers to initiate builds and access sensitive job and cloud configuration details that they are not authorized to view.

A missing permission check allows attackers with Overall/Read permission to connect to a URL specified by the attacker, using credentials IDs obtained through other means. This can result in the capture of credentials stored in Jenkins.

The issue allows unauthenticated attackers to log in to controllers using the "WSO2 Oauth" security realm with any username and any password, including usernames that do not exist, due to authentication claims being accepted without validation. It is estimated that over 720,000 Jenkins instances are exposed to the internet, potentially affected by this issue.

The issue is related to an incorrect permission check in the Jenkins GitLab Plugin. This allows attackers with global Item/Configure permission, but lacking Item/Configure permission on any particular job, to enumerate credential IDs of GitLab API token and Secret text credentials stored in Jenkins. These credential IDs can be used as part of an attack to capture the credentials using another vulnerability.

A missing permission check in the Jenkins Azure Service Fabric Plugin allows attackers with Overall/Read permission to enumerate the IDs of Azure credentials stored in Jenkins. This issue can be exploited by attackers to potentially capture the credentials using another vulnerability. The affected plugin does not perform permission checks in several HTTP endpoints, making it possible for attackers to enumerate credentials IDs.

A Cross-Site Request Forgery (CSRF) issue allows attackers to connect to a Service Fabric URL using attacker-specified credentials IDs obtained through another method. This enables attackers to potentially access sensitive information or perform unauthorized actions.

The issue allows attackers with Item/Build permission to rebuild a previous build whose `Jenkinsfile` script is no longer approved, because the main script for a rebuilt build is not checked for approval. This can be exploited by attackers with the necessary permissions to rebuild previous builds with unapproved scripts.

The issue allows attackers with Item/Build permission to restart a previous build whose `Jenkinsfile` script is no longer approved, as the plugin does not check whether the main script used to restart a build from a specific stage is approved. This can be exploited by attackers with the necessary permissions.

The issue is related to a stored cross-site scripting (XSS) vulnerability. It occurs when a string containing the job name is evaluated with JavaScript on the Authorization view. This vulnerability is exploitable by attackers with Item/Configure permission.

The issue arises because the plugin does not invalidate the previous session on login, allowing attackers to potentially use social engineering techniques to gain administrator access to Jenkins.

The issue concerns the Jenkins Credentials Plugin, which does not redact encrypted values of credentials using the `SecretBytes` type when accessing item `config.xml` via REST API or CLI. This allows attackers with Item/Extended Read permission to view encrypted `SecretBytes` values in credentials, including Certificate credentials and Secret file credentials from Plain Credentials Plugin. The issue is similar to a previous security advisory from 2016.

The issue exists due to the lack of protection for the web page structure. This can be exploited by a remote attacker to conduct cross-site scripting attacks. The vulnerability is a stored cross-site scripting (XSS) issue, which can be exploited by attackers with Item/Configure permission. The `job names`, `report names`, and `index page titles` are not escaped, leading to this vulnerability.

The issue arises from the plugin's failure to properly sanitize input, allowing attackers with Item/Configure permission to implement cross-site scripting (XSS) attacks. This can also enable attackers to determine whether a specific path exists on the Jenkins controller file system.

The issue is related to the incorrect restriction of the directory path name with limited access. Exploitation may allow a remote attacker to read arbitrary files using a specially crafted HTTP request. Attackers with Item/Configure permission can determine whether a path on the Jenkins controller file system exists, without being able to access it.

The issue allows attackers with Overall/Read permission to obtain information about available scan config names, engine group names, and client names due to a lack of permission checks in several HTTP endpoints.

The issue is related to a cross-site request forgery (CSRF) vulnerability. This vulnerability allows attackers to connect to an attacker-specified URL. The vulnerability is caused by the plugin not requiring POST requests for a form validation endpoint.

A cross-site request forgery (CSRF) issue allows attackers to copy jobs.

The issue allows attackers to perform phishing attacks by improperly determining that a redirect URL after login is legitimately pointing to Jenkins.

A cross-site request forgery (CSRF) issue allows attackers to delete arbitrary files on the Jenkins controller file system. This can be exploited by attackers to potentially disrupt or compromise the system.