If you are running Jenkins in your CI/CD pipeline — and let's be honest, most of us are — this is one advisory you should not scroll past. On March 18, 2026, the Jenkins security team released a new advisory covering three vulnerabilities, two of which are rated High severity. One of them can lead to remote code execution on your Jenkins controller. That is as serious as it gets.
Let me walk you through each vulnerability, what actually causes it, what an attacker can do with it, and most importantly — how to fix it whether you are running Jenkins on Docker, Docker Compose, or directly on your system.
The Three Vulnerabilities at a Glance
| CVE | Component | Severity | Impact |
|---|
| CVE-2026-33001 | Jenkins Core | High | Arbitrary file write → Code Execution |
| CVE-2026-33002 | Jenkins Core | High | DNS Rebinding → CLI Hijack |
| CVE-2026-33003 / CVE-2026-33004 | LoadNinja Plugin | Medium | API Key Leak |
CVE-2026-33001 — The Tar Archive Symlink Attack (High)
What Is the Problem?
This one is a classic symlink path traversal vulnerability, but applied to .tar and .tar.gz archive extraction. When Jenkins extracts these archives — for example, during an "Archive the artifacts" post-build step — it does not check whether a symlink inside the archive is pointing outside the intended extraction directory.
A crafted .tar archive can contain a symbolic link that points to something like / or ../../. When Jenkins follows that symlink and writes files through it, the file ends up somewhere completely different on the filesystem — not in the expected build directory.
Why Is This So Dangerous?
The Jenkins controller's filesystem is extremely sensitive. Two locations in particular are frightening targets:
JENKINS_HOME/init.groovy.d/ — Any .groovy script placed here gets executed automatically when Jenkins starts. An attacker who drops a malicious script here gets arbitrary code execution on the next Jenkins restart.
JENKINS_HOME/plugins/ — Placing a crafted plugin here can also result in code execution.
So the attack chain looks like this:
Attacker crafts malicious .tar → Gets it archived via Jenkins build → Symlink inside .tar points to init.groovy.d/ → Jenkins writes attacker's Groovy script there → Jenkins restarts → Script runs → Game over.
Who Can Exploit This?
Anyone with Item/Configure permission on a Jenkins job, or anyone who can control an agent process. In many teams, developers have configure permission on their own pipelines — this widens the attack surface considerably.
What Is the Fix?
Jenkins 2.555 and LTS 2.541.3 now refuses to extract any file whose resolved path lands outside the target directory. Symlinks in the archive path or at the target location are blocked during extraction.
CVE-2026-33002 — DNS Rebinding Attack on the WebSocket CLI (High)
A Bit of Background First
Jenkins has a built-in CLI (Command Line Interface). Since Jenkins 2.217, one way to use the CLI is over a WebSocket endpoint. This endpoint uses standard Jenkins authentication — API tokens, session cookies, etc.
Back in January 2024 (Jenkins 2.442 / LTS 2.426.3), the Jenkins team added origin validation to this WebSocket endpoint to prevent Cross-Site WebSocket Hijacking (CSWSH) attacks. The idea was simple: only requests coming from the Jenkins web interface itself should be allowed.
So What Went Wrong?
The origin validation computes the expected origin by reading the Host or X-Forwarded-Host HTTP request headers. And here is the flaw — those headers come from the attacker's request. An attacker can manipulate them.
More specifically, this opens the door to a DNS rebinding attack:
Attacker sets up a malicious website with a domain they control.
That domain's DNS record initially resolves to the attacker's server.
Victim visits the malicious website inside a corporate network where Jenkins is running on HTTP.
Attacker changes the DNS record to resolve to the Jenkins controller's IP address.
The browser's same-origin policy now considers the attacker's domain the same as Jenkins.
The malicious website establishes a WebSocket connection to Jenkins's CLI endpoint.
CLI commands run as the anonymous user.
How Bad Is It?
It depends entirely on what permissions your anonymous user has:
"Anyone can do anything" authorization → Full code execution via groovy or groovysh CLI commands.
Anonymous user has some permissions → Attacker can run whatever those permissions allow.
Anonymous user has no permissions → Attacker can still run who-am-i (low impact, but a foothold).
The vulnerability only works over plain HTTP, not HTTPS. But many internal Jenkins deployments — especially on private networks — do run over HTTP.
What Is the Fix?
Jenkins 2.555 and LTS 2.541.3 now computes the expected origin using the configured Jenkins URL from Manage Jenkins » System, instead of trusting request headers. If the Jenkins URL is not configured, WebSocket CLI connections are refused entirely.
If you cannot upgrade immediately: Go to Manage Jenkins » Security and make sure the anonymous user has no permissions. This eliminates the practical impact even if the bypass is possible.
CVE-2026-33003 and CVE-2026-33004 — LoadNinja Plugin API Key Exposure (Medium)
What Is the Problem?
The LoadNinja Plugin version 2.1 and earlier stores LoadNinja API keys in plain text inside job config.xml files on the Jenkins controller. Any user with Item/Extended Read permission — or anyone with file system access — can read these keys directly.
On top of that, the API key field on the job configuration form is not masked. This means the key is visible on screen, which increases the risk of it being captured through screen recordings or simply over someone's shoulder.
What Is the Fix?
LoadNinja Plugin 2.2 encrypts the stored API keys and masks them in the configuration form. Update the plugin and your existing keys will be re-encrypted automatically.
How to Update Jenkins
Option 1: Running Jenkins on Docker
If you are running the official Jenkins Docker image, updating is straightforward. Pull the latest image and recreate your container.
docker pull jenkins/jenkins:lts
docker stop jenkins
docker rm jenkins
docker run -d \
--name jenkins \
-p 8080:8080 \
-p 50000:50000 \
-v jenkins_home:/var/jenkins_home \
jenkins/jenkins:lts
Your jenkins_home volume preserves all your jobs, configurations, and plugins. You are not losing any data by recreating the container.
To verify the Jenkins version running inside your container:
docker exec jenkins jenkins --version
Option 2: Running Jenkins via Docker Compose
Update the image tag in your docker-compose.yml file:
version: '3.8'
services:
jenkins:
image: jenkins/jenkins:2.541.3
container_name: jenkins
ports:
- "8080:8080"
- "50000:50000"
volumes:
- jenkins_home:/var/jenkins_home
restart: unless-stopped
volumes:
jenkins_home:
Then run:
docker compose pull
docker compose up -d --force-recreate
Verify the version:
docker compose exec jenkins jenkins --version
Option 3: Jenkins Installed Directly on Your System
Download the latest version from the official Jenkins website: https://www.jenkins.io/download/
Target versions: Jenkins Weekly 2.555 or newer, Jenkins LTS 2.541.3 or newer.
On Debian or Ubuntu:
sudo apt-get update
sudo apt-get install jenkins
On Red Hat, CentOS, or Fedora:
sudo dnf update jenkins
After updating, restart Jenkins:
sudo systemctl restart jenkins
sudo systemctl status jenkins
Updating the LoadNinja Plugin
Go to Manage Jenkins → Plugins → Updates tab
Find LoadNinja Plugin in the list
Select it and click Download now and install after restart
Restart Jenkins
Quick Security Checklist While You Update
Disable anonymous access — Go to Manage Jenkins → Security and ensure the anonymous user has no permissions. This is the most effective short-term mitigation for CVE-2026-33002.
Force HTTPS — The DNS rebinding attack only works over plain HTTP. Enforcing HTTPS eliminates that attack vector entirely.
Review Item/Configure permissions — Limit who can configure jobs, especially on your Jenkins controller.
Audit your JENKINS_HOME/init.groovy.d/ directory — Check for any unexpected .groovy scripts that should not be there.
Rotate LoadNinja API keys — If you use the LoadNinja Plugin, treat your existing keys as potentially exposed and regenerate them from the LoadNinja dashboard.
Summary
The March 2026 Jenkins Security Advisory is one worth taking seriously. The tar symlink vulnerability can lead to code execution on your Jenkins controller through something as routine as archiving build artifacts — a step used in almost every pipeline. The DNS rebinding issue is a reminder that origin validation needs to be done with server-side data, not with headers an attacker can forge.
The fix for all three issues is available right now. Whether you run Jenkins on Docker, Docker Compose, or directly on your machine — the update path is clear and the steps are simple.
Update to Jenkins 2.555 (weekly) or LTS 2.541.3, and LoadNinja Plugin 2.2. Do it today.
Reference: https://www.jenkins.io/security/advisory/2026-03-18/
Join the conversation! Your thoughts help the community grow.