The team behind Jenkins, the widely used CI/CD open source tool, has published an advisory urging users to patch against two major vulnerabilities. While the advisory was published a week ago, 45,000 instances still remain exposed.
The vulnerabilities, CVE-2024-23897 and CVE-2024-23898, were rated critical and high-severity respectively, and were disclosed on 24 January by Yaniv Nizry, a vulnerability researcher at Sonarsource. These vulnerabilities don't impact all Jenkins deployments, being limited to Jenkins versions 2.442 and LTS 2.426.3.
CVE-2024-2389, can allow an unauthenticated attacker with no permissions to leak the first couple of lines of arbitrary text files on a vulnerable Jenkins server. However, an authenticated attacker can retrieve entire text files, using the connect-node CLI command.
This vulnerability has emerged because Jenkins has a built-in command line interface (CLI) to access Jenkins from a script or shell environment. The CLI is enabled by default in versions LTS 2.426.2 and earlier of Jenkins.
Jenkins uses the args4j library to parse command arguments and options on the Jenkins controller when processing CLI commands. This command parser has a feature that replaces an @ character followed by a file path in an argument with the file’s contents (expandAtFiles).
This allows attackers to read arbitrary files on the Jenkins controller file system using the default character encoding of the Jenkins controller process through the vulnerability CVE-2024-23897.
However, the access an attacker can gain to the server depends on certain server configurations. As mentioned earlier, an unauthenticated attacker can only leak the first few lines of arbitrary files. However, if a Jenkins server is configured to have the “Allow users to sign up” option, which allows anyone with access to the Jenkins instance to self-register an account or the “Allow anonymous read access” option gives everyone the Overall/Read permission, the risk from the vulnerability increases substantially.
The high-severity flaw, CVE-2024-23898, stems from a weakness in the software’s WebSocket CLI feature, which does not perform origin validation of requests made through the CLI WebSocket endpoint, resulting in a cross-site WebSocket hijacking.
This would mean that an attacker could create a malicious web page on their own domain which establishes a cross-site WebSocket connection to the vulnerable server, and handle the connection in the context of the victim user's session with the application.
According to Nizry, threat actors could use social engineering attacks to trick users into clicking malicious links that would enable the attacker to eventually execute CLI commands as the victim.
The vulnerability impacts Jenkins 2.217 through 2.441 (both inclusive), LTS 2.222.1 through 2.426.2 (both inclusive).
In the week since, despite Jenkins pushing a patch, multiple proof of concept exploits for the patch have been made publicly available. Florian Roth, Head of Research at Nextron Systems shared these POCs over X, terming the file leak vulnerability serious.
Chaofan Shou, a security researcher affiliated with the University of Berkeley, said that his lab had seen the file leak vulnerability exploited in the wild and managed to reproduce it. However, incident reports of the vulnerability being exploited in the wild were not available at the time of publication.
See also: Patch Tuesday brings lots of chaff, a little buggy wheat too. Some CVE highlights to review.
The advice for all users is that Jenkins weekly should be updated to version 2.442, while Jenkins LTS should be updated to version 2.426.3. However, in the case that users are unable to update and patch immediately, they should disable access to CLI, as that is expected to prevent exploitation completely.
The link to the patch can be found here.