Docker package signature bypass in Docker Desktop for Windows enables LocalSystem execution

Before 4.92.0, Docker Desktop for Windows did not verify the signature of a package supplied to Docker Desktop Installer.exe install -package. An attacker able to provide a crafted package and convince a user to approve the Docker-signed UAC prompt could execute attacker-controlled installer actions as LocalSystem.

• Docker Desktop for Windows: The CNA identifies the affected semver range as 0 through less than 4.92.0, with a default status of unaffected outside the declared range.
• The record identifies 4.92.0 as the boundary after the affected range. It does not establish the status of every parallel or later branch without separate verification.

Docker Desktop for Windows does not verify the signature of a package supplied through Docker Desktop Installer.exe install -package before executing package-controlled installer actions. This is CWE-347, an improper verification of a cryptographic signature for externally supplied input. The attacker must be able to provide a crafted package and convince a user to approve the Docker-signed UAC prompt. The attack path is local, requires low privileges and active user interaction, and the record characterizes its complexity as low. If successful, attacker-controlled installer actions can execute as LocalSystem. The available evidence does not describe the package format, signature-verification API or library, or how the package is delivered to the target system.

This is a local attack path, not a remote path established by the record. The attacker must be able to provide a malicious package, has low privileges on the system, and requires the user to actively approve a Docker-signed UAC prompt. The record describes low attack complexity and active user interaction. The record does not identify a public exploit; its available enrichment records exploitation as none, but that does not prove exploitation cannot occur elsewhere.

Successful exploitation allows attacker-controlled installer actions to run as LocalSystem on Windows. This could provide broad control of the affected host and could affect data, software, services and Docker workloads within that account's reach. The record describes high impact to confidentiality, integrity and availability. It does not establish lateral movement, impact beyond the compromised endpoint or evidence of actual exploitation.

The flaw can turn an apparently legitimate UAC approval into execution of untrusted installer actions with the highest Windows service-account privileges on the endpoint. Potential consequences include loss of confidentiality, integrity or availability for the host and Docker workloads that depend on it. Organizations with developer workstations or other Windows systems running Docker Desktop should prioritize identifying affected installations and controlling the use of externally supplied packages. The supplied evidence does not name a victim, campaign or specific breach.

1. Upgrade Docker Desktop for Windows to 4.92.0, which the record identifies as the boundary after the affected range.
2. Until updated, do not run Docker Desktop Installer.exe with untrusted -package files.
3. If deployment tooling uses another release branch, verify that branch's fix status with Docker before deployment.
4. Review affected endpoints for use of the package-install path and investigate packages from unknown sources. The record provides no additional mitigation steps or specific indicators of compromise.

1. Inventory Windows systems running Docker Desktop and flag installations that fall within the CNA-declared affected range.
2. Where endpoint telemetry is available, search for executions of Docker Desktop Installer.exe with install -package, then identify the provenance and trust level of the supplied package.
3. Review UAC events and installer activity occurring immediately after a user approves a Docker-signed prompt, where the telemetry records those details.
4. Investigate packages installed through this path to determine whether their signatures were validated before execution.
5. The record provides no specific IOC or log event. The absence of matching log evidence does not establish that a system is safe.