You updated Docker Desktop after its October security fix. But the diagnostic bundle you sent with a support request last week may still be sitting in your downloads folder—or in a synced drive.
Docker says Desktop versions before 4.97.0 could write third-party API keys and OAuth access tokens to local logs and diagnostic bundles. The update fixes the issue and cleans up certain host logs, but separately saved or shared copies need their own review. That is a reason to check, not evidence that anyone accessed a credential.
- Does This Apply to Your Setup?
- The 10-Point Docker Desktop Cleanup Checklist
- Confirm the product and current version
- Look back at versions used
- Identify integrations and credential types
- Update Desktop and note its cleanup behavior
- Review remaining local logs
- Find exported diagnostic bundles
- Check support tickets and other shared copies
- Look in synced folders and backups
- Handle a credential only if you find one
- Record completion and verify services
- A Worked Example: One Diagnostic Archive, Three Copies
- When Can You Close the Checklist?
- Sources and related guides
Does This Apply to Your Setup?
The advisory concerns Docker Desktop. Docker Engine running natively on Linux is a different product; do not assume this Desktop notice applies to it. Check the advisory for the product you actually use.
| Your setup | What to do |
|---|---|
| Docker Desktop on macOS, Windows or Linux | Check the version history and any logs or diagnostics made with Desktop before 4.97.0. Docker specifically calls out copies created or shared with 4.96.x or earlier. |
| Docker Engine installed directly on Linux | This Desktop notice does not establish that your Engine installation is affected. Check Docker Engine advisories for your version and distribution. |
| You updated to Desktop 4.97.0 or later | The update includes cleanup of existing host logs and crash dumps. Separately exported bundles and copies kept or shared elsewhere still warrant review. |
Docker notes that versions 4.94.0 and 4.95.0 addressed known logging paths. Its notice still asks users with copies from 4.96.x or earlier to delete or sanitize those copies. Check the current Docker security notice for the exact scope and later updates. Docker also says the OAuth tokens in this notice are not Docker account tokens.
The 10-Point Docker Desktop Cleanup Checklist
Use each card as a small task. Tick Mark checked after you record the evidence; open Show evidence and next step for guidance. These checkboxes work in the page and are not saved as a compliance record.
Confirm the product and current version
Open Docker Desktop’s version or About screen. Confirm you are checking Desktop, not Docker Engine alone.
Show evidence and next step
Record: Product, operating system, installed version and date checked.
Decide: If the version is earlier than 4.97.0, update through Docker’s supported channel. If you cannot update, consult Docker’s notice and your administrator.
Look back at versions used
Review available update history, managed-device records or your notes. Check whether Desktop 4.96.x or earlier was used to create diagnostic files.
Show evidence and next step
Record: The oldest relevant version and approximate date. A version alone does not show that a credential was captured.
Decide: If you cannot establish the history, continue with the copy review. Ask your IT administrator if devices are centrally managed.
Identify integrations and credential types
List third-party services used with Docker Desktop during the relevant period, such as connected APIs or development tools. Include third-party API keys and OAuth tokens. Docker says this notice does not concern Docker account tokens.
Show evidence and next step
Record: Service names and credential owners. Never put secret values in the checklist.
Decide: If the owner is unclear, ask the relevant service or security team before taking action.
Update Desktop and note its cleanup behavior
Confirm that the installed version is 4.97.0 or later. Read Docker’s description of the cleanup included in that release.
Show evidence and next step
Record: Installed version and update date.
Decide: Treat the update as fixing the Desktop issue and cleaning certain host logs. Continue to check exported archives and copies outside those logs.
Review remaining local logs
Use Docker’s current guidance for your operating system to determine whether additional Docker Desktop log copies remain. Paths can differ across macOS, Windows and Linux.
Show evidence and next step
Record: Which locations or sources you checked and whether you found copies. Do not paste log contents into a public issue or chat.
Decide: Delete or sanitize copies according to Docker’s notice and your organization’s retention rules. If logs may be needed for an investigation, restrict access and ask the security owner before deleting them.
Find exported diagnostic bundles
Check the places where you usually save downloads and support files for diagnostic bundles created before the update.
Show evidence and next step
Record: Approximate creation date, filename and current location. Do not copy any secret into your notes.
Decide: If you no longer need the bundle, remove it under your normal device policy. If it must be kept, restrict access and sanitize it through an approved process.
Check support tickets and other shared copies
Recall whether you attached a diagnostic bundle to a Docker support request, internal ticket, email or team chat. Review the attachment or its access settings where you have permission.
Show evidence and next step
Record: The ticket or repository reference, recipient group and whether the file is still accessible. Do not download and forward it just to inspect it.
Decide: Ask the support or platform owner how to remove or restrict an attachment when possible. For copies outside your control, use the receiving organization’s process.
Look in synced folders and backups
Review cloud-synced folders, shared drives and backup locations where local logs or diagnostic archives may have been copied.
Show evidence and next step
Record: Services checked, relevant date range and any retention or deletion limits.
Decide: Remove or restrict copies under the service’s controls and your retention policy. Deleting a local file may not remove separately synced or retained copies.
Handle a credential only if you find one
If an authorized review confirms a credential value is present, identify its provider, owner, permissions and whether it remains active. Do not paste it into another tool to test it.
Show evidence and next step
Record: Credential type, owner, scope and where it was found. Use a redacted reference instead of the value.
Decide: If exposure is confirmed, revoke or rotate the credential through its provider, update dependent applications and verify they work. OWASP’s Secrets Management guidance covers credential lifecycle and revocation. A file’s presence alone does not prove access.
Record completion and verify services
Review the devices, local files, shared locations and credentials that were in scope. After any credential change, confirm the expected Docker integrations still work.
Show evidence and next step
Record: Checks completed, the responsible owner, outstanding copies and next review date. Keep the record redacted.
Decide: Close the task only when each known copy has an owner and documented outcome. Verify service access after rotating a secret.
A Worked Example: One Diagnostic Archive, Three Copies
Hypothetical scenario: Before updating Docker Desktop, an engineer creates a diagnostic archive. They attach it to a support ticket, then save a copy in a folder synchronized to the team cloud drive.
The engineer updates Docker Desktop to 4.97.0. That does not answer whether the ticket attachment remains available or whether the cloud copy persists. They check each location, ask the ticket owner about removal, and apply the team’s retention process to the synced copy.
If a credential is found, they record its owner and scope without copying its value into the incident notes. The credential owner decides whether to revoke or rotate it. This example illustrates a workflow; it is not a report of a real customer incident.
When Can You Close the Checklist?
| Finding | Next step | What it does not prove |
|---|---|---|
| A credential is found | Identify owner and permissions; follow the provider’s process to revoke or rotate if exposure is confirmed. | Its presence alone does not show that anyone used it. |
| An archive was shared, contents unknown | Ask the recipient or ticket owner about access, retention and removal; escalate internally if needed. | You cannot conclude that it contained a credential. |
| A local copy was removed | Check known attachments, synced folders and retained backups separately. | Local cleanup does not remove every other copy. |
| Nothing found in checked locations | Document the locations and date range you reviewed. | A limited search cannot prove that no copy exists anywhere. |
Sources and related guides
- Docker security notice for CVE-2026-114409 — affected product, update and guidance for old copies.
- OWASP Secrets Management Cheat Sheet — credential lifecycle, rotation and revocation.
- Linux Server Security Checklist — broader VPS security checks.
- Linux Server Change Checklist — preparing and documenting server changes.
- How to Read Linux Service Logs with journalctl — inspecting Linux service logs where applicable.
Docker’s notice was checked October 31, 2026. The worked example is hypothetical. This checklist does not determine whether a credential was accessed; investigate confirmed findings with the credential owner or security team.
