If you run any Docker deployment on a VPS you control, the release from 30 September 2026 is not a routine version bump. Docker Engine 29.8.2 ships 13 security fixes - three in the engine itself and ten in the bundled BuildKit - including one high-severity issue that can hand a remote attacker your registry credentials or swap the image you pull, and two that bite exactly the setup most self-hosters use. This is the hosting upgrade to do this week, not next month.

Why this release matters

Docker Engine 29.8.2 was released on 30 September 2026 as a dedicated security release.[1] It fixes three Docker Engine vulnerabilities plus a batch of ten BuildKit vulnerabilities, and it bundles updated containerd (v2.3.6), BuildKit (v0.33.1) and runc (v1.5.2).[1][2]

Three of the four “headline” issues - the registry-trust bypass, the Swarm overlay injection, and the containerd image-pull DoS - fit a pattern that should worry anyone who self-hosts on a single box: they are reachable by pulling untrusted images, resolving DNS on a host you don’t fully control, or running an unprivileged user on a Swarm node. None of them needs you to click a malicious container - the damage happens during resolution and pull, before anything you wrote runs.

The one that breaks your registry chain of trust - CVE-2026-92543 (High)

The most serious bug in the release is CVE-2026-92543 (GHSA-7cfq-22r6-qp73), rated High with a CVSS score of 7.6.[3]

The mechanics matter because they’re subtle. Docker Engine treats a registry hostname as “insecure” using an any-match DNS check: by default it injects the 127.0.0.0/8 and ::1/128 ranges as insecure CIDRs, and the matching function resolves all of a hostname’s addresses, returning “insecure” if a single one falls inside those ranges. The transport then re-dials the hostname rather than the address that matched - so a crafted DNS answer that returns one loopback IP alongside a non-loopback attacker IP disables TLS certificate verification and enables HTTP fallback for the registry connection.[3]

The impact is what makes it dangerous for a deploy host:[3]

  • Registry credentials sent in the X-Registry-Auth header can be disclosed to an attacker-controlled host with an invalid certificate.
  • A trusted image tag can be substituted with an attacker-controlled manifest and layers in the image store - i.e. you pull “your” image and get a poisoned one.

That second outcome is the one that should keep you up at night if you run CI/CD or pull from a private registry (Docker Hub counts). The advisory lists defense-in-depth workarounds if you can’t upgrade immediately: pin the registry hostname to a trusted non-loopback address (trusted DNS or a hosts-file entry), restrict the daemon’s outbound access to trusted registry endpoints, and reference critical images by digest instead of mutable tag. Note that using a trusted CA certificate does not mitigate the issue if the hostname can also resolve to a loopback address.[3] The real fix is Engine 29.8.2. Reported by AdamKorcz.[3]

CVE-2026-92542 (Moderate): blind VXLAN injection into encrypted Swarm overlay networks

The second engine flaw, CVE-2026-92542 (GHSA-6m9p-4h64-m6vh), is rated Moderate with a CVSS score of 6.9.[4] If you run Docker Swarm across multiple nodes with encrypted overlay networks, it’s directly relevant.

The root cause is that the iptables rules which mark VXLAN datagrams for IPsec encryption match any qualifying datagram - authentic kernel-sent VXLAN and forged datagrams sent by user processes alike. Any packet from the host network namespace of a Linux Swarm node that meets three criteria (UDP, destination port equal to the Swarm data-path port, and a VXLAN header for the VNI of an encrypted overlay network a container on the node is connected to) gets encrypted with the overlay-network IPsec parameters. An unprivileged user on a Linux Swarm node can therefore trivially inject forged Ethernet frames into an encrypted overlay network on another node.[4]

Impact: an unprivileged local user on a peer node can launch a denial of service, and a sophisticated attacker may be able to smuggle packets past a stateful firewall that the encrypted overlay was meant to protect.[4] Affected versions are <= 25.0.18 and 26.0.0–29.8.1; fixed in 29.8.2 (and 25.0.19 for the older branch).[4] The advisory’s workaround is to block userspace processes from sending UDP to the Swarm data-path port - an iptables rule using --socket-exists - but on a multi-tenant Swarm the cleaner answer is the upgrade.[4]

