PatchDay Alert
Field Note · 5 min read · 1,041 words By runbook-desk

Jenkins CVE-2024-23897: from 'limited file read' to your secret key

The KEV entry calls it 'limited read access to certain files.' On a Jenkins controller, the files include the cryptographic key that turns read into remote code execution. Here's how to check, patch, and what to rotate if you were exposed.

Jenkins CVE-2024-23897: from 'limited file read' to your secret key

The official descriptions undersell this one. The CISA KEV entry calls CVE-2024-23897 “limited read access to certain files.” That phrasing is technically accurate and operationally misleading, because on a Jenkins controller the files an attacker wants to read are the cryptographic secrets that let them forge their way to remote code execution. CVSS 9.8, unauthenticated, and a CI/CD server is one of the worst boxes in your estate to hand to an attacker, because it holds credentials to your source, your artifacts, and your deploy targets. RansomEXX used this bug against a payments technology provider and disrupted retail payments at Indian banks.

This is a runbook. Work it top to bottom.

What the bug actually does

Jenkins’s CLI uses the args4j library to parse command arguments. args4j has a feature called expandAtFiles: an argument of the form @/path/to/file gets replaced with the contents of that file. Jenkins didn’t disable it, so an attacker can pass @ arguments over the CLI and have the controller read files back to them. Anonymous users with no permissions can read the first few lines of arbitrary files; users with Overall/Read can read entire files. Affected: Jenkins 2.441 and earlier, LTS 2.426.2 and earlier.

The escalation from read to RCE is the documented part, not speculation. Jenkins’s own advisory lists multiple chains. The common one: read the binary secret key (hudson.util.Secret, decryptable with master.key) out of the Jenkins home directory, then use those recovered secrets to decrypt stored credentials, forge “Remember me” cookies, or abuse resource-root-URL and CSRF paths to execute code. Read access to the right files on this box is functionally full control of it.

Step 1 — Find your Jenkins instances and versions

Don’t assume you know where they all are. CI servers get stood up by teams without going through central IT.

  • Check every Jenkins controller’s version: Manage Jenkins → the version is in the page footer, or query GET /api/json and read the X-Jenkins response header.
  • You need Jenkins 2.442 or later, or LTS 2.426.3 or later. Anything below that is vulnerable.
  • Hunt for unmanaged instances: scan internal ranges for the Jenkins login page and the X-Jenkins header on common ports (8080, 8443). A forgotten Jenkins box on a 2.380-something LTS is the one that gets you.

Step 2 — Patch, or disable the CLI if you genuinely can’t

  • Patch first. Upgrade to 2.442 / LTS 2.426.3 or later. This is the real fix and it’s a clean in-place upgrade for most deployments.
  • If you cannot patch immediately, Jenkins documented a workaround: disable access to the CLI entirely. This blocks the vulnerable path until you can upgrade. Treat it as a stopgap measured in days, not a permanent posture, and confirm nothing in your automation depends on the CLI before you cut it.
  • Do not rely on “the CLI isn’t exposed” as your only control unless you’ve actually verified the access path. The CLI is reachable over HTTP(S) on the same port as the web UI by default.

Step 3 — Determine whether you were already hit

The bug was disclosed January 24, 2024, public PoCs followed within days, and CISA only added it to KEV on August 19, 2024, with a September 9 deadline. That’s a long window in which unpatched, internet-reachable controllers were being scanned and exploited. If your instance was exposed during that period, investigate before you trust it.

  • Review Jenkins access logs for CLI requests containing @ followed by file paths, especially references to secrets/, master.key, hudson.util.Secret, credentials.xml, or /etc/passwd. Those are file-read attempts.
  • Look for CLI activity from unexpected source IPs, and for download/connect-node/help command patterns probing the CLI.
  • Check for unexpected new admin users, new API tokens, unfamiliar jobs or build steps, and outbound connections from the controller that don’t match your normal pipeline traffic.

Step 4 — If you find evidence of exploitation, rotate everything the controller knew

A Jenkins controller compromise is a credential-disclosure incident. Patching does not un-leak the secrets that were already read. Assume anything the controller could decrypt is now in someone else’s hands.

  • Rotate all credentials stored in Jenkins: service accounts, cloud API keys, SSH deploy keys, registry tokens, secret-text credentials.
  • Rotate credentials that the controller’s identity could reach even if not stored in Jenkins, including any cloud instance-profile or pipeline-assumed roles.
  • Invalidate existing user sessions and API tokens, and force a credential reset for Jenkins user accounts.
  • Review what those pipelines deploy to. The reason CI/CD compromise is dangerous is the blast radius downstream: if the controller could push to production or sign artifacts, treat those targets as potentially affected and check them.

Step 5 — Reduce the standing exposure

So the next Jenkins CVE, and there will be one, costs you less.

  • Take the controller off the public internet. A CI server should be reachable from your build agents and your engineers, not the world. Put it behind VPN or IP allowlisting.
  • Minimize stored long-lived secrets. Prefer short-lived, federated credentials (OIDC to your cloud) over static keys sitting in the credentials store, so a future file-read leaks less.
  • Lock down anonymous read. The bug is worse when anonymous users have permissions; principle of least privilege on the authorization matrix limits what an unauthenticated attacker gets.

The takeaway to carry past this single CVE: when an advisory says “file read” about a server that stores its own decryption keys on disk, read it as “code execution with extra steps.” Your CI/CD controller is part of your supply chain, and it deserves the same patch urgency you’d give an internet-facing VPN. We flag the KEV additions that hit build and deploy infrastructure specifically, because “limited read access” on the wrong server is how a payments processor ends up taking banks offline.

Sources

Share

Related field notes

One email, every weekday morning.

You're in. Check your inbox.

Get the digest

Free. Weekday mornings. Plain English CVE triage.

Check your inbox to confirm.