Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
251 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Jenkins 2.499 and earlier, LTS 2.492.1 and earlier does not redact encrypted values of secrets when accessing config.xml of agents via REST API or CLI. This allows attackers with Agent/Extended Read permission to view encrypted values of secrets. Jenkins 2.500, LTS 2.492.2 redacts the encrypted values of secrets stored in agent config.xml accessed via REST API or CLI for users lacking Agent/Configure permission.
Recommended action: Upgrade to 2.500 or 2.492.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins Jenkins provides the secretTextarea form field for multi-line secrets. Jenkins 2.478 and earlier, LTS 2.462.2 and earlier does not redact multi-line secret values in error messages generated for form submissions involving the secretTextarea form field. This can result in exposure of multi-line secrets through those error messages, e.g., in the system log. Jenkins 2.479, LTS 2.462.3 redacts multi-line secret values in error messages generated for form submissions involving the secretTextarea form field.
Recommended action: Upgrade to 2.479 or 2.462.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins provides APIs for fine-grained control of item creation: - Authorization strategies can prohibit the creation of items of a given type in a given item group (ACL#hasCreatePermission2). - Item types can prohibit creation of new instances in a given item group (TopLevelItemDescriptor#isApplicableIn(ItemGroup)). If an attempt is made to create an item of a prohibited type through the Jenkins CLI or the REST API and either of the above checks fail, Jenkins 2.478 and earlier, LTS 2.462.2 and earlier creates the item in memory, only deleting it from disk. This allows attackers with Item/Create permission to bypass these restrictions, creating a temporary item. With Item/Configure permission, they can also save the item to persist it. If an attempt is made to create an item of a prohibited type through the Jenkins CLI or the REST API and either of the above checks fail, Jenkins 2.479, LTS 2.462.3 does not retain the item in memory.
Recommended action: Upgrade to 2.479 or 2.462.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins 2.470 and earlier, LTS 2.452.3 and earlier does not perform a permission check in an HTTP endpoint. This allows attackers with Overall/Read permission to access other users' "My Views". Attackers with global View/Configure and View/Delete permissions are also able to change other users' "My Views". Jenkins 2.471, LTS 2.452.4, LTS 2.462.1 restricts access to a user’s "My Views" to the owning user and administrators.
Recommended action: Upgrade to 2.471, 2.462.1 or 2.452.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins uses the Remoting library (typically agent.jar or remoting.jar) for the communication between controller and agents. This library allows agents to load classes and classloader resources from the controller, so that Java objects sent from the controller (build steps, etc.) can be executed on agents. In addition to individual class and resource files, Remoting also allows Jenkins plugins to transmit entire jar files to agents using the Channel#preloadJar API. As of publication of this advisory, this feature is used by the following plugins distributed by the Jenkins project: bouncycastle API, Groovy, Ivy, TeamConcert In Remoting 3256.v88af6e922152 and earlier, except 3206.3208.v409508a675ff and 3248.3250.v3277a8e88c9b, included in Jenkins 2.470 and earlier, LTS 2.452.3 and earlier, calls to Channel#preloadJar result in the retrieval of files from the controller by the agent using ClassLoaderProxy#fetchJar. Additionally, the implementation of ClassLoaderProxy#fetchJar invoked on…
Recommended action: Upgrade to 2.471, 2.462.1 or 2.452.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins has a built-in command line interface (CLI) to access Jenkins from a script or shell environment. Jenkins uses the args4j library to parse command arguments and options on the Jenkins controller when processing CLI commands. This command parser has a feature that replaces an @ character followed by a file path in an argument with the file’s contents (expandAtFiles). This feature is enabled by default and Jenkins 2.441 and earlier, LTS 2.426.2 and earlier does not disable it. This allows attackers to read arbitrary files on the Jenkins controller file system using the default character encoding of the Jenkins controller process. Attackers with Overall/Read permission can read entire files. Attackers without Overall/Read permission can read the first few lines of files. The number of lines that can be read depends on available CLI commands. As of publication of this advisory, the Jenkins security team has found ways to read the first three lines of files in recent releases of…
Recommended action: Upgrade to 2.442, 2.440.1 or 2.426.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins has a built-in command line interface (CLI) to access Jenkins from a script or shell environment. Since Jenkins 2.217 and LTS 2.222.1, one of the ways to communicate with the CLI is through a WebSocket endpoint. This endpoint relies on the default Jenkins web request authentication functionality, like HTTP Basic authentication with API tokens, or session cookies. This endpoint is enabled when running on a version of Jetty for which Jenkins supports WebSockets. This is the case when using the provided native installers, packages, or the Docker containers, as well as when running Jenkins with the command java -jar jenkins.war. Jenkins 2.217 through 2.441 (both inclusive), LTS 2.222.1 through 2.426.2 (both inclusive) does not perform origin validation of requests made through the CLI WebSocket endpoint, resulting in a cross-site WebSocket hijacking (CSWSH) vulnerability.
Recommended action: Upgrade to 2.442 or 2.426.3 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ExpandableDetailsNote allows annotating build log content with additional information that can be revealed when interacted with. Jenkins 2.423 and earlier, LTS 2.414.1 and earlier does not escape the value of the caption constructor parameter of ExpandableDetailsNote. This results in a stored cross-site scripting (XSS) vulnerability exploitable by attackers able to provide caption parameter values. As of publication, the related API is not used within Jenkins (core), and the Jenkins security team is not aware of any affected plugins. Jenkins 2.424, LTS 2.414.2 escapes caption constructor parameter values.
Recommended action: Upgrade to 2.424 or 2.414.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.424 or 2.414.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.424 or 2.414.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins allows filtering builds in the build history widget by specifying an expression that searches for matching builds by name, description, parameter values, etc. 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 this search. This allows 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. Jenkins 2.424, LTS 2.414.2 excludes sensitive variables from this search.
Recommended action: Upgrade to 2.424 or 2.414.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.424 or 2.414.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins applies formatting to the console output of builds, transforming plain URLs into hyperlinks. Jenkins 2.415 and earlier, 2.414 and earlier, and LTS 2.401.2 and earlier does not sanitize or properly encode URLs of these hyperlinks in build logs. This results in a stored cross-site scripting (XSS) vulnerability exploitable by attackers able to control build log contents. Jenkins 2.416, 2.414.1, and LTS 2.401.3 encodes URLs of affected hyperlink annotations in build logs.
Recommended action: Upgrade to 2.416, 2.414.1 or 2.401.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins provides context menus for various UI elements, like links to jobs and builds, or breadcrumbs. In Jenkins 2.399 and earlier, LTS 2.387.3 and earlier, POST requests are sent in order to load the list of context actions. If part of the URL includes insufficiently escaped user-provided values, a victim may be tricked into sending a POST request to an unexpected endpoint (e.g., the Script Console) by opening a context menu. As of publication of this advisory, we are aware of insufficiently escaped context menu URLs for label expressions, allowing attackers with Item/Configure permissions to exploit this vulnerability. Jenkins 2.400, LTS 2.401.1 sends GET requests to load the list of context actions.
Recommended action: Upgrade to 2.400 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins 2.270 through 2.393 (both inclusive), LTS 2.277.1 through 2.375.3 (both inclusive) does not escape the Jenkins version a plugin depends on when rendering the error message stating its incompatibility with the current version of Jenkins, resulting in a stored cross-site scripting (XSS) vulnerability exploitable by attackers able to provide plugins to the configured update sites and have this message shown by Jenkins instances.
Recommended action: Upgrade to 2.394 or 2.375.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins 2.393 and earlier, LTS 2.375.3 and earlier, and prior to LTS 2.387.1 is affected by the Apache Commons FileUpload library’s vulnerability CVE-2023-24998. This library is used to process uploaded files via the Stapler web framework (usually through StaplerRequest#getFile) and MultipartFormDataParser in Jenkins. This allows attackers to cause a denial of service (DoS) by sending crafted requests to HTTP endpoints processing file uploads. Jenkins 2.394, LTS 2.375.4, and LTS 2.387.1 limits the number of request parts to be processed to 1000. Specific endpoints receiving only simple form submissions have a lower limit.
Recommended action: Upgrade to 2.394, 2.387.1 or 2.375.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins 2.393 and earlier, LTS 2.375.3 and earlier uses the Apache Commons FileUpload library without specifying limits for the number of request parts introduced in version 1.5 for CVE-2023-24998 in org.kohsuke.stapler.RequestImpl, allowing attackers to trigger a denial of service.
Recommended action: Upgrade to 2.394, 2.387.1 or 2.375.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins 2.393 and earlier, LTS 2.375.3 and earlier, and prior to LTS 2.387.1 prints an error stack trace on agent-related pages when agent connections are broken, potentially revealing information about Jenkins configuration that is otherwise inaccessible to attackers. Jenkins 2.394, LTS 2.375.4, and LTS 2.387.1 does not display error stack traces when agent connections are broken.
Recommended action: Upgrade to 2.394, 2.387.1 or 2.375.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins creates a temporary file when a plugin is uploaded from an administrator’s computer. Jenkins 2.393 and earlier, LTS 2.375.3 and earlier, and prior to LTS 2.387.1 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 allows attackers to read the temporary file. Jenkins 2.394, LTS 2.375.4, and LTS 2.387.1 creates the temporary file with more restrictive permissions. As a workaround, you can set a different path as your default temporary directory using the Java system property java.io.tmpdir, if…
Recommended action: Upgrade to 2.394, 2.387.1 or 2.375.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When triggering a build from the Jenkins CLI, Jenkins creates a temporary file on the controller if a file parameter is provided through the CLI’s standard input. Jenkins 2.393 and earlier, LTS 2.375.3 and earlier, and , and LTS prior to 2.387.1 creates this temporary file in the default 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 used in the build. 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 allows attackers to read the temporary file. Jenkins 2.394, LTS 2.375.4, and LTS 2.387.1 creates the temporary file with more restrictive permissions. As a workaround, you can set a different path as your default temporary directory using the Java system…
Recommended action: Upgrade to 2.394, 2.387.1 or 2.375.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins uses temporary directories adjacent to workspace directories, usually with the @tmp name suffix, to store temporary files related to the build. In pipelines, these temporary directories are adjacent to the current working directory when operating in a subdirectory of the automatically allocated workspace. Jenkins-controlled processes, like SCMs, may store credentials in these directories. Jenkins 2.393 and earlier, LTS 2.375.3 and earlier, and prior to LTS 2.387.1 shows these temporary directories when viewing job workspaces, which allows attackers with Item/Workspace permission to access their contents. Jenkins 2.394, LTS 2.375.4, and LTS 2.387.1 does not list these temporary directories in job workspaces. As a workaround, do not grant Item/Workspace permission to users who lack Item/Configure permission, if you’re concerned about this issue but unable to immediately update Jenkins.
Recommended action: Upgrade to 2.394, 2.387.1 or 2.375.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins 2.367 through 2.369 (both inclusive) does not escape tooltips of the l:helpIcon UI component used for some help icons on the Jenkins web UI, resulting in a stored cross-site scripting (XSS) vulnerability exploitable by attackers able to control tooltips for this component. As of publication, the Jenkins security team is unaware of any exploitable help icon/tooltip in Jenkins core or plugins published by the Jenkins project. The vast majority of help icons use the l:help component instead of l:helpIcon. The few known instances of l:helpIcon do not have user-controllable tooltip contents.
Recommended action: Upgrade to 2.370 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Since Jenkins 2.340, the tooltip of the build button in list views supports HTML without escaping the job display name. This vulnerability is known to be exploitable by attackers with Job/Configure permission. Jenkins 2.356 addresses this vulnerability. The tooltip of the build button in list views is now escaped. No Jenkins LTS release is affected by SECURITY-2776 or SECURITY-2780, as these were not present in Jenkins 2.332.x and fixed in the 2.346.x line before 2.346.1.
Recommended action: Upgrade to 2.356 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Since Jenkins 2.321 and LTS 2.332.1, the HTML output generated for new symbol-based SVG icons includes the title attribute of l:ionicon until Jenkins 2.334 and alt attribute of l:icon since Jenkins 2.335 without further escaping. This vulnerability is known to be exploitable by attackers with Job/Configure permission. Jenkins 2.356, LTS 2.332.4 and LTS 2.346.1 addresses this vulnerability, the title attribute of l:ionicon (Jenkins LTS 2.332.4) and alt attribute of l:icon (Jenkins 2.356 and LTS 2.346.1) are escaped in the generated HTML output.
Recommended action: Upgrade to 2.356, 2.346.1 or 2.332.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jenkins uses the Stapler web framework to render its UI views. These views are frequently composed of several view fragments, enabling plugins to extend existing views with more content. Before SECURITY-534 was fixed in Jenkins 2.186 and LTS 2.176.2, attackers could in some cases directly access a view fragment containing sensitive information, bypassing any permission checks in the corresponding view. In Jenkins 2.335 through 2.355 (both inclusive), the protection added for SECURITY-534 is disabled for some views. As a result, attackers could in very limited cases directly access a view fragment containing sensitive information, bypassing any permission checks in the corresponding view. As of publication, the Jenkins security team is unaware of any vulnerable view fragment across the Jenkins plugin ecosystem. Jenkins 2.356 restores the protection for affected views. No Jenkins LTS release is affected by this issue, as it was not present in Jenkins 2.332.x and fixed in the 2.346.x…
Recommended action: Upgrade to 2.356 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.