> ## Content Index > Fetch the complete content index at: https://app.hostwolf.net/blog/llms.txt > Use this file to discover other available public pages before exploring further. # Docker Engine 29.8.2: two container security bugs you can't ignore - URL: https://app.hostwolf.net/blog/docker-engine-29-8-2-security-release/ - Published: 2026-10-08T01:17:04.000Z - Updated: 2026-10-08T02:05:18.000Z - Description: This guide walks through the Docker Engine 29.8.2 security release, which patches two unprivileged-attack vulnerabilities: malicious DNS responses that disable TLS verification on registry pulls and forged VXLAN injection into encrypted Swarm overlay networks. - Author: Hostwolf - Tags: Security, Docker, DevOps, News Docker Engine 29.8.2 security release: what changed and what to do Docker Engine 29.8.2 is a security release, published on 2026-09-30, that patches two vulnerabilities exploitable without root access: a DNS-triggered TLS bypass for registry pulls (CVE-2026-92543) and forged frame injection into encrypted Swarm overlay networks (CVE-2026-92542). If you run your own Docker daemon, especially one pulling from private registries, upgrade now; the two advisories were published a day later, on 2026-10-01\. One caveat up front: this release has a known regression on Swarm, covered below. No source reports active exploitation. The urgency comes from how easy the bugs are to reach: neither requires privileged access on the target host. ## What shipped in Docker Engine 29.8.2 and why it matters The release is documented in the [official release notes](https://docs.docker.com/engine/release-notes/29/?ref=app.hostwolf.net), with the change list mirrored in the [moby/moby discussion #53829](https://github.com/moby/moby/discussions/53829?ref=app.hostwolf.net). It fixes three CVEs: | CVE | What it does | Severity | | -------------- | ----------------------------------------------------------------------- | ------------------------------------- | | CVE-2026-92543 | Malicious DNS answer disables TLS verification for registry connections | CVSS 7.6, High | | CVE-2026-92542 | Unprivileged injection of forged frames into encrypted Swarm overlays | CVSS 4.0 6.9, Moderate | | CVE-2026-53493 | Crafted OCI image index causes unbounded CPU and memory on pull | Advisory lives in the containerd repo | Bundled component updates: BuildKit v0.33.1, containerd static binaries v2.3.6, and runc v1.5.2. Primary sources for the two headline bugs are the advisories [GHSA-7cfq-22r6-qp73](https://github.com/moby/moby/security/advisories/GHSA-7cfq-22r6-qp73?ref=app.hostwolf.net) and [GHSA-6m9p-4h64-m6vh](https://github.com/moby/moby/security/advisories/GHSA-6m9p-4h64-m6vh?ref=app.hostwolf.net), both published 2026-10-01. ### The two bugs in one paragraph The first bug lets any party who controls DNS answers on the wire make your daemon talk to a registry without verifying certificates, which exposes your registry credentials and opens the door to image substitution. The second lets any unprivileged user on a Linux Swarm node craft UDP packets that get encrypted with an overlay's IPsec parameters and injected as frames into an encrypted overlay network, potentially on a different node. ### Which CVE applies to which setup You don't need to care about all three equally. If you don't run Swarm, CVE-2026-92542 doesn't apply at all. If you only pull from public registries over networks you fully control, your exposure to CVE-2026-92543 is limited but not zero. If you run Kubernetes nodes with containerd and no Docker Engine, the Docker upgrade fixes nothing for you; you need containerd's advisory for CVE-2026-53493. ## CVE-2026-92543: how a DNS answer turns off TLS for your registry pulls Per the advisory, the root cause is in how the daemon decides whether a registry host counts as insecure. ![Abstract horizontal flow diagram on a dark circuit-line background: a periwinkle server rack icon connects via a line…](https://app.hostwolf.net/blog/content/images/2026/10/docker-engine-29-8-2-security-release-dns-flow.webp) Diagram: server, DNS resolver with a warning flag, and registry with a verification toggle. ### The loopback-match bug, step by step `loadInsecureRegistries()` hardcodes `127.0.0.0/8` and `::1/128` as insecure CIDRs. When the daemon checks whether a registry hostname is insecure, `isCIDRMatch` resolves all of the hostname's addresses and returns true if a single one of them falls in the insecure CIDR list. So a DNS answer set containing one loopback IP plus one attacker-controlled IP is enough to classify the whole hostname as insecure. Because the transport re-dials the hostname, the connection to the attacker's address then skips certificate verification and can fall back to plain HTTP. ### Credential exposure via X-Registry-Auth Two consequences follow. First, the daemon sends the `X-Registry-Auth` header with every authenticated pull, so those credentials land on the attacker's host with an invalid certificate and are disclosed. Second, a trusted image tag can be substituted with an attacker-controlled manifest and layers in the image store. Who is most exposed: CI runners on shared or cloud networks, developer machines on untrusted networks, and any host whose resolver, or the path to it, is not fully trusted. ### Why split-horizon and corporate DNS need a second look Split-horizon setups can legitimately return different address sets depending on where the query comes from. That's normal operation, not an attack. The question to ask is whether an attacker can influence the answers your daemon receives. If your daemon's resolver is inside your own network and you control it, your risk is much lower than a CI runner using whatever DNS its cloud provider hands it. What does not mitigate, per the advisory: - Removing `insecure-registries` entries. The loopback CIDRs are hardcoded. - Using a trusted CA certificate for the registry. Doesn't help if the hostname can resolve to loopback. - Digest pinning. Defense-in-depth against image substitution only; it does nothing about credential disclosure. ## CVE-2026-92542: forged frames in encrypted Swarm overlay networks [GHSA-6m9p-4h64-m6vh](https://github.com/moby/moby/security/advisories/GHSA-6m9p-4h64-m6vh?ref=app.hostwolf.net) describes a flaw in the overlay driver's firewall rules. ### The encryption-marking flaw The iptables rules that mark VXLAN datagrams for encryption match both authentic kernel-sent datagrams and forged datagrams sent from user processes. Any UDP datagram from a Linux Swarm node's host network namespace, sent to the Swarm data-path port and starting with a VXLAN header for the VNI of an encrypted overlay that a running container is connected to, gets encrypted with that overlay's IPsec parameters. The result: an unprivileged user on one Swarm node can trivially inject forged Ethernet frames into an encrypted overlay network on another node. The CVSS profile reflects that: integrity and availability impact high, confidentiality none (CVSS 4.0 6.9, AV:L/PR:L). Affected versions are <= 25.0.18 and 26.0.0 through 29.8.1\. Patched in 29.8.2 and v25.0.19. ### The official iptables workaround The advisory offers an exact mitigation, blocking userspace processes from sending UDP to the Swarm data-path port: ```bash iptables -I OUTPUT -p udp --dport "$(docker info --format '{{.Swarm.Cluster.DataPathPort}}')" -m owner --socket-exists -j DROP ``` If you do not run Swarm, this CVE does not apply to you. Skip this section entirely. ## Check whether you are exposed before upgrading ### Version, CIDR and DNS checks Check the daemon version, not the client: ```bash docker version --format '{{.Server.Version}}' ``` The server version is what matters. You want 29.8.2. Then look at what the daemon currently classifies as insecure registries: ```bash docker info --format '{{json .RegistryConfig.InsecureRegistryCIDRs}}' ``` If the output includes loopback ranges, that's expected (they're hardcoded), but it means any registry hostname resolving to a loopback address is treated as insecure. For each registry hostname you pull from, do a point-in-time check: ```bash getent ahosts "$host" ``` Caveat: DNS answers can change between checks. This confirms whether you were vulnerable at that moment, not whether you always were. ### Auditing CI runners and Docker-in-Docker CI configs often pin Engine versions or use Docker-in-Docker images, and those are the hosts doing authenticated pulls on untrusted networks: ```bash grep -rnE "docker:[0-9]+\.[0-9]+|docker-version|dind" .github/ .gitlab-ci.yml ``` Every hit is a host to upgrade or update. ### Which CVEs apply to your setup | Your setup | Applies | What to do | | -------------------------------------------------------------- | -------------- | ------------------------------------------------------------ | | Running Docker Swarm | CVE-2026-92542 | Upgrade to 29.8.2 or v25.0.19; iptables workaround meanwhile | | Pulling private registries on networks you don't fully control | CVE-2026-92543 | Upgrade to 29.8.2; pin registry hostnames meanwhile | | containerd-only host (most Kubernetes nodes) | CVE-2026-53493 | Docker upgrade does not help; check containerd's advisory | ## Interim mitigations while you plan the upgrade ### Registry hostname pinning and egress restrictions For CVE-2026-92543, the advisory lists two mitigations: pin the registry hostname to its expected address via trusted DNS or a hosts-file entry, and restrict the daemon's outbound network access to trusted registry endpoints only. Pinning via a hosts-file entry is the quickest to deploy; egress filtering is the better long-term control regardless. ### Swarm data-path port lockdown For CVE-2026-92542, apply the `iptables` owner-match DROP rule above on every Linux Swarm node. ### Set an end date for every workaround These are partial mitigations, not fixes. Give each one an end date in your tracker, and treat the upgrade as the only complete remediation. Note again what does not work: editing `insecure-registries` (the loopback CIDRs are hardcoded), swapping in a trusted CA, or relying on digest pinning to protect credentials. Operators keep making those three moves because they sound right; the advisory explicitly rules them out. ## How to upgrade to 29.8.2 safely ### Debian/Ubuntu package upgrade If you installed from the Docker apt repository: ```bash sudo apt-get update && sudo apt-get install --only-upgrade docker-ce docker-ce-cli containerd.io docker-buildx-plugin sudo systemctl restart docker ``` ### Rolling Swarm nodes one at a time Restart worker nodes one at a time and confirm encrypted-overlay services are back up before touching the next node. This matters more than usual for this release, for reasons covered in the regression section below. ### Static binaries and the 25.0 branch If you install from static binaries, fetch the 29.8.2 binaries and restart the daemon. On the 25.0 branch, the fix landed in v25.0.19 per the primary advisory. Secondary sources note the 25.0 line's security support reportedly ends 4 December 2026, so plan your exit from that branch either way. ### Don't forget BuildKit in separate builders Builders running through the `docker-container` driver, remote builders, and Kubernetes builders run their own BuildKit. They may stay below v0.33.1 even after the Engine upgrade. Verify each builder separately. ## Post-upgrade checklist: cache, credentials and verification ### Verify the patch landed everywhere - Every host pulling from a private registry reports `29.8.2` from `docker version --format '{{.Server.Version}}'`. - CI runner images and Docker-in-Docker services are upgraded (the grep output from earlier is your worklist). - Every buildx builder reports BuildKit v0.33.1 or later. ### Prune poisoned build cache The upgrade stops new cache poisoning but does not undo earlier poisoning. Prune the build cache after upgrading, prioritizing shared builders that ran fork-PR builds: ```bash docker builder prune ``` ### Decide on registry credential rotation [GHSA-7cfq-22r6-qp73](https://github.com/moby/moby/security/advisories/GHSA-7cfq-22r6-qp73?ref=app.hostwolf.net) lists credential disclosure via `X-Registry-Auth` as a possible impact. Credentials used by a vulnerable daemon pulling from a private registry should be treated as potentially disclosed. No source mandates rotation, so this is your call based on exposure history: if your daemon pulled on networks whose DNS you couldn't fully trust, rotation is the safer default. Check `~/.docker/config.json` on your runner hosts to see which registries have stored credentials. ### Containerd-only hosts Check hosts running containerd without Docker against containerd's own advisory for CVE-2026-53493. And close the loop on workarounds: every one you applied gets an end date or gets removed. ## One regression to watch: the 29.8.2 overlay Join/Leave bug A word of caution before you mass-restart Swarm nodes. This section comes from a community post-mortem and upstream tracking, not from the official advisories. ### Symptoms and cause The issue is tracked upstream as moby/moby#53834, documented in a [community post-mortem](https://homelabpostmortem.com/2026/10/03/docker-swarm-failed-starts-cut-healthy-containers-off-the-overlay/?ref=app.hostwolf.net). When a container start fails after the overlay driver's Join, a double Leave fires and decrements the per-node endpoint count. After N+1 such failures, the overlay sandbox is destroyed for healthy containers on that node, while `docker ps` still reports them running. No fix had been released as of 2026-10-03. ### The workaround sequence Per the field report: fix the failing start first (a port conflict is visible via `docker service ps --no-trunc`), scale the failing service to zero, then `systemctl restart docker` and restart the containers without a restart policy. The practical takeaway lines up with the upgrade procedure already described: don't mass-restart all Swarm nodes at once. Rolling one node at a time limits the blast radius of this regression the same way it does for the CVE fix. ## What we'd do first If you run Docker on servers you manage, the order that makes sense is: check `docker version --format '{{.Server.Version}}'` on every host, apply the iptables rule on Swarm nodes and pin registry hostnames on CI runners today, upgrade to 29.8.2 node by node this week, prune build caches, then decide on credential rotation. The advisory workarounds buy you days, not months. The upgrade is the fix. One note on further reading: none of our existing blog posts cover Docker Engine security releases closely enough to link here, so the advisories and release notes above are the best references. ## Frequently asked questions ### Does Docker Engine 29.8.2 fix the issues on Kubernetes clusters? Most Kubernetes nodes run containerd without the Docker Engine. A Docker upgrade does nothing for them on CVE-2026-53493, whose advisory lives in the containerd repository — check containerd's fixed versions instead. CVE-2026-92542 applies only to Swarm. ### Do I need to rotate registry credentials after patching? Credential disclosure via X-Registry-Auth is a stated possible impact of CVE-2026-92543, so credentials used by a vulnerable daemon pulling from a private registry should be treated as potentially disclosed. No source mandates rotation; make the call based on whether your daemon pulled on networks whose DNS you could not fully trust. ### Is my build cache safe after upgrading? No. The upgrade stops new cache poisoning but does not undo earlier poisoning. Prune the build cache, prioritizing shared builders that ran fork-PR builds, and verify each builder reports BuildKit v0.33.1 or later. ### Is there active exploitation of these Docker vulnerabilities? No source reports in-the-wild exploitation. CVE-2026-92543 has no EPSS score and is not in CISA's KEV catalog, which means the probability is unknown rather than low. The urgency comes from exploits that need no privileged access. ### What if I don't run Docker Swarm? CVE-2026-92542 does not apply. Your exposure is CVE-2026-92543 (registry pulls over DNS you don't control) and, on containerd-only hosts, CVE-2026-53493 via containerd's own advisory.