CVE-2026-88883 in Renovate
Summary
by MITRE • 09/10/2026
Renovate is an automated dependency update tool. In versions before 44.14.4 (and Mend Renovate CE/EE images before 15.4.0 and the mend-renovate-enterprise-edition Helm chart before 10.4.0), log sanitisation for TLS private keys used for Mutual TLS was incomplete. While the value of hostRules[].httpsPrivateKey was redacted in the field itself, the same private key value was not redacted if it also appeared elsewhere — for example in another configuration option or in a log message under a key other than httpsPrivateKey — causing the full private key to be written to Renovate's logs in cleartext. This affects deployments that configure Mutual TLS through hostRules[].httpsPrivateKey without passing the value through the documented `secrets` configuration. Anyone able to read the resulting logs can recover the private key. The issue is fixed in Renovate 44.14.4, which redacts any value supplied as hostRules[].httpsPrivateKey wherever it appears in the logs; as a workaround, supply the key via the `secrets` configuration.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/10/2026
The vulnerability identified in Renovate versions prior to 44.14.4 represents a critical information disclosure flaw rooted in incomplete log sanitization mechanisms for Mutual TLS configurations. As an automated dependency update tool, Renovate frequently processes sensitive infrastructure credentials during its operational lifecycle. The specific defect lies within the handling of the hostRules[].httpsPrivateKey configuration parameter. While the application correctly redacted this value when it appeared directly under that specific key name, the sanitization logic failed to generalize across other contexts where the same private key material might be referenced. This oversight means that if a user configured Mutual TLS by passing the private key through alternative configuration options or if the key value was echoed in log messages under different keys, the full plaintext private key would be written directly to the application logs without any obfuscation.
This technical flaw creates a severe security risk for organizations relying on Renovate for dependency management, particularly those utilizing Mutual TLS to secure communication with upstream registries or internal services. The core issue is that anyone with read access to the system logs can extract these plaintext private keys. In many deployment environments, log files are accessible not only to application administrators but also to DevOps engineers, monitoring systems, and potentially third-party logging aggregators such as ELK Stack, Splunk, or cloud-native logging services. The exposure of a TLS private key effectively compromises the confidentiality and integrity of all communications secured by that certificate. Attackers with access to these logs could perform man-in-the-middle attacks against downstream dependencies or impersonate Renovate itself when interacting with package registries, thereby introducing malicious code into the software supply chain.
The vulnerability is primarily classified under CWE-532, which covers information exposure through log files, and aligns with ATT&CK technique T1078, specifically related to valid accounts being used for unauthorized access or data exfiltration if logs are compromised. The root cause stems from a lack of comprehensive context-aware redaction in the logging subsystem. Instead of treating sensitive credential values as immutable secrets regardless of their contextual key name, the application performed string matching only on specific configuration paths. This design decision failed to account for scenarios where developers might reuse variables or pass credentials through environment-specific wrappers that alter the log output structure but retain the underlying secret value.
To mitigate this vulnerability, immediate action is required for all deployments running versions of Renovate before 44.14.4, Mend Renovate CE/EE images before 15.4.0, and the mend-renovate-enterprise-edition Helm chart before 10.4.0. The recommended remediation strategy involves upgrading to version 44.14.4 or later, which implements robust redaction logic that masks any value supplied as hostRules[].httpsPrivateKey regardless of where it appears in the log output. For organizations unable to upgrade immediately due to compatibility constraints, a critical workaround is available: users must configure their Mutual TLS settings by passing the private key through the documented secrets configuration mechanism rather than directly via hostRules or other exposed parameters. This ensures that the logging subsystem treats the value as a secret and applies appropriate masking protocols consistently across all log entries.
Furthermore, organizations should conduct an audit of existing logs to determine if any plaintext private keys were previously written during the window of vulnerability exposure. If such data is found, it must be considered compromised, necessitating the rotation of affected TLS certificates and private keys immediately. Access controls for log storage systems should also be reviewed to ensure that only authorized personnel have read access, minimizing the blast radius in case future vulnerabilities arise. Adhering to these mitigation steps ensures that Renovate continues to operate securely while maintaining compliance with industry standards for credential management and secure logging practices.