Docker Engine 29.9.0 fixes five HTTP/2 flaws inherited from Go and turns lazy-pull on by default
On October 8, 2026, Docker Engine 29.9.0 updated its Go runtime and closed five CVEs that let an HTTP/2 client crash the daemon or exhaust its memory, while enabling lazy-pull for remote snapshotters. If your Docker API is reachable from the network, schedule the upgrade; otherwise, use the moment to check your exposure.
October 8, 2026. Docker ships Engine 29.9.0, a maintenance release that matters mostly for its security fixes. Five CVEs. That is the number of HTTP/2 flaws closed by the Go runtime update to 1.26.9. An HTTP/2 client. That is the only attacker needed — it can crash the daemon or exhaust its memory. Why it matters: these flaws live in the daemon’s network stack, not in an exotic plugin, and they hit anyone who exposes the Docker API over the network.
Five HTTP/2 flaws, one origin
All five vulnerabilities come from the Go runtime, fixed upstream in Go 1.26.9 and then pulled into Docker Engine. They share a common denominator: a malicious HTTP/2 client that abuses the protocol to degrade or halt the daemon.
The precise list helps size the risk.
- CVE-2026-97032 — a client can crash the daemon by changing the HPACK table size while sending requests.
- CVE-2026-78659 — a client can exhaust memory by declaring a large number of fields in a Trailer header, bypassing header size limits.
- CVE-2026-78663 — a client can bypass the connection-level flow control limit by resetting streams, forcing the daemon to buffer more request data than allowed.
- CVE-2026-78669 — a client can drive excessive CPU use by opening many streams and repeatedly changing the initial window size.
- CVE-2026-56857 — on Windows, the daemon can create a directory outside its data root if someone with write access to the data root placed a junction there.
The update of golang.org/x/net to v0.60.0 applies the same HTTP/2 fixes to the deprecated /grpc endpoint and to the gRPC server that BuildKit runs for frontend containers — for example an image referenced by a # syntax= directive.
Who is actually exposed
The answer comes down to one question: where is your Docker API reachable? By default, the daemon listens on a local Unix socket (/var/run/docker.sock), unreachable from the network. In that case, the “unauthenticated” attacker of the advisories has no path to the vulnerable code.
The risk flips as soon as you leave that default. Three configurations dominate among the exposed.
- TCP port 2375 (no TLS) or 2376 (with TLS) opened for CI/CD agents, monitoring tools or third-party integrations. This is the classic door.
- A reverse proxy in front of the Docker API, speaking HTTP/2 with the client. The flaws then live in the daemon’s HTTP/2 path, proxy or no proxy.
- Remote builds that use
# syntax=to load a BuildKit frontend: the internal gRPC server receives the fix through x/net v0.60.0.
To check your own posture, the signal is simple: run docker info and read the Hosts line, or inspect the hosts key in daemon.json. A socket-only daemon shows no tcp:// entry — and that is the configuration in which none of the five flaws is reachable.
The first two CVEs (97032 and 78659) are the most worrying, because they turn a simple HTTP/2 client into a denial of service vector against the daemon — and therefore against every container it manages.
Lazy-pull: pull less, start faster
Beyond security, 29.9.0 brings a genuine change of behavior. The lazy-pull daemon feature controls whether docker pull skips downloading layer content that the snapshotter already provides.
In practice, it is enabled by default for known remote snapshotters — nydus, overlaybd, soci and stargz. For those backends, content is only fetched on demand, when a container actually accesses it, instead of being fully downloaded at pull time. The payoff is twofold: shorter pulls and faster starts on large images.
The release also fixes a pull bug that skipped required layer blobs when unpacked layers already existed, leaving images runnable but incomplete for export or push. With the containerd image store, that is an important consistency fix for anyone rebuilding or redistributing images.
The networking fixes, in passing
The networking section of the release deserves a careful read, because one fix touches the confidentiality of encrypted overlays.
A bug meant that when the kernel failed to program overlay encryption, traffic could be transmitted in cleartext toward some nodes. The receiving peer dropped those cleartext packets as spoofed, so the loss of confidentiality was limited to unidirectional flows — for example UDP DNS queries — and to handshake attempts that never proceeded. The fix closes the leak.
The release also restores removal of the empty DOCKER-INGRESS iptables chain left behind by Engine 28.0.0, releases IPsec associations when the last container leaves an encrypted overlay, and fixes published ports being omitted from docker ps on routed gateway networks. These are patches that mostly concern Swarm deployments and overlay networks.
A faster cadence of fixes
This release is not an isolated case: it extends a sequence. Version 29.8.2, published on September 30, 2026, had already closed a batch of engine and BuildKit flaws — including CVE-2026-53493, a malformed OCI image able to saturate CPU and memory, and CVE-2026-92543, a malicious DNS response that could skip the registry’s TLS verification. 29.9.0 lands eight days later with a comparable batch, this time centered on the HTTP/2 stack of the Go runtime.
That compressed cadence changes the expected posture. A Docker engine updated “once a year” now accumulates several waves of remotely exploitable network fixes. Moving from 29.8 to 29.9 is a short path — same major branch, few breaking changes — and it is worth it chiefly for the five HTTP/2 CVEs it carries.
Lazy-pull is not just a performance gain: it also shrinks the surface of fetched data. With a remote snapshotter such as stargz or nydus, the daemon no longer downloads whole layers it may never use, which cuts bandwidth and shortens the exposure window of an internal registry. The feature is on by default, but it assumes the containerd image store: deployments still on the classic image store get nothing until they migrate.
One CVE in the batch stands apart from the rest. CVE-2026-56857 is the only one that does not ride the HTTP/2 path: on Windows, a junction placed by someone with write access to the data root lets the daemon create a directory outside it. It is a reminder that the container-escape surface is not limited to Linux — Windows hosts deserve the same upgrade attention, especially those shared with less-trusted users.
Finally, note what the release does not do: it does not remove the deprecated /grpc endpoint, it fixes it. Teams still using it for legacy integrations should plan its eventual removal, but they are not forced to migrate urgently to be protected.
Verdict
If your Docker daemon listens on a local Unix socket and you do not publish the API on the network, the five HTTP/2 flaws are not exploitable in your environment: schedule the upgrade at the next maintenance cycle and enable lazy-pull if you use a remote snapshotter. If you expose the API on TCP 2375/2376, behind an HTTP/2 reverse proxy, or your builds use # syntax=, treat 29.9.0 as a priority update: an unauthenticated HTTP/2 client is enough to bring down the daemon, and with it every container you run. In every case, if you operate encrypted overlays, apply the fix to close the cleartext leak — even when limited, confidentiality that leaks intermittently is confidentiality you cannot audit.