Docker Desktop 4.97.0 Fixes Credential Leakage—but Copies May Remain

Short answer: Docker Desktop users on versions before 4.97.0 should update, then separately review diagnostics bundles and copied logs. The update cleans existing host logs and crash dumps, but Docker explicitly warns that files generated, shared, or stored elsewhere may still contain third-party credentials.

This is the practical distinction in CVE-2026-114409: patching closes the known logging path and cleans files on the host, while incident response still has to account for copies outside that cleanup boundary.

What Docker disclosed

Docker's security announcement says insufficient IPC payload redaction could write third-party API keys and OAuth access tokens in cleartext to local application logs and diagnostics bundles. An attacker needs read access to those files to obtain the credentials. The OAuth tokens described here are not Docker account tokens.

The CVE record marks Docker Desktop versions from 4.39.0 up to, but not including, 4.97.0 as affected. It assigns a CVSS 4.0 score of 5.7 (Medium), with local attack access and low privileges represented in the vector. NVD independently republishes the affected range and currently labels its own analysis as awaiting enrichment.

Docker says releases 4.94.0 and 4.95.0 addressed known logging paths, but credential-bearing logs could survive an upgrade. Version 4.97.0, released October 26, fixes the issue and adds cleanup of existing host logs and crash dumps.

The patch boundary matters more than the headline

The exposure is local-file based, not a claim that credentials were remotely extracted from every Docker Desktop installation. Risk depends on whether sensitive third-party credentials traversed the affected IPC path and whether someone else could read the resulting logs or bundles.

The remediation has two different scopes:

• On-host remediation: install Docker Desktop 4.97.0 or later so the vulnerable path is fixed and Docker's cleanup runs against existing host logs and crash dumps.
• Off-host response: find diagnostics bundles or logs that were exported, uploaded to a ticket, attached to chat, archived, backed up, or copied to another machine. The local updater cannot be assumed to clean those copies.

That second scope is why “updated successfully” is not the same as “all historical exposure is resolved.”

Who should treat this as a credential incident

Prioritize review when a developer workstation or shared build machine both ran an affected Docker Desktop version and handled valuable third-party credentials. Examples include cloud-provider API keys, source-control tokens, CI/CD credentials, observability tokens, or OAuth access tokens used by local developer tools.

The case becomes more urgent when diagnostics were shared with people or systems outside the credential owner's control, when local logs were collected centrally, or when endpoint permissions allowed other users to read them. Conversely, an affected version alone does not prove that any credential was logged or accessed.

A proportionate response

1. Record the current version. Confirm whether the workstation is below 4.97.0 before changing it, so the response has a defensible affected-state record.
2. Update to 4.97.0 or later. Use Docker's supported update path and confirm the installed version afterward.
3. Inventory exported artifacts. Search support-ticket systems, shared drives, chat attachments, local archives, backup destinations, and centralized log collectors for Docker Desktop diagnostics or copied application logs from the affected period.
4. Revoke or rotate based on evidence and reach. Credentials present in a bundle shared outside a trusted boundary deserve rotation. For uncertain cases, weigh the credential's privilege, lifetime, and auditability rather than rotating every secret blindly.
5. Review provider audit logs. Where available, look for use from unexpected principals, locations, or times. Rotation stops future use; it does not explain past use.
6. Sanitize retained bundles. Docker's release notes advise deleting or sanitizing diagnostics generated or shared with Docker Desktop 4.96.x or earlier, as well as copies of logs kept elsewhere.

What not to infer

• The Medium score does not make every environment low priority; credential privilege and distribution can raise the business impact.
• The CVE does not say Docker account tokens were exposed.
• An affected version is not proof of exploitation or even proof that a sensitive value reached a log.
• The 4.97.0 cleanup does not establish deletion from backups, ticket attachments, shared drives, or third-party log systems.
• Public vulnerability records do not currently provide evidence of widespread exploitation in the wild.

Related WealthLab context

For a different supply-chain transition, see our Docker Content Trust retirement migration guide. If you run AI tooling around local containers, our Docker Sandboxes trust-store analysis covers a separate certificate-chain risk. These incidents have different causes and should not be merged into one generic “Docker security” response.

Evidence boundary and sources

Evidence boundary: This is source-based impact analysis. WealthLab reviewed Docker's security announcement and release notes, the Docker-issued CVE record, and NVD's independent publication. We did not inspect an affected workstation, generate a diagnostics bundle, test credential leakage, or investigate a production environment. Operational steps above are scoped editorial guidance derived from the disclosed file and cleanup boundaries.

• Docker security announcement — fix date, affected behavior, cleanup scope, and exported-file warning; reviewed October 30, 2026.
• Docker Desktop 4.97.0 release notes — release-level remediation and deletion/sanitization guidance; reviewed October 30, 2026.
• CVE-2026-114409 record — affected range, CVSS 4.0 vector, and CNA description; updated October 27, 2026.
• NVD record — independent publication of the affected range and current enrichment status; published October 27, 2026.

This article has no affiliate links.