A cross-site scripting vulnerability exists in Jenkins 2.115 and older, LTS 2.107.1 and older, in confirmationList.jelly and stopButton.jelly that allows attackers with Job/Configure and/or Job/Create permission to create an item name containing JavaScript that would be executed in another user's browser when that other user performs some UI actions.
An exposure of sensitive information vulnerability exists in Jenkins 2.115 and older, LTS 2.107.1 and older, in CLICommand.java and ViewOptionHandler.java that allows unauthorized attackers to confirm the existence of agents or views with an attacker-specified name by sending a CLI command to Jenkins.
Jenkins before versions 2.44 and 2.32.2 is vulnerable to an insufficient permission check. This allows users with permissions to create new items (e.g. jobs) to overwrite existing items they don't have access to (SECURITY-321).
Jenkins before 2.107 and Jenkins LTS before 2.89.4 did not properly prevent specifying relative paths that escape a base directory for URLs accessing plugin resource files. This allowed users with Overall/Read permission to download files from the Jenkins master they should not have access to. On Windows, any file accessible to the Jenkins master process could be downloaded. On other operating systems, any file within the Jenkins home directory accessible to the Jenkins master process could be downloaded.
An improper authorization vulnerability exists in Jenkins versions 2.106 and earlier, and LTS 2.89.3 and earlier, that allows an attacker to have Jenkins submit HTTP GET requests and get limited information about the response.
An improper input validation vulnerability exists in Jenkins versions 2.106 and earlier, and LTS 2.89.3 and earlier, that allows an attacker to access plugin resource files in the META-INF and WEB-INF directories that should not be accessible, if the Jenkins home directory is on a case-insensitive file system.
Jenkins versions 2.56 and earlier as well as 2.46.1 LTS and earlier are vulnerable to an unauthenticated remote code execution. 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 blacklist-based protection mechanism. We're fixing this issue by adding `SignedObject` to the blacklist. We're also backporting the new HTTP CLI protocol from Jenkins 2.54 to LTS 2.46.2, and deprecating the remoting-based (i.e. Java serialization) CLI protocol, disabling it by default.
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.
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.