Which versions of Docker Desktop are affected by EUVD-2026-34033?

Docker Desktop versions 4.33.0 through 4.75.x contain a high-severity denial-of-service vulnerability (CVSS 8.2) that allows any low-privileged user inside a container to crash the underlying Linux…. A patch is available.

How to fix or mitigate EUVD-2026-34033?

Within 24 hours: Audit inventory to identify all systems running Docker Desktop versions 4.33.0-4.75.x, particularly development workstations and CI/CD agents. Within 7 days: Apply the latest Docker Desktop patch released by vendor to all affected systems. Within 30 days: Verify 100% of Docker Desktop installations are updated and confirm no instances remain on vulnerable versions.

Docker Desktop EUVD-2026-34033

Q: What is the CVSS score of EUVD-2026-34033?

EUVD-2026-34033 has a CVSS 4.0 base score of 8.2 (High). CVSS vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:U/V:X/RE:X/U:X. EPSS exploitation probability: 0.0%.

| CVE-2026-8936 HIGH

Uncontrolled Recursion (CWE-674)

2026-06-02 Docker

GHSA-m3jp-gxgq-rpr9

Docker Information Disclosure

8.2

CVSS 4.0 · NVD

Severity by source

NVD PRIMARY

8.2 HIGH

CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:U/V:X/RE:X/U:X

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:U/V:X/RE:X/U:X

Attack Vector

Local

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Analysis Generated

Jun 03, 2026 - 00:05 vuln.today

Patch available

Jun 02, 2026 - 23:01 EUVD

CVSS changed

Jun 02, 2026 - 22:22 NVD

8.2 (HIGH)

CVE Published

Jun 02, 2026 - 21:09 nvd

UNKNOWN (no severity yet)

DescriptionCVE.org

Fixed a VM panic caused by unbounded recursion in the grpcfuse kernel module when a container created deeply nested directories on a bind-mounted host folder and triggered a dentry invalidation event. This issue has been fixed in Docker Desktop 4.76.0.

AnalysisAI

Denial of service in Docker Desktop versions 4.33.0 through 4.75.x allows a local low-privileged user inside a container to crash the underlying Linux VM by triggering unbounded recursion in the grpcfuse kernel module. The flaw is exercised by creating deeply nested directories on a bind-mounted host folder and forcing a dentry invalidation event, which panics the virtualization layer that backs the entire Docker engine. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV.

Technical ContextAI

Docker Desktop uses grpcfuse, a custom FUSE-based filesystem driver, to share host directories into the Linux virtual machine that runs the Docker engine on macOS and Windows. The vulnerability is rooted in CWE-674 (Uncontrolled Recursion): when the grpcfuse kernel module processes a dentry (directory entry) invalidation for a path with sufficient nesting depth, the invalidation walks the dentry tree recursively without any bound, blowing the kernel stack and panicking the VM. Because bind-mounts let an unprivileged container author control directory structure on the host-shared volume, the recursion source is reachable from inside any container that has a host bind mount.

RemediationAI

Upgrade Docker Desktop to vendor-released patch version 4.76.0 or later, as documented in the Docker Desktop release notes at https://docs.docker.com/desktop/release-notes/#4760. If immediate upgrade is not feasible, avoid using host bind mounts from untrusted containers or switch the file-sharing implementation away from grpcfuse where the option is available (for example, VirtioFS on macOS or the WSL2 backend on Windows), which removes the vulnerable code path but may change file-sharing performance characteristics and permission semantics. As an additional compensating control, restrict who can create or run containers on shared Docker Desktop hosts (CI runners, lab machines) so that an untrusted user cannot trigger the panic, accepting the trade-off of reduced self-service for developers.