The Jenkins project released a critical security advisory addressing multiple vulnerabilities in its core automation server and the LoadNinja plugin.
These flaws expose continuous integration and continuous deployment (CI/CD) environments to severe risks, including arbitrary file creation, credential exposure, and remote code execution (RCE).
Because Jenkins controllers often hold elevated privileges across enterprise networks, administrators must prioritize patching to secure their build pipelines against potential exploitation.
Archive Extraction and Symbolic Link Exploitation
The most severe threat stems from CVE-2026-33001, a high-severity arbitrary file creation vulnerability affecting Jenkins core versions 2.554 and LTS 2.541.2 and earlier.
The core issue lies in how Jenkins processes symbolic links when extracting .tar and .tar.gz archives.
This oversight allows attackers to craft malicious archives that write files to arbitrary locations on the controller’s filesystem.
The only limitation is the operating system file permissions assigned to the user running the Jenkins service.
If an attacker has permissions to configure items or control agent processes, they can exploit features like the “Archive the artifacts” post-build action.
By escaping the intended directory, threat actors can write malicious Groovy scripts directly to the JENKINS_HOME/init.groovy.d/ directory or deploy unapproved tools to the JENKINS_HOME/plugins/ folder.
This results in full remote code execution on the Jenkins controller when the service restarts or processes the new files.
DNS Rebinding in WebSocket CLI
Another high-severity flaw, CVE-2026-33002, involves a DNS rebinding vulnerability that bypasses origin validation in the Jenkins command-line interface (CLI) WebSocket endpoint.
Originally implemented to prevent cross-site WebSocket hijacking (CSWSH), the origin validation mechanism relied unsafely on the Host or X-Forwarded-Host HTTP request headers.
Attackers can exploit this by tricking a victim into visiting a malicious website that uses DNS rebinding to resolve to the Jenkins controller’s internal IP address.
This effectively establishes a WebSocket connection from an untrusted origin. If the Jenkins instance is accessible over plain HTTP and anonymous users have elevated permissions, attackers can execute administrative CLI commands.
Depending on the environment’s authorization strategy, this access can easily escalate to arbitrary code execution through built-in Groovy scripting capabilities (groovy and groovysh commands), completely compromising the server.
The LoadNinja plugin suffers from two medium-severity vulnerabilities tracked as CVE-2026-33003 and CVE-2026-33004. Versions 2.1 and earlier store API keys unencrypted directly in the job config.xml files on the Jenkins controller, as reported by Jenkins.
Furthermore, the plugin fails to mask these keys in the graphical job configuration interface.
This oversight allows any user with extended read permissions, or direct filesystem access, to quickly capture sensitive credentials and potentially pivot into external testing environments.
To secure their infrastructure, administrators should immediately upgrade to Jenkins weekly version 2.555 or Jenkins LTS version 2.541.3.
These patched releases introduce stringent path validation for archive extraction, strictly refusing to extract files outside the target directory or through symbolic links.
They also enforce CLI origin checks based on the officially configured Jenkins URL rather than easily manipulated HTTP headers.
Organizations using LoadNinja must update the plugin to version 2.2, which ensures API keys are properly encrypted and masked.
If immediate updates are impossible, security teams should enforce authentication on all controllers, revoke all permissions from the anonymous user role, and ensure Jenkins is exclusively accessible via HTTPS to minimize the available attack surface.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
