Docker Desktop stops copying environment secrets into diagnostic logs
CVE-2025-6587 links shell completion to environment-variable disclosure in Desktop diagnostics on macOS and Linux.
Shell completion can become a disclosure path when diagnostic collection records more process context than a user expects. Docker Desktop 4.43.0 removes system environment variables from diagnostics after a flaw allowed those values to enter its diagnostic logs. The affected values can include credentials for systems unrelated to Docker.
The July 3 release notes identify the fix as CVE-2025-6587. Docker's CVE record, published the same day, supplies the conditions missing from the short release entry. It describes environment variables being recorded when shell auto-completion is used, with an attacker requiring read access to the resulting logs.
I associate Docker with making application environments repeatable. That makes this failure particularly relevant to its role on a developer machine. An environment can contain both ordinary build settings and access credentials, but a diagnostic collector should not treat those categories as equally suitable for export.
The disclosure moves a secret into another artifact
The CVE describes an unintended copy. A value present in the system environment becomes a value in a diagnostic log. That copy creates another place where a reader can obtain the credential, even if the original environment was available only in a narrower execution context.
Docker names API keys and passwords as examples. The vulnerability does not require those secrets to be credentials for a container registry. The environment can hold credentials for other services, which explains the advisory's concern about access to subsequent systems.
That is the central consequence of this disclosure. Someone reading a diagnostic log may gain a credential that authorizes an unrelated action elsewhere. The reader's original capability is access to the log. The copied credential can supply a different capability whose scope depends on the external service and the credential itself.
The record does not say that every use of completion exposed a usable secret. The environment must contain sensitive values for that particular consequence to arise. A resulting log must also become readable by the attacker. Retaining those conditions gives a more accurate description than treating shell completion alone as remote account compromise.
It also does not establish how every affected environment value reached every diagnostic artifact. The public description identifies the trigger and the class of copied information. Without an implementation account, a detailed story about a particular completion subprocess or serialization function would go beyond the available evidence.
macOS and Linux define the stated affected scope
Docker's record identifies Docker Desktop on macOS and Linux before 4.43.0 as affected. It does not list Windows in that affected platform entry. The product and platform scope should remain attached to the description when deciding which installations the advisory concerns.
The distinction between Desktop and Engine matters as well. Desktop 4.43.0 is the fixed product version named in this CVE. The release includes an Engine upgrade, but that does not make an arbitrary Engine version the identifier of the diagnostic collection fix.
This is useful when software inventories contain several Docker-related version numbers. An application can show a CLI version and a daemon version while Desktop has its own release number. The advisory addresses a Desktop diagnostics behavior, so the relevant comparison is with the Desktop version.
The record classifies the defect as CWE-532, insertion of sensitive information into a log file. That classification describes the mechanism directly. The failure is the additional stored representation of information that should not have entered a log in the first place.
It differs from a vulnerability requiring a malicious container to escape its isolation. The public record here describes a reader of logs obtaining environment secrets. Introducing a container escape into this explanation would confuse the access condition and the affected operation.
Diagnostic usefulness does not require a complete environment dump
A diagnostic log is useful because it records evidence about behavior. An environment dump can provide context, but its contents are not limited to harmless configuration. The flaw shows why collecting all available context can change the security properties of the resulting artifact.
The security boundary is therefore also a data selection boundary. The collector decides which information becomes durable diagnostic evidence. If that decision includes credentials, later restrictions on access to the original environment no longer account for every copy.
Docker's repair changes that collection decision. Starting with 4.43.0, Desktop no longer logs system environment variables as part of diagnostic collection. The public description supports that removal. It does not describe a new secret-name filter or claim that selected variable names receive special redaction.
Removing the source of the copy is different from guessing which values look sensitive. A variable's name cannot establish all the authority carried by its value. The stated fix avoids depending on such a classification for this part of diagnostic collection.
My preference is to keep build and runtime definitions explicit. That does not imply every input belongs in diagnostic output. A variable can be necessary for an operation while its value remains unnecessary for a record explaining whether the operation succeeded.
The update changes future collection
The fixed version prevents the described logging behavior. It does not follow that installing it changes the contents of artifacts already collected by an earlier version. A previously copied credential remains a separate object from the software that originally copied it.
That is why evaluating an exposure needs both the software version and the artifact history. The version tells whether the described collection behavior is present. Existing diagnostic files determine whether sensitive values were previously recorded and which readers could access those copies.
The public advisory does not establish a compromise of every affected installation. Read access to a relevant log is part of the attack conditions. Exposure assessment can therefore be specific about whether a sensitive value was present and whether the resulting artifact crossed an access boundary.
The same distinction applies to the authority of a copied credential. A log entry containing a setting with no external authority has a different consequence from one containing an active API credential. The CVE explains the possible cross-system impact without proving that a particular reader exercised it.
For this release, the concrete improvement is that Desktop stops recording system environment variables in diagnostics on the affected path. Shell completion remains a user convenience, while the collector no longer carries those environment values into its logs. The fixed Desktop version and the access history of earlier diagnostic artifacts answer the two separate questions raised by the disclosure.