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: 1. Unauthenticated code execution 2. There is no special / proprietary protocol that will hinder exploitation ( you just send the object in the body of a POST request ) 3. 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