CVE-2026-53493 (Moderate): an image-pull DoS in the bundled containerd

CVE-2026-53493 (GHSA-pg57-6jwg-q645) is a containerd vulnerability that becomes a Docker Engine problem because Engine 29.x bundles containerd as its runtime. It’s rated Moderate with a CVSS score of 6.9 (CWE-400/834).[2][5]

Pulling a crafted OCI image index with deeply nested or widely fanned-out descriptors can force very high CPU and memory usage during the pull - before any container starts. Because containerd’s descriptor-graph resolution recursed without limits on depth, breadth, or duplicate references, a single poisoned image reference can tie up the node for long-running container creations or, at larger sizes, destabilise the host.[5][6]

For a self-hosted box, the exposure concentrates where you pull anything you didn’t build and can’t vouch for: multi-tenant clusters, CI runners that pull arbitrary base images, and registry mirrors/caches. If every image on your node comes from a registry you own and trust, this is routine hygiene; if any node pulls from the open internet or from tenants you don’t trust, treat it with more urgency.[6] Fixed in containerd 1.7.36, 2.0.13, 2.2.9, 2.3.6 and 2.4.1; Docker Engine 29.8.2 bundles containerd v2.3.6, so the Engine upgrade is what carries the fix.[1][5][6]

The BuildKit batch: crashes, cache poisoning, a source-policy bypass

The ten BuildKit fixes (the batch is fixed in the bundled BuildKit v0.33.1) cluster into three groups.[1][2][7]

Daemon crashes (availability): CVE-2026-93316 (CDI requested but disabled → daemon panic), CVE-2026-93319 (malicious external frontend crashes the daemon via gateway lifecycle races or malformed requests), CVE-2026-93321 (malformed LLB file operation with invalid symlink owner inputs) and CVE-2026-93322 (malformed LLB merge operation with mismatched input counts) can all panic or crash the build daemon. CVE-2026-93323 adds memory exhaustion from an oversized Dockerfile, .dockerignore, gateway file or nested LLB definition.[2][7]

Build-cache poisoning (integrity / supply chain): the two that should matter most on a deploy host. CVE-2026-93317 - with the containerd image store, a client using the low-level LLB API can poison the build cache with container blob contents that don’t match their claimed digest. CVE-2026-93318 - a malicious image can poison the build cache with layer DiffIDs that don’t match the actual layer contents.[2][7] If an attacker can poison your cache, later builds can silently pick up tampered content and shipping it to production becomes supply-chain compromise rather than an exotic bug.

Source policy and filesystem: CVE-2026-93326 is the one the briefs flagged - a crafted Git build source can bypass source-policy rules that match on the repository URL, via a Git bundle locator or a full remote URL that doesn’t match the source identifier. CVE-2026-93320 covers daemon-side snapshot reads and LLB mkfile operations that didn’t safely handle special files, and CVE-2026-93315 lets a build step redirect proxy-CA cleanup outside the build root filesystem or let the build succeed when cleanup failed.[2][7]

What to update and how to verify

The fix is to get Docker Engine to 29.8.2 or later on every node that pulls images or runs builds - that’s your VPS, your CI runners, and the host that runs your registry mirrors. The 29.8.x fixes were carried forward into the 29.9 line: as of 7 November 2026 the current Engine release is 29.9.3 (3 November 2026, a cumulative security release on top of 29.9.2’s eMudhra CA fix), and any 29.9.x node already carries the 29.8.2 fixes - though you should still land on 29.9.3 for the newer CVEs.[1] If you are still on 29.8.0/29.8.1, the jump to ≥29.8.2 is the one that closes the bugs below.

Update. If you installed from Docker’s apt repository on Debian/Ubuntu:

sudo apt-get update
sudo apt-get install --only-upgrade docker-ce docker-ce-cli containerd.io

