CVE-2026-92132 in Gradle Plugin
Summary
by MITRE • 09/16/2026
Jenkins Gradle Plugin 2.19.1252.v15196b_5a_6e10 and earlier requests build scan data from the build scan link detected in the build log, even when a Develocity server URL is configured in the global configuration, allowing attackers able to control the build log to capture the Develocity access key configured in the global configuration by having Jenkins connect to an attacker-specified URL.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in versions of the Jenkins Gradle Plugin prior to 2.19.1252.v15196b_5a_6e10 represents a critical security flaw rooted in improper validation and handling of external resources during build scan operations. This issue specifically affects environments where Develocity, formerly known as Build Scan, is configured for tracking Gradle builds. The core technical deficiency lies in the plugin's logic for retrieving build scan data. When a user configures a specific Develocity server URL within Jenkins global configuration settings, the expectation is that all communication regarding build scans will be directed exclusively to this trusted endpoint. However, the vulnerable implementation fails to strictly enforce this configuration when processing links found directly within the build logs generated by Gradle tasks. Instead of ignoring or validating these embedded URLs against the configured policy, the plugin blindly follows any link detected in the log output that appears to point toward a Develocity service.
This architectural oversight creates a severe path for credential theft and unauthorized data exfiltration. An attacker who has the ability to control or inject content into the build logs of a Jenkins job can exploit this behavior by embedding a malicious URL within the log output. This crafted link is designed to mimic a legitimate Develocity endpoint but actually points to a server under the attacker's control. When Jenkins executes the step that retrieves scan data, it initiates an HTTP request to this attacker-specified address. Crucially, because the plugin operates on behalf of the configured global settings, it attaches the sensitive access keys and authentication tokens associated with the legitimate Develocity instance to these outgoing requests. Consequently, as soon as the malicious server receives the connection, it captures these credentials in plaintext or via standard HTTP headers, depending on the configuration.
The operational impact of this vulnerability is significant, particularly for organizations relying on Jenkins for continuous integration and delivery pipelines that utilize Gradle. The compromise of Develocity access keys allows an attacker to gain unauthorized access to build metadata, dependency information, and potentially other sensitive artifacts stored or referenced within the Develocity platform. This can lead to further supply chain attacks, where compromised build data is used to inject malicious code into downstream projects or to steal proprietary intellectual property embedded in build reports. Furthermore, if these keys have broad permissions, the attacker could manipulate scan results, hide evidence of previous compromises, or disrupt the integrity of the software delivery pipeline by altering reported metrics and dependencies.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the plugin fails to adequately validate that external links conform to expected domains before processing them. It also relates closely to CWE-798 Use of Hard-coded Credentials in conjunction with improper access control mechanisms, although here the credentials are dynamically retrieved from configuration rather than hardcoded in source code. In terms of offensive security frameworks, this exploit maps directly to MITRE ATT&CK technique T1059 Command and Scripting Interpreter for log manipulation and T1078 Valid Accounts if the stolen keys provide persistent access to internal tools. The attack vector is classified as remote with low complexity but requires a specific prerequisite: the ability to write to build logs, which typically implies some level of initial compromise or injection capability within the CI/CD pipeline itself.
Mitigation strategies must prioritize immediate version upgrades and strict configuration enforcement. Organizations running affected versions should upgrade the Jenkins Gradle Plugin to version 2.19.1252.v15196b_5a_6e10 or later, where this logic has been corrected to respect global URL configurations exclusively. For environments that cannot immediately patch due to compatibility constraints, administrators can implement network-level controls such as firewall rules or proxy settings to block outbound connections from Jenkins agents and masters to unauthorized Develocity-like endpoints. Additionally, reviewing build log generation processes for injection vulnerabilities is essential to prevent the initial step of embedding malicious links. Regular auditing of plugin configurations and restricting write access to job definitions and build scripts can further reduce the attack surface by limiting who can influence the content processed by this vulnerable component.