CVE-2026-98432: patch the Linux host behind your PDF containers

CVE-2026-98432 is a Linux kernel use-after-free in IPv4 TCP connection handling. Anthropic has described remote command execution as root against a server using a Multipath TCP listener. For teams operating PDF workers in Docker, the patching boundary matters: updating Node.js, Chromium, or a container image does not replace the host kernel.

Sources checked on November 2, 2026. Follow the current distribution advisory for patch availability rather than treating this article as a live package-status feed.

Why did Tobi Lütke's post draw attention to this CVE?

Shopify co-founder Tobi Lütke brought the issue to a wider developer audience on October 31, linking an analysis of CVE-2026-98432 with the comment "What a disaster". The post was subsequently shared and discussed by other technology and security accounts. That public attention is part of why this kernel vulnerability reached people who do not routinely follow Linux security notices.

The reaction makes sense for teams running web services: the reported attack concerns the host's networking stack, rather than a route that an application can simply remove. A PDF worker, an API server, and a reverse proxy can have different application dependencies while still relying on the same underlying Linux kernel.

Social attention and technical scope are separate facts. Lütke's post is useful context for how the story spread; the Linux CVE record, vendor trackers, and researchers' write-up establish what is vulnerable and what needs patching. The public proof of concept also does not establish widespread exploitation in production. The sections below keep those distinctions explicit.

What happened with the Linux TCP vulnerability?

The vulnerability concerns socket option memory being freed while concurrent TCP processing can still access it. The Linux project's CVE record, published on October 15, describes the fix as deferring those frees until after an RCU grace period.

The incident received wider attention after Anthropic's October 27 research report. Anthropic says an internal research model produced a remote exploit after initial prompting. In the reported test, leaking a kernel pointer took 48 minutes and reaching command execution took another five minutes. Those are measurements from the researchers' proof of concept, not a universal time-to-compromise for Linux servers.

For operators, distinguish the vulnerable component, the demonstrated exploit, and the patch deployed to a particular host. A research demonstration establishes a concrete risk. It does not tell you whether a managed platform has already patched its machines or whether your server uses the same listener configuration.

Our recommended incident record contains the host identifier, the running kernel, the exposed listeners, and the party responsible for the kernel. That last field is easy to miss when the application team only manages a Dockerfile.

Is this only a Go or MPTCP problem?

No. The Go security team's notice explicitly separates the demonstrated MPTCP exploit from the broader kernel bug. It warns that systems without MPTCP listeners could be vulnerable to similar attacks and recommends a patched kernel.

The notice says Go 1.24 enables MPTCP by default for Linux listening sockets. It describes GODEBUG=multipathtcp=0 as a way to change the default, while explicit per-socket configuration can override that setting. Treat this as a temporary exposure-reduction option for an affected Go program, not a replacement for the kernel fix.

Red Hat's bulletin rates the issue critical and describes inbound IPv4 TCP systems as the most directly exposed. Review the host's actual network path instead of deciding from the application language alone.

Why does a fresh Docker image leave the host kernel unchanged?

Linux containers share the host kernel, as the Docker documentation explains. A rebuilt PDF worker can contain a patched Node.js runtime and browser while still executing on an affected host kernel.

Separate these maintenance records:

Our recommendation for a self-operated PDF service is to inventory both the public API host and any private rendering nodes. For a managed container platform, ask who owns the underlying kernel and what deployment scope its security statement covers. A new application deployment is useful evidence for an image-level update; it is not evidence of host remediation.

The Docker PDF generation guide explains the application packaging side. The HTML-to-PDF threat model covers the separate browser boundary. Both matter, but neither substitutes for a host-kernel update.

What should you check before closing the incident?

Identify the running kernel, match it to your vendor's fixed package, and confirm that the fixed kernel is active. Our recommended checklist also records listener exposure and tests a representative PDF workflow after maintenance.

These Linux commands collect information without changing the host:

uname -r
ss -tlnp
ss -Mlnp
sysctl net.mptcp.enabled

Use an ss build that supports MPTCP and inspect the relevant network namespaces. A host-level listing does not automatically inventory every isolated container namespace. The kernel MPTCP documentation explains the protocol and its configuration.

Check the exact release and package in the Ubuntu tracker or your distribution's equivalent. Distribution kernels may contain backports, so comparing an arbitrary package version with a different upstream release line is insufficient. After installing a fixed kernel, activate it using the vendor's documented procedure and re-check the running version.

Red Hat documents temporary packet filtering but explicitly says it cannot fully prevent the vulnerability. Follow the vendor's mitigation procedure if you need interim controls; do not label a filtering change as a completed patch.

For a PDF deployment, finish with a known template, a successful HTML-to-PDF conversion, and a download check. PDF4.dev can handle hosted rendering, while your own caller infrastructure remains a separate maintenance responsibility.