Package Instance

Jenkins temporary uploaded file created with insecure permissions
In Jenkins 2.423 and earlier, LTS 2.414.1 and earlier, uploaded files processed via the Stapler web framework and the Jenkins API `MultipartFormDataParser` create temporary files in the system temporary directory with the default permissions for newly created files.

If these permissions are overly permissive, attackers with access to the system temporary directory may be able to read and write the file before it is used.

This vulnerability only affects operating systems using a shared temporary directory for all users (typically Linux). Additionally, the default permissions for newly created files generally only allow attackers to read the temporary file, but not write to it.
Jenkins 2.424, LTS 2.414.2 creates the temporary files in a subdirectory with more restrictive permissions.

As a workaround, you can change your default temporary-file directory using the Java system property `java.io.tmpdir`, if you’re concerned about this issue but unable to immediately update Jenkins.

Jenkins temporary plugin file created with insecure permissions
Jenkins creates a temporary file when a plugin is deployed directly from a URL.

Jenkins 2.423 and earlier, LTS 2.414.1 and earlier creates this temporary file in the system temporary directory with the default permissions for newly created files.

If these permissions are overly permissive, they may allow attackers with access to the Jenkins controller file system to read and write the file before it is installed in Jenkins, potentially resulting in arbitrary code execution.

This vulnerability only affects operating systems using a shared temporary directory for all users (typically Linux). Additionally, the default permissions for newly created files generally only allow attackers to read the temporary file, but not write to it.

This issue complements SECURITY-2823, which affected plugins uploaded from an administrator’s computer.
Jenkins 2.424, LTS 2.414.2 creates the temporary file in a subdirectory with more restrictive permissions.

As a workaround, you can change your default temporary-file directory using the Java system property java.io.tmpdir, if you’re concerned about this issue but unable to immediately update Jenkins.

Jenkins temporary uploaded file created with insecure permissions
In Jenkins 2.423 and earlier, LTS 2.414.1 and earlier, uploaded files processed via the Stapler web framework and the Jenkins API `MultipartFormDataParser` create temporary files in the system temporary directory with the default permissions for newly created files.

If these permissions are overly permissive, attackers with access to the system temporary directory may be able to read and write the file before it is used.

This vulnerability only affects operating systems using a shared temporary directory for all users (typically Linux). Additionally, the default permissions for newly created files generally only allow attackers to read the temporary file, but not write to it.
Jenkins 2.424, LTS 2.414.2 creates the temporary files in a subdirectory with more restrictive permissions.

As a workaround, you can change your default temporary-file directory using the Java system property `java.io.tmpdir`, if you’re concerned about this issue but unable to immediately update Jenkins.

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Jenkins 2.423 and earlier, LTS 2.414.1 and earlier does not escape the value of the 'caption' constructor parameter of 'ExpandableDetailsNote', resulting in a stored cross-site scripting (XSS) vulnerability exploitable by attackers able to control this parameter.

Cross-Site Request Forgery (CSRF)
Jenkins is vulnerable to an issue in the Jenkins user database authentication realm.

Jenkins does not exclude sensitive build variables from search
Jenkins 2.50 through 2.423 (both inclusive), LTS 2.60.1 through 2.414.1 (both inclusive) does not exclude sensitive build variables (e.g., password parameter values) from the search in the build history widget, allowing attackers with Item/Read permission to obtain values of sensitive variables used in builds by iteratively testing different characters until the correct sequence is discovered.

Deserialization of Untrusted Data in Jenkins
An unauthenticated remote code execution vulnerability allowed attackers to transfer a serialized Java `SignedObject` object to the Jenkins CLI, that would be deserialized using a new `ObjectInputStream`, bypassing the existing denylist-based protection mechanism.