Database/Control plane, storage & DevOps

Renovate: mutual-TLS private key written to logs in cleartext when it appears outside its own field

CVSS 8.3CVE-2026-88883Control plane, storage & DevOpscurated

Impact

Renovate redacted the httpsPrivateKey field itself but not the same key value appearing elsewhere in config or in a log line under another key, so the full mutual-TLS private key lands in the bot's logs in cleartext. In a datacenter that fronts its internal registry, artifact store or Git platform with mTLS, that key is the credential Renovate uses to reach them - and bot logs are usually shipped to a cluster-wide logging stack that far more people and services can read than can read the secret store. Anyone with log access recovers the key and can impersonate the client to those endpoints. Only deployments that set hostRules[].httpsPrivateKey directly instead of via the documented secrets configuration are affected.

Who can reach it

Anyone who can read Renovate's logs: log aggregation users, anyone with kubectl logs on the namespace, or a service with read access to the log backend. No access to Renovate's configuration is needed.

What to do

Upgrade Renovate to 44.14.4 (Mend Renovate CE/EE 15.4.0, Helm chart 10.4.0) and restart the service, or as a workaround supply the key through the secrets configuration. Patching stops new leakage but does not undo it: treat any key that was logged as disclosed, reissue the client certificate and purge or restrict the retained logs.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-88883 https://github.com/renovatebot/renovate/security/advisories/GHSA-4hmw-qw74-vrhm https://www.vulncheck.com/advisories/renovate-before-44.14.4-tls-private-key-log-sanitisation

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.