Jenkins CLI Arbitrary File Read (CVE-2024-23897) Explained

Jenkins sits at the center of countless software delivery pipelines, which makes its controller one of the highest-value targets in an engineering environment: it holds credentials, signing keys, deployment tokens, and the ability to run code across build agents. In January 2024, the Jenkins project disclosed CVE-2024-23897, a flaw in the built-in command-line interface that let attackers read arbitrary files from the Jenkins controller — and, through a well-understood chain, escalate that file-read into full remote code execution. It was rated critical, weaponized within days, and added to CISA's Known Exploited Vulnerabilities catalog.

Vulnerability identity and severity

CVE-2024-23897 is an arbitrary file read vulnerability in the Jenkins built-in CLI. It carries a CVSS 3.x base score of 9.8 (Critical). The root cause is a feature of the args4j command-line parsing library that Jenkins uses to process CLI commands on the controller. That feature expands an argument beginning with @ into the contents of the file at the path that follows — a convenience for passing long arguments from a file, and a serious problem when the argument is attacker-controlled.

Timeline and impact

• January 24, 2024 — the Jenkins project publishes the security advisory and fixed releases.
• Within days — public proof-of-concept exploits appear and internet-wide scanning for exposed Jenkins begins.
• Following weeks — the flaw is folded into intrusion and ransomware activity, and CISA adds it to the KEV catalog.

The severity depends on permissions, but even the weakest case is dangerous. Attackers with Overall/Read permission can read entire files. Attackers without Overall/Read — including anonymous users on instances that permit it — can still read the first few lines of arbitrary files. Given how often Jenkins is left reachable and how much sensitive material lives on the controller, "a few lines" is frequently enough to grab the secrets needed for the next step.

Root cause: the args4j @ file-expansion feature

When Jenkins parses a CLI command, args4j implements an "expand at files" behavior: any argument token that starts with @ is replaced with the contents of the file whose path follows the @. This was designed so operators could store lengthy option lists in a file. The problem is that the expansion happens on untrusted input before Jenkins enforces meaningful authorization on the command's contents. An attacker supplies a command argument like the following (safe, conceptual illustration — not a working exploit):

# Conceptually, the CLI turns:
@/etc/passwd
# into the contents of that file, which are then echoed back
# through the command's parsing/error output.

By choosing sensitive paths, an attacker reads configuration, credentials stores, and key material off the controller filesystem. The escalation to RCE follows from what those files contain. Jenkins encrypts secrets in credentials.xml using a master key that itself lives on disk (under the Jenkins home directory). An attacker who reads both the encrypted secrets and the key material can decrypt stored credentials offline, then reuse them — or combine the file read with resource-based techniques (deserialization, resource root URLs) — to achieve code execution. That is why a "file read" bug earned a 9.8.

Affected versions

• Jenkins weekly up to and including 2.441
• Jenkins LTS up to and including 2.426.2

Detection

• Confirm your version on the Jenkins dashboard footer or via jenkins-cli.jar version output; anything at or below 2.441 (weekly) or 2.426.2 (LTS) is vulnerable.
• Review CLI access logs for requests to the CLI endpoint (/cli) and for arguments containing an @ character followed by a filesystem path.
• Check whether the CLI is reachable at all from untrusted networks, and whether anonymous read access is enabled — both widen the exposure.
• Hunt for signs of secret theft: unexpected use of stored credentials, new agents, or off-hours access to credentials.xml and the controller's secret key files.

Remediation and patched versions

1. Upgrade to Jenkins 2.442 (weekly) or LTS 2.426.3 or later. These releases disable the @-file expansion feature in the command parser, closing the root cause.
2. If you cannot upgrade immediately, disable CLI access. The Jenkins advisory notes that turning off the CLI is expected to prevent exploitation as an interim measure.
3. Rotate all secrets that were stored on any controller that ran an affected version while reachable — treat stored credentials, tokens, and keys as potentially disclosed.
4. Restrict network exposure of the controller and disable anonymous read access.
5. Re-verify post-upgrade that the CLI no longer expands @-prefixed arguments into file contents.

How Safeguard helps

A CI/CD controller is both a running service and a bundle of components, so it needs to be watched from both angles. Safeguard's software composition analysis tracks the Jenkins core version and plugin inventory across your build infrastructure, flagging any controller that falls under CVE-2024-23897 so it does not hide in a self-hosted corner nobody scans. Because exploitation depends on the CLI being reachable, Safeguard's DAST engine helps confirm which instances are actually exposed, prioritizing the live risk over the theoretical. The Safeguard CLI embeds these checks into your own pipelines, so your delivery tooling is held to policy the same way your application code is — a vulnerable controller becomes a failing gate rather than a lucky catch. If you want to weigh this combined coverage against a single-vendor scanner, read Safeguard versus Snyk, and review usage-based pricing.

CVE-2024-23897 is a reminder that your pipeline is production too, and a convenience feature in a parsing library can put your most sensitive secrets one request away. Create a free Safeguard account or read the documentation to secure your build infrastructure.