If you use static binaries or another distro’s package path, fetch the 29.8.2 binaries and restart the daemon.

Verify the engine version after the upgrade:

docker version --format '{{.Server.Version}}'   # expect 29.8.2 or later (29.9.x as of Oct 2026)
docker info | grep -i "Server Version"

The Server Version field is the number that matters - it’s the engine’s own version, not the CLI’s. Also confirm the bundled components after a fresh restart:

docker buildx version    # bundled BuildKit revision (v0.33.1+)
docker info              # check the daemon restarted cleanly on the new binary

On a self-hosted Swarm, restart worker nodes one at a time so the overlay doesn’t churn, and confirm your encrypted-overlay services come back up before moving to the next node.

Why this is exactly your problem on a self-hosted box

None of this depends on someone running a malicious container on your host. The DNS-based registry bypass (92543) fires while the daemon resolves and authenticates a registry; the containerd DoS (53493) fires during pull; the BuildKit cache-poisoning bugs fire when you build from a questionable base or frontend. For a lean post on a raw VPS or a self-hosted platform, that’s the exact threat model you live in: you pull public images, you build against them, and you trust the registry chain to keep that honest.

The upgrade is small, well-tested, and it closes a batch that includes a High-severity credential-and-image-substitution bug. Verify your nodes are on 29.8.2, confirm the bundled containerd/BuildKit versions, and you’ve removed an entire family of pull-time attacks from your box.

Sources

  1. Docker - Engine 29 release notes (29.8.2, 2026-09-30; packaging updates: BuildKit v0.33.1, containerd v2.3.6, runc v1.5.2; current line release 29.9.3, 2026-11-03). https://docs.docker.com/engine/release-notes/29/ - checked 2026-11-07
  2. GitHub - moby/moby release docker-v29.8.2 (full CVE + GHSA list for engine and BuildKit). https://github.com/moby/moby/releases/tag/docker-v29.8.2 - checked 2026-10-02
  3. GitHub Advisory GHSA-7cfq-22r6-qp73 (moby/moby) - CVE-2026-92543, “insecure-registry fallback via malicious DNS responses”, High (CVSS 7.6), patched 29.8.2. https://github.com/moby/moby/security/advisories/GHSA-7cfq-22r6-qp73 - checked 2026-10-02
  4. GitHub Advisory GHSA-6m9p-4h64-m6vh (moby/moby) - CVE-2026-92542, “blind VXLAN injection into encrypted overlay networks”, Moderate (CVSS 6.9), patched 29.8.2 / 25.0.19. https://github.com/moby/moby/security/advisories/GHSA-6m9p-4h64-m6vh - checked 2026-10-02
  5. GitHub Advisory GHSA-pg57-6jwg-q645 (containerd) - CVE-2026-53493, “image-pull DoS via crafted OCI index graph amplification”, Moderate, fixed 1.7.36 / 2.0.13 / 2.2.9 / 2.3.6 / 2.4.1. https://github.com/containerd/containerd/security/advisories/GHSA-pg57-6jwg-q645 - checked 2026-10-02
  6. containerd - NVD record for CVE-2026-53493 (crafted OCI index graph can force high CPU/memory during pull; fixed 1.7.36/2.0.13/2.2.9/2.3.6/2.4.1). https://nvd.nist.gov/vuln/detail/CVE-2026-53493 - checked 2026-10-02
  7. GitHub - moby/buildkit security advisories (GHSA-2f5p-x9ph-g97x, GHSA-r456-g3gm-cvxf, GHSA-p3rc-w3hc-pqvv, GHSA-f2v9-hprr-32q3, GHSA-4hgw-qrhw-fhg8, GHSA-9728-qjrv-2xh2, GHSA-fjj4-h6vf-m9hj, GHSA-cv6p-7w7g-xjwq, GHSA-mgqf-486f-49vp, GHSA-66hf-6vf5-87hc). https://github.com/moby/buildkit/security/advisories - checked 2026-10-02