Jenkins < 2.46.2 / 2.57 and Jenkins Enterprise < 1.625.24.1 / 1.651.24.1 / / Multiple Vulnerabilities


The version of Jenkins running on the remote web server is prior to 2.57 or is a version of Jenkins LTS prior to 2.46.2, or else it is a version of Jenkins Enterprise that is 1.625.x.y prior to 1.625.24.1, 1.651.x.y prior to 1.651.24.1, 2.7.x.0.y prior to, or 2.x.y.z prior to It is, therefore, affected by multiple vulnerabilities : - A remote code execution vulnerability exists within core/src/main/java/jenkins/model/Jenkins.java that allows an untrusted serialized Java SignedObject to be transfered to the remoting-based Jenkins CLI and deserialized using a new ObjectInputStream. By using a specially crafted request, an unauthenticated, remote attacker can exploit this issue to bypass existing blacklist protection mechanisms and execute arbitrary code. (CVE-2017-1000353) - A flaw exists in the remoting-based CLI, specifically in the ClientAuthenticationCache.java class, when storing the encrypted username of a successfully authenticated user in a cache file that is used to authenticate further commands. An authenticated, remote attacker who has sufficient permissions to create secrets in Jenkins and download their encrypted values can exploit this issue to impersonate any other Jenkins user on the same instance. (CVE-2017-1000354) - A denial of service vulnerability exists in the XStream library. An authenticated, remote attacker who has sufficient permissions, such as creating or configuring items, views or jobs, can exploit this to crash the Java process by using specially crafted XML content. (CVE-2017-1000355) - Cross-site request forgery (XSRF) vulnerabilities exist within multiple Java classes due to a failure to require multiple steps, explicit confirmation, or a unique token when performing certain sensitive actions. An unauthenticated, remote attacker can exploit these to perform several administrative actions by convincing a user into opening a specially crafted web page. (CVE-2017-1000356) Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.