GHSA-5VJQ-5JMG-39XQ: Remote Code Execution in Renovate via Bazel Lockfile Maintenance

Renovate is an automated dependency update tool that operates by parsing repository manifests and invoking ecosystem-native package managers to resolve and lock dependency versions. The vulnerability resides in the implementation of the bazel-module and bazelisk managers. These modules are responsible for maintaining Bazel dependencies and specifically handling MODULE.bazel configurations.

The flaw constitutes an Unsafe Command Execution vulnerability (CWE-94) stemming from the invocation of the Bazel CLI against untrusted inputs. When Renovate performs lockfile maintenance on a repository, it attempts to generate an updated MODULE.bazel.lock file by natively executing Bazel commands within the runner's execution environment.

Because Bazel configuration files allow for the execution of arbitrary scripts and commands during the workspace evaluation phase, invoking the Bazel CLI on untrusted repository contents without strict sandboxing permits remote code execution. This architectural trust boundary violation enables an attacker to compromise the runner infrastructure.

The root cause of this vulnerability lies in the execution semantics of the Bazel build system and Renovate's failure to require administrative consent before performing high-risk operations. Bazel utilizes Starlark, a dialect of Python, for its configuration and macro definitions within MODULE.bazel files.

During dependency resolution, Bazel executes these Starlark files to dynamically determine build graphs and fetch external dependencies. Starlark macros can invoke host system commands via functions like repository_ctx.execute. When a user runs a Bazel command that forces dependency evaluation, any logic embedded in the MODULE.bazel file executes within the context of the host process.

When lockFileMaintenance is enabled for Bazel managers, Renovate executes the command bazel mod deps --lockfile_mode=update. This command explicitly commands Bazel to evaluate the dependencies defined in the repository's MODULE.bazel file and generate a corresponding lockfile.

Prior to version 43.102.11, Renovate issued this command indiscriminately whenever it encountered a relevant manifest. The system trusted the repository contents implicitly, failing to classify the operation as an unsafe execution. This oversight provided a direct path for repository-supplied code to execute natively on the CI/CD runner hosting the Renovate instance.

In versions prior to the patch, the lib/modules/manager/bazel-module/lockfile.ts component directly executed the Bazel CLI tool using an internal execution wrapper. The code path retrieved the dependencies and formulated the bazel mod deps command without verifying the global security configuration.

// Conceptual representation of vulnerable logic
export async function updateLockFile(config: LockFileConfig): Promise<UpdateLockFileResult> {
  const cmd = 'bazel mod deps --lockfile_mode=update';
  // Flaw: Execution proceeds without checking allowedUnsafeExecutions
  const result = await exec(cmd, execOptions);
  return { lockFile: result.stdout };
}

The remediation implemented in pull request #42323 addresses this by enforcing an explicit opt-in mechanism for high-risk executions. The patch modifies the lockfile generation logic to interrogate the GlobalConfig object before allowing the Bazel execution to proceed.

// Conceptual representation of patched logic (#42323)
export async function updateLockFile(config: LockFileConfig): Promise<UpdateLockFileResult> {
  const allowedExecutions = GlobalConfig.get('allowedUnsafeExecutions') || [];
  
  if (!allowedExecutions.includes('bazelModDeps')) {
    logger.warn('Bazel command, bazel mod deps --lockfile_mode=update, was requested to run, but bazelModDeps is not permitted in the allowedUnsafeExecutions');
    return { error: 'unsafe-execution-denied' };
  }
  
  const cmd = 'bazel mod deps --lockfile_mode=update';
  const result = await exec(cmd, execOptions);
  return { lockFile: result.stdout };
}

Additionally, the patch updates the configuration schema, adding bazelModDeps to the allowedValues for the allowedUnsafeExecutions array. This ensures that only instance administrators who explicitly modify the runner's configuration can authorize the potentially dangerous Bazel execution phase.

Exploiting this vulnerability requires the attacker to introduce a malicious repository into the operational scope of a vulnerable Renovate instance. This is typically achieved by hosting a public repository and configuring Renovate to scan it, or by submitting a pull request containing malicious modifications to a repository actively managed by Renovate.

The attacker constructs a specialized payload within the MODULE.bazel file. This payload leverages standard Starlark functions designed for repository rules. By defining a custom repository rule that utilizes the execute method, the attacker can specify arbitrary shell commands to be run by the underlying operating system during the dependency resolution phase.

When Renovate begins its scheduled lockfile maintenance run, it identifies the need to update the MODULE.bazel.lock file. Renovate issues the bazel mod deps --lockfile_mode=update command. Bazel parses the malicious configuration, encounters the execution directive, and executes the payload with the privileges of the Renovate user on the host system.

The impact of this vulnerability is critical, directly leading to unauthenticated remote code execution on the system hosting the Renovate CLI. In typical deployments, Renovate operates within a CI/CD environment or as a dedicated automation runner. These environments inherently possess elevated privileges and sensitive credentials necessary to interact with source code management systems and package registries.

Successful exploitation allows the attacker to extract environmental variables, SSH keys, GitHub Personal Access Tokens (PATs), and API tokens configured for the runner. With access to these credentials, the attacker can escalate privileges within the organization's development infrastructure.

Furthermore, an attacker could abuse the compromised runner to tamper with other repositories processed by the same Renovate instance. This introduces a severe supply chain risk, as the attacker could covertly inject malicious code or vulnerable dependencies into downstream projects managed by the organization.

The primary remediation for this vulnerability is upgrading the Renovate CLI to version 43.102.11 or later. The patch introduces a secure-by-default posture that categorically denies the execution of bazel mod deps unless explicitly permitted by the instance administrator.

For environments that actively utilize Bazel and require automated lockfile maintenance, administrators must explicitly opt-in to this behavior. This is accomplished by modifying the global (self-hosted) configuration file to include bazelModDeps within the allowedUnsafeExecutions array.

If the configuration is not updated, Renovate will gracefully degrade its functionality for Bazel modules. It will skip the lockfile update process and emit a warning to the logs: Bazel command, bazel mod deps --lockfile_mode=update, was requested to run, but bazelModDeps is not permitted in the allowedUnsafeExecutions. Administrators should monitor these logs to identify repositories impacted by the new security constraint.