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.
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/jsonand read theX-Jenkinsresponse 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-Jenkinsheader 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 tosecrets/,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/helpcommand 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
- CISA Known Exploited Vulnerabilities Catalog
- NVD CVE-2024-23897 — 2024-01-24
- Jenkins Security Advisory 2024-01-24 (SECURITY-3314) — 2024-01-24
- The Hacker News: CISA warns of critical Jenkins vulnerability exploited in ransomware attacks — 2024-08
- Help Net Security: Critical Jenkins RCE flaw exploited in the wild (CVE-2024-23897) — 2024-01-29
- BleepingComputer: CISA warns of Jenkins RCE bug exploited in ransomware attacks — 2024-08
Share
Related field notes
-
The attacker installed a second antivirus to crash your first one
CVE-2024-38094 is a 7.2. It requires authentication. Most teams filed it below the criticals. It was still the entry point for a two-week, full-domain compromise, and the cleanup tactic was installing rogue antivirus to make the real EDR fall over.
-
SysAid customers got the patch the same week they learned they were already breached
CVE-2023-47246 was a SysAid zero-day before it was a CVE. The Cl0p operator Lace Tempest, fresh off MOVEit, was writing webshells to Tomcat and deploying ransomware while the vendor was still writing the advisory. When the attacker has the bug first, detection matters as much as patching.
-
TeamCity's path traversal took two years to reach KEV. That's a long time to leave a CI server exposed.
CVE-2024-27199, a path traversal in JetBrains TeamCity On-Premises, was patched in March 2024 and exploited by BianLian ransomware within days. CISA added it to KEV in April 2026 with a May 4 federal deadline. If you're still below 2023.11.4, this is two years overdue.
One email, every weekday morning.
You're in. Check your inbox.