New Critical Jenkins Vulnerabilities Put CI/CD Servers at Risk of RCE Exploits

Jenkins disclosed a critical security advisory addressing multiple vulnerabilities impacting its core automation server and the LoadNinja plugin.

These flaws pose severe risks to CI/CD environments, including arbitrary file creation, credential exposure, and remote code execution (RCE).

As Jenkins controllers often possess elevated privileges across enterprise networks, administrators must prioritize patching to safeguard build pipelines against exploitation.

Archive Extraction and Symbolic Link Exploitation

The most critical threat involves CVE-2026-33001, a high-severity arbitrary file creation vulnerability affecting Jenkins core versions 2.554 and LTS 2.541.2 and earlier.

The root cause stems from Jenkins’ symbolic link processing during .tar and .tar.gz archive extraction.

This vulnerability allows attackers to craft malicious archives that write files to arbitrary locations on the controller’s filesystem, constrained only by the Jenkins service’s assigned permissions.

If attackers have item configuration or agent process control privileges, they can exploit the “Archive the artifacts” post-build action. By escaping the target directory, threat actors can deploy malicious Groovy scripts to the JENKINS_HOME/init.groovy.d/ directory or unapproved tools to the JENKINS_HOME/plugins/ folder.

This results in full remote code execution on the Jenkins controller upon service restart or file processing.

DNS Rebinding in WebSocket CLI

Another high-severity vulnerability, CVE-2026-33002, involves a DNS rebinding flaw bypassing origin validation in the Jenkins CLI WebSocket endpoint.

This security measure originally aimed to prevent cross-site WebSocket hijacking (CSWSH), but relied unsafely on the Host or X-Forwarded-Host headers.

Attackers can exploit this by deceiving a victim into visiting a malicious site that employs DNS rebinding to resolve to the Jenkins controller’s internal IP address. This enables an untrusted origin WebSocket connection.

If the Jenkins instance is accessible via plain HTTP and anonymous users hold elevated permissions, attackers can execute administrative CLI commands.

This access can readily escalate to arbitrary code execution using Jenkins’ built-in Groovy capabilities (groovy and groovysh commands), fully compromising the server.

The LoadNinja plugin suffers from two medium-severity flaws tracked as CVE-2026-33003 and CVE-2026-33004. Versions 2.1 and earlier store API keys unencrypted within job config.xml files on the Jenkins controller, as reported by Jenkins.

The plugin also fails to mask these keys in the job configuration UI.

This oversight allows any user with extended read permissions or direct filesystem access to capture sensitive credentials and potentially pivot into external testing environments.

To secure infrastructure, administrators should immediately upgrade to Jenkins weekly version 2.555 or Jenkins LTS version 2.541.3.

These patched releases introduce strict path validation for archive extraction, explicitly rejecting files outside the target directory or via symbolic links.

They also enforce CLI origin checks based on the officially configured Jenkins URL rather than manipulable HTTP headers.

Organizations using LoadNinja must update the plugin to version 2.2, which ensures API keys are encrypted and properly masked.

If immediate updates are impossible, security teams should implement controller authentication, revoke all permissions from the anonymous user role, and restrict Jenkins access exclusively through HTTPS to minimize attack surface.