Docker 29.9.0 Security Update: How to Safely Update Your Home Server

Quick answer

Docker Engine 29.9.0 was released on 8 October 2026 and is now the current documented 29.x patch in Docker’s official release notes.

It adds another security layer on top of the fixes shipped in 29.8.2. The main 29.9.0 security changes are four HTTP/2 denial-of-service vulnerabilities fixed through the updated Go runtime:

• CVE-2026-97032: an HTTP/2 client could crash the Docker daemon by changing the HPACK header table size while sending requests
• CVE-2026-78659: an HTTP/2 client could consume daemon memory using a large number of trailer fields
• CVE-2026-78663: stream resets could bypass connection-level flow-control limits and make the daemon buffer more request data
• CVE-2026-78669: repeated HTTP/2 stream/window changes could drive excessive daemon CPU usage

Docker also documents a Windows-specific junction issue, CVE-2026-56857.

The same HTTP/2 fixes are applied through the updated golang.org/x/net dependency to Docker’s deprecated /grpc endpoint and to the gRPC server BuildKit uses for frontend containers.

For an ordinary Ubuntu home server, the sensible response is:

check Engine and Compose versions
→ record the working Docker state
→ back up Compose files, .env and application data
→ preview the package update
→ update Docker Engine packages
→ verify the daemon
→ verify containers, networks and volumes
→ test Jellyfin and media access
→ update container images separately

Updating Jellyfin, Sonarr or Radarr images does not update Docker Engine itself.

---

1. Check your Docker Engine version

Run:

docker version
docker compose version

For a compact Engine check:

docker version --format 'client={{.Client.Version}} server={{.Server.Version}}'

On Ubuntu hosts installed from Docker’s Apt repository, also inspect the package candidate:

apt-cache policy   docker-ce   docker-ce-cli   containerd.io   docker-buildx-plugin   docker-compose-plugin

If the server is on Docker 29.x and a supported 29.9.0 package is available from the package source you intentionally use, plan the update.

Do not switch package families during a security patch. If your host uses Ubuntu’s Docker packages, an appliance repository or another distribution’s packaging, follow that source’s supported update path.

---

2. What the HTTP/2 fixes mean for a home server

The 29.9.0 vulnerabilities are denial-of-service issues rather than a generic claim that any internet user can compromise every Docker host.

Risk depends on who can reach Docker’s API or relevant BuildKit interfaces.

Exposure is more concerning when:

• the Docker daemon listens on a TCP socket
• remote API access is exposed beyond a tightly controlled administrative network
• untrusted users can access the Docker API
• build workflows process untrusted Dockerfiles or external frontends
• CI or automation lets less-trusted clients submit builds

A typical home server using only the local Unix socket has less remote reachability than a daemon exposed over TCP. That does not make patching unnecessary. Local access to the Docker socket is already highly privileged, and BuildKit paths still deserve current security fixes.

Check how dockerd is listening:

ps -ef | grep '[d]ockerd'
systemctl cat docker
ss -lntp | grep -E '2375|2376' || true

If you find an unexpected unauthenticated Docker TCP listener, treat that as a configuration problem as well as a patching task.

---

3. Docker 29.9.0 also includes non-security fixes

The release is not only a Go-runtime security rebuild.

Docker 29.9.0 also includes fixes and changes affecting:

• containerd image-store pulls
• incomplete image content after certain pull scenarios
• RootlessKit connections
• bridge-network IPv6 neighbour discovery
• published-port visibility and reachability
• Swarm overlay networking
• encrypted-overlay handling
• containerd, BuildKit and Go runtime package versions

Most SmallGrid readers do not need to change configuration because of those fixes. They do need to confirm that the daemon, networks and important containers return normally after the package update.

---

4. Record the working state before patching

Capture enough information to compare before and after.

docker version
docker compose version
docker info
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'
docker compose ls
docker network ls
docker volume ls
docker system df
systemctl status docker --no-pager

For restart policies:

docker inspect $(docker ps -q)   --format '{{.Name}} restart={{.HostConfig.RestartPolicy.Name}}'

For Jellyfin mounts:

docker inspect jellyfin   --format '{{range .Mounts}}{{println .Source "->" .Destination "RW=" .RW}}{{end}}'

Replace jellyfin if your container uses another name.

This gives you evidence of the known-good state before the daemon restarts.

---

5. Back up Compose files and persistent data

Before updating infrastructure, protect the files that rebuild the stack.

For each Compose project, preserve:

• compose.yaml or docker-compose.yml
• .env
• secrets
• bind-mounted configuration directories
• named-volume data using an application-appropriate backup method
• application database exports where required

Render the effective Compose configuration:

cd /path/to/compose-project
docker compose config > compose-effective-before-docker-29-9-0.yaml
docker compose config --images

Protect the rendered file if it contains secrets.

Use How to Back Up and Restore Docker Compose Services if you have not already documented how your stacks are rebuilt.

---

6. Check storage before updating Docker

Media servers are especially sensitive to bind mounts and host storage.

Before patching:

findmnt
df -hT
lsblk -f

For Jellyfin:

docker exec jellyfin find /media -maxdepth 3 -type f | head

Use your real container path.

If media access is already broken, fix that first. Otherwise an existing mount or permission problem can be mistaken for a Docker regression after the update.

Useful references:

• Jellyfin Docker Volume Paths Explained
• Jellyfin Docker Permissions
• Docker File Permissions Explained: UID, GID, Umask and Shared Media Folders

---

7. Preview the Ubuntu package update

