Answer in brief
CVE-2026-88883 records a Unknown severity vulnerability in Renovate before 44.14.4 TLS Private Key Log Sanitisation. The current sources do not mark it as known exploited. The current feed maps renovatebot/renovate (generic), renovatebot/renovate (generic), renovatebot/renovate (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps renovatebot/renovate (generic), renovatebot/renovate (generic), renovatebot/renovate (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| renovatebot/renovategeneric | >=0 <44.14.44 | 44.14.44 |
| renovatebot/renovategeneric | >=0 <15.4.0 | 15.4.0 |
| renovatebot/renovategeneric | >=0 <10.4.0 | 10.4.0 |
Published upstream
Sep 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 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.
Quoted source text, attributed separately from HOL analysis.