CVE-2020-37267 in Renovateinfo

Summary

by MITRE • 08/19/2026

Renovate versions >=19.180.0 and <23.25.1, when used with Azure DevOps, may expose the bot's authorization token in server or pipeline logs because the git http.extraheader=AUTHORIZATION parameter is logged without redaction. Anyone with access to saved logs could obtain the bot credentials. Fixed in 23.25.1; Azure DevOps users should revoke and regenerate credentials if logs may have been exposed.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Analysis

by VulDB Data Team • 08/19/2026

The vulnerability identified in Renovate versions ranging from 19.180.0 up to, but not including, version 23.25.1 represents a critical information disclosure flaw when the tool is integrated with Azure DevOps pipelines. This issue stems from how Renovate handles authentication headers during Git operations within this specific cloud-based continuous integration and deployment environment. When Renovate executes pull requests or updates dependencies in repositories hosted on Azure DevOps, it utilizes an HTTP extra header to pass authorization credentials. Specifically, the configuration parameter git.http.extraheader is set with an AUTHORIZATION value containing a personal access token or bot credential required for repository access. The core technical flaw lies in the logging mechanism of Renovate and potentially the underlying Git client within this context, which records these command-line arguments and environment variables into standard output streams without performing any sanitization or redaction procedures.

This lack of input filtering results in the plaintext exposure of sensitive authorization tokens directly in server logs, pipeline run histories, and build artifacts stored by Azure DevOps. Since CI/CD platforms typically retain log data for auditing, debugging, and historical tracking purposes, these credentials become persistently available to anyone with read access to the repository or project logs. This scenario aligns closely with CWE-532, which classifies information exposure through log files, as well as CWE-798, involving the use of hardcoded credentials that are inadvertently exposed in runtime environments. The presence of these tokens in plain text transforms what should be a secure authentication process into a significant security risk, effectively bypassing access controls for any individual or automated system capable of viewing the pipeline logs.

The operational impact of this vulnerability is severe due to the high privilege level typically associated with bot accounts used by dependency management tools like Renovate. These tokens often possess write permissions on multiple repositories within an organization's Azure DevOps project, allowing them not only to read code but also to create pull requests and merge changes. An attacker or malicious insider who gains access to these logs could extract the valid authorization token and use it to authenticate against the Azure DevOps API independently of Renovate. This would enable unauthorized modifications to source code repositories, injection of malicious dependencies into projects, or further lateral movement within the organization's infrastructure by leveraging the bot's established trust relationships with other services.

To mitigate this risk, organizations must immediately revoke all existing tokens associated with affected Renovate instances and generate new credentials with minimal necessary privileges following the upgrade to version 23.25.1 or later. The fix implemented in the newer versions ensures that sensitive headers are properly masked during logging operations, preventing their leakage into persistent storage. Additionally, security teams should conduct a thorough audit of historical logs from affected systems to identify any potential exposure events and assess whether credentials were compromised prior to remediation. Implementing strict log rotation policies and restricting access to CI/CD logs based on the principle of least privilege can further reduce the attack surface for this type of information disclosure vulnerability, ensuring that even if future logging flaws occur, the blast radius remains contained.

Responsible

VulnCheck

Reservation

08/19/2026

Disclosure

08/19/2026

Moderation

accepted

CPE

ready

EPSS

0.00314

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!