CVE-2026-33997

What it actually does

CVE-2026-33997 is an authorization bypass in Moby/Docker Engine plugin installation prior to version 29.3.1. During `docker plugin install`, the daemon is supposed to compare the privileges requested by a plugin with the privileges approved by the user. Because of flawed privilege comparison logic, the daemon can accept a plugin privilege set that differs from what the user approved. Plugins requesting exactly one privilege are also affected because the comparison may not be performed at all. The result is that a malicious or compromised Docker plugin can be installed with unintended privileges, potentially exposing sensitive host resources, network access, device access, or container/runtime control paths depending on the plugin’s declared capabilities.

Why it matters to the business

Successful exploitation can let an attacker trick an operator into installing a Docker plugin that receives more access than intended. In practical terms, this can lead to compromise of container hosts, exposure of sensitive data mounted or reachable from the host, unauthorized manipulation of containers, and potential lateral movement from build or runtime infrastructure. The CVSS score is moderate-high, but exploitation requires user interaction and a specific plugin-install workflow, and the current EPSS score is low with no known CISA KEV listing, so this should be prioritized for environments where Docker plugins are allowed, administrators install third-party plugins, or container hosts process sensitive workloads.

How an attack unfolds

An attacker publishes, distributes, or compromises a Docker plugin and crafts its privilege declarations so that the privileges shown to or approved by the user do not match the privileges ultimately accepted by the Docker daemon. The attacker then convinces an administrator or automated deployment workflow to run `docker plugin install` against that plugin. Due to the daemon-side privilege validation flaw, Docker Engine prior to 29.3.1 may approve the plugin with a privilege set the user did not actually authorize, including the special case where a plugin requests exactly one privilege and no comparison is performed. Once installed and enabled, the plugin can operate with the unintended privileges granted by the daemon, which may allow access to host resources, networking, storage, or other container-adjacent capabilities. The attacker’s next steps depend on the plugin privileges obtained, but may include collecting secrets, reading or manipulating host-accessible data, interfering with containers, or establishing persistence through the malicious plugin.

How to fix it

Upgrade Docker Engine/Moby to version 29.3.1 or later. Treat the daemon upgrade as the primary remediation because the defect is in Docker Engine’s privilege validation logic, not merely in individual plugins. Until upgraded, restrict Docker plugin installation to trusted administrators, block installation of third-party or unverified plugins, and avoid installing plugins from untrusted registries or sources. Review currently installed plugins and remove any that are unnecessary, untrusted, recently added without approval, or whose requested privileges do not match operational need. Where possible, enforce change control for plugin installation, require image/plugin provenance checks, and limit access to the Docker socket and Docker administrative commands.

How to confirm the fix worked

Confirm exposure by checking Docker Engine/Moby versions on systems that can install or run Docker plugins; versions prior to 29.3.1 are vulnerable. Validate remediation by confirming `docker version` or package manager output reports Docker Engine/Moby 29.3.1 or later. Enumerate installed plugins with `docker plugin ls` and inspect each plugin with `docker plugin inspect` to verify the plugin source, enabled state, and requested privileges. Confirm that only approved administrators or automation identities can run Docker administrative commands and access the Docker socket. If compensating controls were applied, test that unapproved users cannot execute `docker plugin install` and that installation from untrusted plugin sources is blocked by policy, network controls, or registry restrictions.

Typical attack path

1. Identify an organization or operator that uses Docker Engine versions prior to 29.3.1 and permits Docker plugin installation.
2. Create or compromise a Docker plugin with crafted privilege metadata designed to exploit the daemon’s flawed privilege comparison behavior.
3. Distribute the plugin through a registry, repository, documentation, support channel, dependency path, or social-engineering lure.
4. Induce an administrator or automation process to run `docker plugin install` for the malicious plugin.
5. Rely on the vulnerable Docker daemon to accept a privilege set that differs from the one the user approved, or to skip comparison for a single requested privilege.
6. Enable or cause use of the plugin so it can exercise the unintended privileges.
7. Use the plugin’s granted access to reach host resources, container data, network paths, or other sensitive runtime capabilities.

How to detect it

To determine whether exploitation may have already occurred, review Docker daemon logs, system journal logs, shell history, EDR command telemetry, package/container management logs, and SIEM records for Docker plugin installation or enablement activity. Focus on `docker plugin install`, `docker plugin enable`, plugin installations from unfamiliar registries or publishers, and plugins installed shortly before suspicious host, container, network, or data-access events. Use `docker plugin ls` and `docker plugin inspect` to identify enabled plugins, installation sources, and requested privileges; compare these against an approved plugin inventory. Investigate plugins requesting access to host paths, network namespaces, devices, mounts, or other sensitive capabilities that are not required for their business function. Look for unexpected Docker daemon restarts, plugin process creation, unusual outbound network connections from plugin-related processes, unexplained access to Docker socket paths, and changes to plugin state. Because there are no public reports of widespread exploitation or named threat actor activity from the provided data, detection should be behavior-focused rather than relying on known attacker infrastructure.

• docker plugin install
• docker plugin enable
• docker plugin disable
• docker plugin rm
• docker plugin ls
• docker plugin inspect
• /var/run/docker.sock
• /run/docker.sock
• /var/lib/docker/plugins/
• plugin install
• plugin enable
• dockerd

What your security team should do

• Upgrade Docker Engine/Moby to 29.3.1 or later on all hosts where Docker plugins can be installed or enabled.
• Inventory Docker plugin usage across container hosts and remove plugins that are unused, untrusted, or not explicitly approved.
• Review recent plugin installation events, especially installations from external registries or unfamiliar publishers.
• Restrict access to Docker administrative interfaces, including the Docker socket, to a minimal set of trusted administrators and automation workflows.
• Temporarily prohibit new third-party Docker plugin installations until affected hosts are upgraded and plugin governance is verified.
• Require provenance, publisher validation, and change approval for Docker plugins before installation.
• Monitor Docker daemon logs and shell history for `docker plugin install`, `docker plugin enable`, and unexpected plugin lifecycle activity.
• Prioritize remediation for shared build systems, production container hosts, and hosts that process secrets or sensitive data.