Refresh package metadata:

sudo apt update

Check the available versions:

apt-cache policy   docker-ce   docker-ce-cli   containerd.io   docker-buildx-plugin   docker-compose-plugin

Preview what Apt intends to do:

sudo apt-get --simulate install   docker-ce   docker-ce-cli   containerd.io   docker-buildx-plugin   docker-compose-plugin

Stop if Apt proposes unexpected removals, a repository switch or package-family replacement.

For the evergreen workflow, use How to Safely Update Docker Engine on Ubuntu.

---

8. Update Docker Engine

For a host installed from Docker’s official Ubuntu repository:

sudo apt install   docker-ce   docker-ce-cli   containerd.io   docker-buildx-plugin   docker-compose-plugin

Read the transaction summary before confirming.

The Docker daemon can restart during the package update, briefly interrupting containers.

Keep this maintenance window narrow. Do not combine it with:

• an Ubuntu release upgrade
• a Jellyfin major upgrade
• a storage migration
• a Compose network redesign
• a broad application-image refresh

One moving part is much easier to diagnose than five.

---

9. Verify Docker after the update

Check the daemon and versions:

systemctl status docker --no-pager
docker version
docker compose version
docker info

Then verify the runtime objects:

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'
docker network ls
docker volume ls
systemctl --failed
journalctl -u docker --since '-15 minutes' --no-pager

Confirm:

• the Docker Server version reports 29.9.0 or a later supported patch
• the daemon is active
• expected containers returned
• health checks settle
• expected networks still exist
• expected volumes still exist
• published ports are reachable

Do not run docker system prune -a as part of routine security patching. Cleanup is a separate maintenance job.

---

10. Verify networking deliberately

Docker 29.9.0 includes several networking fixes, so compare the post-update state rather than assuming it is fine.

Check:

docker network ls
docker inspect jellyfin   --format '{{range $name, $value := .NetworkSettings.Networks}}{{println $name}}{{end}}'

If you use a reverse proxy, confirm it can still resolve and reach the target container.

If you use Swarm or encrypted overlay networks, read the 29.9.0 networking section in Docker’s release notes before maintenance because several fixes are specific to those paths.

---

11. Verify Jellyfin and the rest of the media stack

A healthy Docker daemon does not prove the application is healthy.

For Jellyfin:

docker ps --filter name=jellyfin
docker logs --since 10m jellyfin
docker exec jellyfin find /media -maxdepth 3 -type f | head

Then verify in the UI:

• dashboard opens
• libraries are present
• a known file plays
• one intentional transcode works if used
• hardware acceleration still works
• remote access follows the expected path

For Sonarr and Radarr, check:

• the UI loads
• the download client connects
• root folders remain available
• completed-download import still sees the expected paths

If Docker is healthy but media is missing, investigate mounts and permissions before rolling Docker back.

---

12. Engine updates and container-image updates are separate jobs

This distinction is worth repeating.

Running:

docker compose pull
docker compose up -d

updates application images referenced by a Compose project.

It does not normally update:

• Docker Engine
• Docker CLI
• containerd
• Buildx
• the Compose plugin

Likewise, patching Docker Engine does not automatically update Jellyfin, Sonarr, Radarr or other container images.

Patch the Engine first, verify it, then schedule application-image updates separately.

Use How to Update Docker Containers Safely for that second job.

---

What changed since Docker 29.8.2?

Docker 29.8.2, released on 30 September 2026, already fixed serious issues involving crafted image indexes, registry TLS handling, Swarm overlays and multiple BuildKit paths.

Docker 29.9.0 does not make those fixes irrelevant. It adds another security set, mainly around HTTP/2 handling in the Go runtime and related gRPC code.

If you followed the earlier version of this guide and updated to 29.8.2, check again. A server on 29.8.2 is no longer at the latest documented 29.x patch.

The URL for this guide has deliberately been preserved so SmallGrid does not create a competing version-specific page every time Docker ships another patch.

---

Final checklist

• Docker Engine and Compose versions recorded before the update.
• Docker package source confirmed.
• Compose files and .env backed up.
• Persistent application data protected.
• Running containers, networks and volumes recorded.
• Media mounts verified before maintenance.
• Apt transaction previewed.
• Docker packages updated through the existing supported source.
• Docker Server reports 29.9.0 or a later supported patch.
• Expected containers restarted.
• Networks and volumes remain present.
• Jellyfin still sees media and plays a known file.
• Sonarr/Radarr still see their root and download paths.
• Docker journal shows no new repeating failure.
• Application-image updates are handled separately.

---

Official source

• Docker Engine 29 release notes

---

Related SmallGrid guides

• How to Safely Update Docker Engine on Ubuntu
• How to Install Docker on Ubuntu Server
• How to Back Up and Restore Docker Compose Services
• How to Update Docker Containers Safely
• Docker File Permissions Explained: UID, GID, Umask and Shared Media Folders
• Jellyfin Docker Permissions
• Jellyfin Docker Volume Paths Explained
• Jellyfin on Ubuntu

---

Recap

Docker Engine 29.9.0 is the current documented 29.x security patch as of 10 October 2026.

The important home-server response is controlled maintenance rather than panic: record the known-good state, back up the configuration and persistent data, patch Docker through the package source you already use, verify the daemon, networks and volumes, then prove Jellyfin and the rest of the media stack still work.

Keep Docker Engine patching separate from container-image updates. That makes failures easier to identify and keeps a routine security update from becoming an accidental platform migration.