CVE-2026-114409 in Docker
Summary
by MITRE • 10/27/2026
Docker Desktop before version 4.97.0 could write third-party API keys and OAuth access tokens in cleartext to local application logs and diagnostics bundles due to insufficient IPC payload redaction. An attacker with read access to these files could obtain the credentials. These OAuth tokens are not Docker account tokens. Docker Desktop 4.94.0 and 4.95.0 addressed the known logging paths, but logs containing credentials can remain after upgrading. Docker Desktop 4.97.0 fixes the issue and includes cleanup of existing host logs and crash dumps.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/27/2026
Docker Desktop versions prior to 4.97.0 contained a significant security vulnerability related to insufficient inter-process communication payload redaction, which resulted in the logging of sensitive third-party API keys and OAuth access tokens in cleartext. This flaw allowed credentials intended for external services to be persisted locally on the host system within application logs and diagnostic bundles without encryption or masking. The issue specifically affects non-Docker account tokens, meaning that while Docker's own authentication mechanisms may have been secured, any integrations using third-party APIs were exposed through this logging mechanism. An attacker with read access to these local files could extract these credentials, potentially gaining unauthorized access to external services and data associated with the user's Docker environment.
The operational impact of this vulnerability is severe due to the nature of OAuth tokens and API keys as high-value targets for credential theft. Once obtained, these tokens can be used by an attacker to impersonate the legitimate user across various third-party platforms, leading to potential data breaches, unauthorized transactions, or further lateral movement within connected systems. The persistence of logs containing credentials even after upgrading from versions 4.94.0 and 4.95.0 highlights a critical gap in remediation strategies during incremental updates. While earlier patches addressed known logging paths, they failed to account for all potential vectors where sensitive data could be written or retained, leaving users vulnerable unless they performed additional manual cleanup steps that were not explicitly documented as mandatory for full security assurance.
This vulnerability aligns with CWE-532, which covers the insertion of sensitive information into log files, and reflects a failure in proper input validation and sanitization during inter-process communication handling within the Docker Desktop application architecture. From an ATT&CK perspective, this scenario facilitates Credential Access via Local Logging mechanisms, allowing adversaries to harvest secrets directly from the host environment without needing elevated privileges beyond file read access. The inclusion of cleanup procedures for existing host logs and crash dumps in version 4.97.0 underscores the necessity of not only patching the code path but also actively removing previously generated artifacts that may still contain compromised data, ensuring a complete remediation cycle rather than just preventing future leaks.