CVE-2024-23897: Critical Jenkins RCE Vulnerability That Will Never Be Patched on EOL Versions

🔴 CVE-2024-23897 Jenkins· CVSS 9.8 Critical · Affects: Jenkins ≤ 2.441 and LTS ≤ 2.426.2 · EOL versions: Will never be patched · Actively exploited in ransomware attacks · CISA KEV listed

Jenkins disclosed CVE-2024-23897 on January 24, 2024. CVSS score: 9.8. Unauthenticated. Remote code execution. If your team is running Jenkins LTS 2.346.x or any version before 2.426.3 – a version that reached end
of life in June 2023 – this vulnerability will never receive a patch. Every day you run it is a day attackers can read arbitrary files from your CI/CD server without credentials.

CISA added CVE-2024-23897 Jenkins to its Known Exploited Vulnerabilities catalog in August 2024. Ransomware groups actively exploited it against production CI/CD infrastructure. The proof-of-concept exploit is publicly available
on GitHub. Your Jenkins server is not obscure enough to avoid it.

Vulnerability Summary

What the Vulnerability Actually Does

The Jenkins CLI command parser has a feature that reads file contents when it encounters an @ character followed by a file path. CVE-2024-23897Jenkins exploits this parser to trick Jenkins into reading arbitrary files from its own filesystem and returning their contents to the attacker.

An unauthenticated attacker sends a crafted request to the Jenkins CLI endpoint. Jenkins processes the @ character as a file read directive. The server returns the contents of whatever file the attacker specified including /etc/passwd, SSH private keys, Jenkins credentials XML files, and API tokens stored on disk.

Once an attacker has your Jenkins credentials file, they have your AWS keys, your GitHub tokens, your Kubernetes service account credentials, and everything else your CI/CD pipeline touches. Remote code execution follows from there under certain privilege configurations.

Sonar researchers who discovered the vulnerability documented multiple exploitation paths including admin privilege escalation and full remote code execution. The exploit does not require a logged-in user. It works against any internet-exposed Jenkins instance running a vulnerable version.

Are You Running a Vulnerable Version?

# Check your Jenkins version via CLI
java -jar jenkins-cli.jar -s http://your-jenkins:8080/ version

# Check via API (no auth required on many instances)
curl -s http://your-jenkins:8080/api/json | jq '.version'

# Check via web UI
# Navigate to: http://your-jenkins:8080/manage
# Version shown in bottom right corner

# Check running Docker containers
docker ps --format "table {{.Names}}\t{{.Image}}" | grep jenkins
docker inspect <container_id> | grep -i version

You are vulnerable if your version is:

• Any Jenkins version ≤ 2.441
• Any Jenkins LTS ≤ 2.426.2
• Jenkins LTS 2.346.x (EOL June 2023 — will never be patched)
• Any version older than 2.346.x

Why EOL Jenkins Versions Will Never Receive This Patch

Jenkins 2.426.3 LTS and Jenkins 2.442 are the versions where this vulnerability was fixed. If you are running Jenkins LTS 2.346.x which reached end of life in June 2023, the Jenkins security team will not backport the fix. The EOL policy is explicit: no security patches for unsupported versions.

This means if you discovered CVE-2024-23897 Jenkins in a security scan against your EOL Jenkins instance, the scanner is correct. There is no patch coming. The fix is upgrading to a supported LTS release.

Immediate Mitigations

If you cannot upgrade today, these steps reduce your exposure. They are not fixes, they are temporary risk reduction while you plan the upgrade.

Option 1 – Disable Jenkins CLI Access (Fastest)

The attack vector requires access to the Jenkins CLI endpoint. Disabling CLI access breaks the exploit chain:

# Via Jenkins Script Console — go to Manage Jenkins → Script Console
# Run this Groovy script:
jenkins.CLI.get().setEnabled(false)

# Or via the Jenkins API:
curl -X POST http://your-jenkins:8080/cli \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data "command=disable-cli" \
  --user admin:your-api-token

After disabling CLI, verify by attempting a CLI connection – it should return a connection refused or disabled error.

Option 2 – Block External CLI Access at Network Level

If your Jenkins is internet-exposed, block port 8080 (or your Jenkins port) from all external IPs and allow only your VPN or internal network:

