The following flaw was found in Jenkins:

A vulnerability in the Jenkins remoting module allowed unauthenticated remote attackers to open a JRMP listener on the server hosting the Jenkins master process, which allowed arbitrary code execution.

External References:

https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2016-02-24

The following flaw was found in Jenkins:

Unsafe deserialization allows unauthenticated remote attackers to run arbitrary code on the Jenkins master.

This flaw could allow unauthenticated remote attackers to run arbitrary code on Jenkins.

Mitigation:

https://jenkins-ci.org/content/mitigating-unauthenticated-remote-code-execution-0-day-jenkins-cli

External References:

https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2015-11-11

Jenkins before 1.650 and LTS before 1.642.2 do not use a constant-time algorithm to verify CSRF tokens, which makes it easier for remote attackers to bypass a CSRF protection mechanism via a brute-force approach.

FilePath#renameTo and FilePath#moveAllChildrenTo in Jenkins 2.318 and earlier, LTS 2.303.2 and earlier only check 'read' agent-to-controller access permission on the source path, instead of 'delete'.

Jenkins 2.318 and earlier, LTS 2.303.2 and earlier does not limit agent read/write access to the libs/ directory inside build directories when using the FilePath APIs. This directory is used by the Pipeline: Shared Groovy Libraries Plugin to store copies of shared libraries.

This allows attackers in control of agent processes to replace the code of a trusted library with a modified variant, resulting in unsandboxed code execution in the Jenkins controller process.

Jenkins 2.319, LTS 2.303.3 prohibits agent read/write access to the libs/ directory inside build directories.

If you are unable to immediately upgrade to Jenkins 2.319, LTS 2.303.3, you can install the Remoting Security Workaround Plugin. It will prevent all agent-to-controller file access using FilePath APIs. Because it is more restrictive than Jenkins 2.319, LTS 2.303.3, more plugins are incompatible with it. Make sure to read the plugin documentation before installing it.

It is not easily possible to customize the file access rules to prohibit access to the libs/ directory specifically, as built-in rules (granting access to <BUILDDIR> contents) would take precedence over a custom rule prohibiting access.

FilePath#toURI, FilePath#hasSymlink, FilePath#absolutize, FilePath#isDescendant, and FilePath#getDiskSpace do not check any permissions in Jenkins 2.318 and earlier, LTS 2.303.2 and earlier.

Creating symbolic links is possible without the 'symlink' agent-to-controller access control permission in Jenkins 2.318 and earlier, LTS 2.303.2 and earlier.

The re-key admin monitor was introduced in Jenkins 1.498 and re-encrypted all secrets in JENKINSHOME with a new key. It also created a backup directory with all old secrets, and the key used to encrypt them. These backups were world-readable and not removed afterwards. Jenkins now deletes the backup directory, if present. Upgrading from before 1.498 will no longer create a backup directory. Administrators relying on file access permissions in their manually created backups are advised to check them for the directory $JENKINSHOME/jenkins.security.RekeySecretAdminMonitor/backups, and delete it if present.

Agent processes are able to completely bypass file path filtering by wrapping the file operation in an agent file path in Jenkins 2.318 and earlier, LTS 2.303.2 and earlier.

The agent-to-controller security subsystem limits which files on the Jenkins controller can be accessed by agent processes.

Multiple vulnerabilities in the file path filtering implementation of Jenkins 2.318 and earlier, LTS 2.303.2 and earlier allow agent processes to read and write arbitrary files on the Jenkins controller file system, and obtain some information about Jenkins controller file systems.

SECURITY-2539 / CVE-2021-21693: When creating temporary files, permission to create files is only checked after they’ve been created.

We expect that most of these vulnerabilities have been present since SECURITY-144 was addressed in the 2014-10-30 security advisory.

Jenkins 2.319, LTS 2.303.3 addresses these security vulnerabilities.

SECURITY-2539 / CVE-2021-21693: When creating temporary files, permission to create files is checked before they are created based on an artificial path.

As some common operations are now newly subject to access control, it is expected that plugins sending commands from agents to the controller may start failing. Additionally, the newly introduced path canonicalization means that instances using a custom builds directory (Java system property jenkins.model.Jenkins.buildsDir) or partitioning JENKINSHOME using symbolic links may fail access control checks. See the documentation for how to customize the configuration in case of problems.

If you are unable to immediately upgrade to Jenkins 2.319, LTS 2.303.3, you can install the Remoting Security Workaround Plugin. It will prevent all agent-to-controller file access using FilePath APIs. Because it is more restrictive than Jenkins 2.319, LTS 2.303.3, more plugins are incompatible with it. Make sure to read the plugin documentation before installing it.

A flaw was found in Jenkins. Affected versions of Jenkins do not escape the Jenkins version that a plugin depends on when rendering the error message stating its incompatibility with the current version of Jenkins in the plugin manager. This issue results 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.

