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.
Recent assessments:
space-r7 at September 11, 2020 5:56pm UTC reported:
The readFrom
method within the Command
class in the Jenkins CLI remoting component deserializes objects received from clients without first checking / sanitizing the data. Because of this, a malicious serialized object contained within a serialized SignedObject
can be sent to the Jenkins endpoint to achieve code execution on the target.
This is a fairly old vulnerability, so itβs unlikely that there are many, if any vulnerable installations on the web today, but I rated this vulnerability based on what it could give an attacker if they were to find a vulnerable installation online today. This vulnerability is yet another Java deserialization vulnerability that I would define as critical given a number of reasons:
Unauthenticated code execution
There is no special / proprietary protocol that will hinder exploitation ( you just send the object in the body of a POST request )
A proof of concept exists and has for some time
Again, this is an unlikely target given the date of the vulnerability, but I think an attacker would definitely aim to exploit this if it was spotted online.
Assessed Attacker Value: 4
Assessed Attacker Value: 4Assessed Attacker Value: 4