This is a developer workstation self-own, not a wormable fire in the data center
CVE-2026-8936 is an uncontrolled recursion bug in Docker Desktop's grpcfuse kernel module. A container can trigger a Docker Desktop VM panic by creating very deep directory trees on a bind-mounted host folder and hitting a dentry invalidation path; the public CVE text says it is fixed in Docker Desktop 4.76.0, so the practical affected range is Docker Desktop versions before 4.76.0 on platforms where the grpcfuse file-sharing path is in play.
In real enterprise conditions this is not a top-tier emergency. The attacker already needs the ability to run a container on the target endpoint, then needs a bind mount into a shared host path, and the outcome is a local availability hit against that user's Docker Desktop VM rather than host compromise or broad lateral movement. That combination pushes this down from headline-grabbing CVE territory into a contained workstation/CI disruption problem.
4 steps from start to impact.
Gain code execution in a Docker Desktop container
docker run with a benign base image like alpine or busybox.- Target host runs Docker Desktop
- Attacker can execute
docker runor influence a container workload - Linux containers mode is in use
- This is post-initial-access; the attacker is already on the box or already controlling a developer workflow
- Many enterprise endpoints do not have Docker Desktop installed at all
- Some orgs restrict Docker Desktop to a smaller developer population
Obtain a writable bind mount into a shared host folder
-v $PWD:/mnt or --mount type=bind,src=<host-path>,dst=/mnt. A minimal PoC uses shell tooling like mkdir -p in a tight loop against the mounted path. Named volumes alone do not traverse the same host bind-mount path.- A host directory is shared and bind-mounted into the container
- The container can write into the mounted path
- No bind mount means no trigger path
- Read-only mounts reduce the usable attack surface for directory creation
- Workloads using named volumes or
tmpfsinstead of host binds are not on the hot path
docker inspect, or runtime policy engines, but they do not validate this specific recursion condition.Trigger deep recursion in grpcfuse with nested directory creation
grpcfuse. The public description does not reference a public exploit framework; ordinary shell utilities are sufficient. This is a reliability-focused DoS technique, not an exploit chain for privilege escalation.grpcfuseis the active file-sharing mechanism for the target workflow- The bind-mounted path can be mutated from inside the container
- If the deployment is using another file-sharing backend for that path, the trigger may not apply
- The attacker must hit a fairly specific filesystem behavior, not just write any file
- This is noisy from a filesystem-activity perspective
Crash the Docker Desktop VM and disrupt local workloads
- The vulnerable recursion path is reached successfully
- Docker Desktop is currently hosting active containers or services worth disrupting
- Impact stops at availability based on current public information
- Blast radius is usually one user workstation or one shared Desktop node
- Enterprise servers and Kubernetes worker fleets are generally not using Docker Desktop as the runtime
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found in the sources reviewed, and not listed in CISA KEV. |
|---|---|
| Proof-of-concept availability | No named public exploit repo or researcher PoC surfaced. Based on the CVE text, a bare-bones PoC likely needs only docker run, a writable bind mount, and recursive mkdir activity. |
| EPSS | No CVE-specific public EPSS value was confirmed from FIRST during this assessment; treat EPSS as unavailable/too new to rely on rather than as a risk reducer. |
| KEV status | No in CISA's Known Exploited Vulnerabilities catalog. |
| CVSS / vector interpretation | The user-supplied brief says there is no vendor/authority baseline severity to compare against, so this is scored here as a fresh operational assessment. The attack is effectively local, low-complexity, low-privilege, availability-only. |
| Affected versions | Public CVE text says the fix lands in Docker Desktop 4.76.0; practical read: Docker Desktop < 4.76.0 where the vulnerable grpcfuse file-sharing path is used. |
| Fixed versions | Upgrade to Docker Desktop 4.76.0 or later. No distro backport guidance was found because this is a Docker Desktop product issue, not a typical Linux distro package advisory. |
| Exposure population | Reachable population is naturally capped: this affects developer desktops and shared Desktop-style build hosts, not generic internet-facing services. Shodan/Censys-style exposure data is largely irrelevant because exploitation requires local container execution. |
| Disclosure date | 2026-06-02. |
| Reporter / credit | Credited in the public CVE mirror to Nitesh Surana of TrendAI Research / Trend Micro. |
noisgate verdict.
The decisive downgrading factor is attacker position: this is a post-initial-access local container issue, not something an unauthenticated remote attacker can reach across your fleet. Impact is real but narrow—an endpoint-scale Docker Desktop VM crash with availability loss, not host takeover or broad tenant escape based on current public evidence.
Why this verdict
- Post-initial-access requirement: exploitation starts only after the attacker can run or influence a container on the endpoint, which implies a prior compromise stage or trusted-user abuse.
- Reachability is narrowed by bind mounts: the vulnerable path depends on a writable host bind mount into the container, so named-volume-only workflows are not in the main blast zone.
- Impact is availability, not takeover: the public record describes a VM panic and Docker Desktop disruption, with no current evidence of host code execution, container escape, or confidentiality compromise.
Why not higher?
A higher rating would need one of three things that are missing here: unauthenticated remote reachability, host compromise, or active exploitation evidence. Instead, the chain stacks multiple prerequisites—local container execution, bind-mount presence, and the vulnerable file-sharing path—before it produces a one-node DoS.
Why not lower?
This is still more than cosmetic. On developer laptops, demo machines, or shared Desktop-backed build endpoints, a reliable Docker Desktop VM panic can kill active containers and disrupt work immediately. If you support many developers, the aggregate operational pain is real enough to keep it out of LOW.
What to do — in priority order.
- Prefer named volumes or
tmpfsfor untrusted workloads — Move disposable or semi-trusted containers off writable host bind mounts where feasible, because the vulnerable path is tied to host file sharing. For a MEDIUM finding there is no mitigation SLA, but this is the cleanest exposure reduction to fold into normal engineering work before the remediation window closes. - Restrict who can run Docker Desktop containers — Treat Docker Desktop like a privileged developer tool, not a general-purpose endpoint app. Tightening local group membership, image trust, and shared workstation use reduces the chance that a compromised user session can weaponize the bug; for MEDIUM, there is no mitigation SLA — go straight to planned control hardening inside the 365-day patch window.
- Monitor for abnormal bind-mounted directory churn — Hunt for containers hammering bind-mounted paths with extreme nested directory creation or causing repeated Docker Desktop backend/VM restarts. This will not prevent exploitation, but it gives you an early signal on shared build hosts and power-user laptops while you schedule patching.
- Turning on MFA does nothing for the exploit path once an attacker is already running local containers.
- A WAF or external network IDS is irrelevant; this is not an internet-reachable request/response flaw.
- Enhanced Container Isolation alone is not a fix; Docker documents that normal host directory mounts still work under ECI, and the bug lives in the Desktop file-sharing path rather than in a missing auth check.
Crowdsourced verification payload.
Run this on the target Docker Desktop host as the logged-in user who can invoke Docker Desktop. Save it as check_cve_2026_8936.py and run python3 check_cve_2026_8936.py; no admin rights are usually required, but the script needs the docker CLI and access to docker desktop version if available.
#!/usr/bin/env python3
# Check exposure to CVE-2026-8936 on Docker Desktop hosts.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import json
import os
import re
import subprocess
import sys
from pathlib import Path
FIXED_VERSION = (4, 76, 0)
def run(cmd):
try:
p = subprocess.run(cmd, capture_output=True, text=True, check=False)
return p.returncode, (p.stdout or '').strip(), (p.stderr or '').strip()
except Exception as e:
return 127, '', str(e)
def parse_semver(text):
m = re.search(r'(\d+)\.(\d+)\.(\d+)', text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def get_desktop_version():
candidates = [
['docker', 'desktop', 'version'],
['docker', 'desktop', 'version', '--format', 'json'],
]
for cmd in candidates:
rc, out, err = run(cmd)
if rc == 0 and out:
# Try JSON first
try:
data = json.loads(out)
for key in ('Version', 'version', 'desktopVersion'):
if key in data:
v = parse_semver(str(data[key]))
if v:
return v, 'docker desktop version'
except Exception:
pass
v = parse_semver(out)
if v:
return v, 'docker desktop version'
# Fallback: try local settings files that sometimes include Desktop metadata.
paths = []
home = Path.home()
if sys.platform.startswith('darwin'):
paths.append(home / 'Library' / 'Group Containers' / 'group.com.docker' / 'settings-store.json')
paths.append(home / 'Library' / 'Group Containers' / 'group.com.docker' / 'settings.json')
elif os.name == 'nt':
appdata = os.environ.get('APPDATA')
localapp = os.environ.get('LOCALAPPDATA')
if appdata:
paths.append(Path(appdata) / 'Docker' / 'settings-store.json')
paths.append(Path(appdata) / 'Docker' / 'settings.json')
if localapp:
paths.append(Path(localapp) / 'Docker' / 'settings-store.json')
else:
paths.append(home / '.docker' / 'desktop' / 'settings-store.json')
paths.append(home / '.docker' / 'desktop' / 'settings.json')
for p in paths:
try:
if p.exists():
text = p.read_text(encoding='utf-8', errors='ignore')
v = parse_semver(text)
if v:
return v, str(p)
except Exception:
continue
return None, None
def cmp_ver(a, b):
return (a > b) - (a < b)
def main():
version, source = get_desktop_version()
if not version:
print('UNKNOWN - Could not determine Docker Desktop version from CLI or local settings')
sys.exit(2)
version_str = '.'.join(map(str, version))
fixed_str = '.'.join(map(str, FIXED_VERSION))
if cmp_ver(version, FIXED_VERSION) < 0:
print(f'VULNERABLE - Docker Desktop {version_str} detected via {source}; fixed in {fixed_str}. Assumes this host may use the affected grpcfuse file-sharing path.')
sys.exit(1)
else:
print(f'PATCHED - Docker Desktop {version_str} detected via {source}; fixed threshold is {fixed_str}.')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Docker CVE mirror entry for CVE-2026-8936
- Docker Desktop release notes
- Docker Desktop networking and file I/O architecture
- Docker bind mounts documentation
- Docker container security FAQ
- Docker Enhanced Container Isolation
- CISA Known Exploited Vulnerabilities catalog
- FIRST EPSS documentation / API reference
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.