# Using iptables — block external access to Jenkins port
iptables -I INPUT -p tcp --dport 8080 ! -s 10.0.0.0/8 -j DROP

# Using AWS Security Groups — remove 0.0.0.0/0 from Jenkins port
# AWS Console → EC2 → Security Groups → your-jenkins-sg → 
# Inbound Rules → remove port 8080 from 0.0.0.0/0

Option 3 – Detection – Monitor for Exploitation Attempts

Even while mitigating, monitor for exploitation attempts in your Jenkins access logs:

# Search Jenkins access logs for CLI exploit patterns
grep -E "POST.*cli.*remoting=false" /var/log/jenkins/access.log

# The exploit sends sequential upload/download requests
# Look for POST /cli?remoting=false with large response bodies
tail -f /var/log/jenkins/access.log | grep "cli"

The Upgrade Path – EOL Jenkins to Current LTS

The permanent fix is upgrading to Jenkins LTS 2.440.x or higher. The current stable LTS release as of May 2026 is available at jenkins.io/download.

Pre-Upgrade Checklist

# 1. Backup Jenkins home directory
tar -czf jenkins-backup-$(date +%Y%m%d).tar.gz /var/lib/jenkins/

# 2. Document your current version
java -jar jenkins-cli.jar -s http://localhost:8080/ version > \
  jenkins-version-before-upgrade.txt

# 3. List all installed plugins and versions
java -jar jenkins-cli.jar -s http://localhost:8080/ \
  list-plugins > jenkins-plugins-before-upgrade.txt

# 4. Export job configurations
java -jar jenkins-cli.jar -s http://localhost:8080/ \
  list-jobs | xargs -I {} java -jar jenkins-cli.jar \
  -s http://localhost:8080/ get-job {} > all-jobs-backup.xml

Upgrade on Linux (Debian/Ubuntu)

# Stop Jenkins
sudo systemctl stop jenkins

# Download the latest LTS war file
wget https://get.jenkins.io/war-stable/latest/jenkins.war \
  -O /tmp/jenkins-new.war

# Replace the existing war file
sudo cp /tmp/jenkins-new.war /usr/share/jenkins/jenkins.war

# Start Jenkins
sudo systemctl start jenkins

# Verify new version
java -jar jenkins-cli.jar -s http://localhost:8080/ version

Upgrade via Docker

# Update your Dockerfile or docker-compose.yml
# Before:
FROM jenkins/jenkins:2.346.3-lts

# After:
FROM jenkins/jenkins:lts-jdk21

# Pull the new image
docker pull jenkins/jenkins:lts-jdk21

# Restart your Jenkins container with the new image
docker-compose down
docker-compose up -d

Post-Upgrade Verification

# Confirm vulnerability is patched - attempt CLI connection
java -jar jenkins-cli.jar -s http://your-jenkins:8080/ version

# Run a plugin compatibility check
# Manage Jenkins → Manage Plugins → scroll to bottom
# Check for incompatible plugins after major version upgrade

# Re-enable CLI if you disabled it during mitigation
# Manage Jenkins → Configure Global Security → 
# Enable CLI over Remoting: tick the checkbox

Plugin Compatibility Warning

Jenkins LTS 2.346.x used Java 8 or 11. Current Jenkins LTS requires Java 17 or 21. If you are jumping from 2.346.x to current LTS, check your plugin compatibility list before upgrading in production. Some plugins built for older Java versions require updates.

Run this in your Jenkins Script Console before upgrading to see which plugins may have issues:

// Paste in Manage Jenkins → Script Console
def plugins = Jenkins.instance.pluginManager.plugins
plugins.each { plugin ->
  println "${plugin.getShortName()}:${plugin.getVersion()}"
}

Compare the output against the Jenkins plugin compatibility matrix at plugins.jenkins.io before proceeding with the upgrade in production.

Your Action This Week

Run curl -s http://your-jenkins:8080/api/json | jq '.version' right now. If the output shows any version below 2.442 and your Jenkins is internet-accessible, disable CLI access today and schedule the upgrade for this sprint. CVE-2024-23897 Jenkins has a public exploit, CISA confirmation, and active ransomware exploitation. This is not a theoretical risk.