Organizations are being urged to fix two security vulnerabilities in Jenkins that could allow unauthenticated attackers to remotely execute arbitrary code in the popular open source software tool that is used to automate various steps in the software development lifecycle.

Researchers with SonarSource, a code quality and security firm, in November 2023 alerted the maintainers of Jenkins about two security flaws that could allow some unauthenticated attackers to read the few lines of a file and others – even those with “read-only” permissions – to read entire files. The researchers also worked with the maintainers to verify the fix.

Some attackers also could read binary files that include cryptographic keys used for features in Jenkins that could lead to a range of remote code execution (RCE) attacks, the Jenkins maintainers wrote in an advisory released last week.

Bad actors that exploit the security flaws could pose a significant threat, Yaniv Nizry, the vulnerability researcher at SonarSource credited with discovering the vulnerabilities, wrote in a report. Nizry noted Jenkins has become a key tool in the continuous integration and continuous deliver (CI/CD) space that lets developers automate such as development aspects as building, testing, and deploying applications.

“With a market share of approximately 44% in 2023, the popularity of Jenkins is evident,” he wrote. “This means the potential impact of security vulnerabilities in Jenkins is large.”

A Look at Two Flaws

Nizry outlined two vulnerabilities, the first a critical tracked as CVE-2024-23897. It’s through this flaws that “unauthenticated attackers can read the first few lines of arbitrary files from the server, while read-only authorized attackers can read the entire file,” he wrote, adding that under certain conditions, “this could ultimately lead to the execution of arbitrary code in some cases.”

According to Jenkins maintainers, the problem lies in a built-in command line interface (CLI) that is used to access Jenkins from a script or shell environment.

“Jenkins uses the args4j library to parse command arguments and options on the Jenkins controller when processing CLI commands,” they wrote in the advisory. “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 feature is enabled by default and Jenkins 2.441 and earlier, LTS 2.426.2 and earlier does not disable it.”

Because of this, attackers who exploit the flaw can read arbitrary files on the Jenkins controller file system using the default character encoding of the Jenkins controller process, they wrote.

They also can read the binary files with the cryptographic keys, which could lead to a range of attacks, including several RCE attacks done through such channels as resource roots URLs, a “remember me” cookie, and a CSRF protection bypass. It also could enable bad actors to decrypt secrets stored in Jenkins or delete items in the tool.

Executing Arbitrary CLI Commands

The second vulnerability, a high-severity flaw tracked as CVE-2024-23898, is a cross-site WebSocket hijacking bug in the CLI that allows threat actors to executive arbitrary CLI commands. The Jenkins maintainers noted that since Jenkins 2.217 and LTS 2.222.1, a way to communicate with the CLI is through a WebSocket endpoint.

“This endpoint relies on the default Jenkins web request authentication functionality, like HTTP Basic authentication with API tokens, or session cookies,” they wrote. “This endpoint is enabled when running on a version of Jetty for which Jenkins supports WebSockets. This is the case when using the provided native installers, packages, or the Docker containers, as well as when running Jenkins with the command java -jar jenkins.war.”

How much of an impact an attacker can have depends on the permissions of the bad actor or the browsers used by the victims. Such conditions include the attacker having no permissions and Jenkins users using web browser with SameSite cookie attribute Lax as default, the attacker has been granted permissions, and Jenkins users using browsers where the SameSite cookie attribute Lax is not the default.

Both vulnerabilities are fixed in Jenkins versions 2.442 and LTS 2.426.3. In the advisory, the maintainers also outlined workarounds for organizations that are unable to immediately upgrade to the new versions.

Growing Popularity of Jenkins

The Continuous Delivery Foundation, which maintains Jenkins, said in a report last year that developers continue to adopt the tool in their CI/CD work. Between June 2021 and 2023, Jenkins Pipeline use jumped 79%, while the total number of workloads on Jenkins during the same period grew 45%

Fatih Degirmenci, executive director of the Continuous Delivery Foundation, said in a statement accompanying the report that there is “a trend in the uptake of open source by large organizations. Dominant enterprises in sectors such as financial services, semiconductors, and manufacturing who were reluctant to adopt open source in the past are now publicly embracing it. More and more, enterprises are discovering that open source software, such as Jenkins, speeds innovation and enables competitive advantage.”