Jenkins 2.470 and earlier, LTS 2.452.3 and earlier allows agent processes to read arbitrary files from the Jenkins controller file system by using the ClassLoaderProxy#fetchJar method in the Remoting library.

Agents are allowed some limited access to files on the Jenkins controller file system. The directories agents are allowed to access in Jenkins 2.318 and earlier, LTS 2.303.2 and earlier include the directories storing build-related information, intended to allow agents to store build-related metadata during build execution. As a consequence, this allows any agent to read and write the contents of any build directory stored in Jenkins with very few restrictions (build.xml and some Pipeline-related metadata).

Jenkins 2.319, LTS 2.303.3 prevents agents from accessing contents of build directories unless it’s for builds currently running on the agent attempting to access the directory.

Update Pipeline: Nodes and Processes to version 2.40 or newer for Jenkins to associate Pipeline node blocks with the agent they’re running on for this fix.

If you are unable to immediately upgrade to Jenkins 2.319, LTS 2.303.3, you can install the Remoting Security Workaround Plugin. It will prevent all agent-to-controller file access using FilePath APIs. Because it is more restrictive than Jenkins 2.319, LTS 2.303.3, more plugins are incompatible with it. Make sure to read the plugin documentation before installing it.

FilePath#untar does not check permission to create symbolic links when unarchiving a symbolic link.

FilePath#mkdirs does not check permission to create parent directories.

FilePath#unzip and FilePath#untar were not subject to any access control.

Multiple unspecified API endpoints in Jenkins before 1.650 and LTS before 1.642.2 allow remote authenticated users to execute arbitrary code via serialized data in an XML file, related to XStream and groovy.util.Expando.

FilePath#listFiles lists files outside directories that agents are allowed to access when following symbolic links in Jenkins 2.318 and earlier, LTS 2.303.2 and earlier.

File path filters do not canonicalize paths, allowing operations to follow symbolic links to outside allowed directories.

FilePath#reading(FileVisitor) does not reject any operations, allowing users to have unrestricted read access using certain operations (creating archives, #copyRecursiveTo).

Jenkins 2.73.1 and earlier, 2.83 and earlier users with permission to create or configure agents in Jenkins could configure a launch method called 'Launch agent via execution of command on master'. This allowed them to run arbitrary shell commands on the master node whenever the agent was supposed to be launched. Configuration of this launch method now requires the Run Scripts permission typically only granted to administrators.

Jenkins 2.423 and earlier, LTS 2.414.1 and earlier creates a temporary file in the system temporary directory with the default permissions for newly created files when installing a plugin from a URL, potentially allowing attackers with access to the system temporary directory to replace the file before it is installed in Jenkins, potentially resulting in arbitrary code execution.

Cross-site request forgery (CSRF) vulnerability in Jenkins before 1.640 and LTS before 1.625.2 allows remote attackers to hijack the authentication of administrators for requests that have unspecified impact via vectors related to the HTTP GET method.

Jenkins before 1.640 and LTS before 1.625.2 allow remote attackers to bypass the CSRF protection mechanism via unspecified vectors.

Jenkins before versions 2.44, 2.32.2 is vulnerable to a remote code execution vulnerability involving the deserialization of various types in javax.imageio in XStream-based APIs (SECURITY-383).

A unauthorized modification of configuration vulnerability exists in Jenkins 2.132 and earlier, 2.121.1 and earlier in User.java that allows attackers to provide crafted login credentials that cause Jenkins to move the config.xml file from the Jenkins home directory. If Jenkins is started without this file present, it will revert to the legacy defaults of granting administrator access to anonymous users.

Jenkins 2.191 and earlier, LTS 2.176.2 and earlier allowed users to obtain CSRF tokens without an associated web session ID, resulting in CSRF tokens that did not expire and could be used to bypass CSRF protection for the anonymous user.

Jenkins versions 2.56 and earlier as well as 2.46.1 LTS and earlier are vulnerable to an issue in the Jenkins user database authentication realm: create an account if signup is enabled; or create an account if the victim is an administrator, possibly deleting the existing default admin user in the process and allowing a wide variety of impacts.

Jenkins versions 2.56 and earlier as well as 2.46.1 LTS and earlier are vulnerable to a login command which allowed impersonating any Jenkins user. The login command available in the remoting-based CLI stored the encrypted user name of the successfully authenticated user in a cache file used to authenticate further commands. Users with sufficient permission to create secrets in Jenkins, and download their encrypted values (e.g. with Job/Configure permission), were able to impersonate any other Jenkins user on the same instance.

A data modification vulnerability exists in Jenkins 2.153 and earlier, LTS 2.138.3 and earlier in User.java, IdStrategy.java that allows attackers to submit crafted user names that can cause an improper migration of user record storage formats, potentially preventing the victim from logging into Jenkins.