On 30 October 2026 Akamai opened a customer security advisory on the Linode status page for a Linux kernel bug, CVE-2026-98432. The advisory is two sentences long and the second one is the whole story for anyone who runs on a shared kernel: "Akamai is aware of the recently published remote code execution CVE-2026-98432. We are actively investigating and taking the appropriate mitigation actions, while we continue to monitor our platform in parallel." Nothing in that sentence is addressed to the customer, because nothing in it is the customer's to do.
DeployBase runs containers on a shared Linux kernel, with no root inside the container and unprivileged SSH from the Pro plan up. That is the model this article is about. It says nothing about any particular host's kernel version or patch status, including ours; it is about what kind of bug this is, and who holds the fix when the bug is in the kernel rather than in your code.
What the registry actually says
The CVE was assigned by the Linux kernel's own CNA and published on 15 October 2026, two weeks before the advisory. Its title is the commit that fixes it: "ipv4: free inet_opt and ireq_opt after an RCU grace period". It is a use-after-free in the IPv4 TCP handshake path. When a SYN arrives carrying IP options (Record Route or Timestamp bytes), the kernel stores them on the request socket; when the handshake completes, ownership of those options moves to the child socket without a copy. A retransmitted SYN for the same request, handled on another CPU at the same moment, can still be reading the options while the first CPU frees them. The fix defers the free until an RCU grace period has passed.
The CNA scored it CVSS 3.1 9.8, Critical, with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, and the record carries the reasoning for each letter. The two that matter most to a tenant are quoted here verbatim. On privileges: the vulnerable code runs "during the TCP handshake, before application authentication. The target performs no capability or credential check on the peer's valid IPv4 Record Route or Timestamp option." On impact: reclaiming the freed object "can therefore disclose adjacent kernel heap contents directly to the peer", and the stale offsets permit "out-of-bounds kernel writes and potential control-flow corruption"; a stale length can also "oops the kernel" or trigger a panic in the SYNACK path.
Two things the record does not say. It does not say "remote code execution"; that phrase is Akamai's characterisation in its advisory, and the registry's own wording stops at out-of-bounds writes and potential control-flow corruption. And it is not a flood. The scenario text describes one option-bearing SYN racing its own retransmission against the teardown of that same connection. It is a correctness bug in how two CPUs share one object, not a volume problem, and nothing about connection rate or bandwidth enters into it. A reader who sees "SYN" and thinks of a SYN flood is thinking of a different class of problem with different defences.
Affected ranges, per the record: every kernel from 4.4 up to the fix in each stable series. Fixed in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, and in 7.3 and later. IPv6 is not affected by the main issue, because the IPv6 path duplicates the options instead of transferring them.
Why this one is different from the CVEs you have been fixing
Over the last two weeks this blog has covered three security fixes a tenant could apply from inside their own deployment. The October Node.js security release needed a rebuilt container image, because the runtime lives in the image. The Laravel TokenGuard bypass needed a Composer update, because the framework lives in your vendor directory. The PHP2Shell fix needed a new PHP build in the image. Every one of them was userland: the vulnerable bytes were in files you ship, so you could ship different files.
CVE-2026-98432 is not in any file you ship. A container has its own filesystem, its own process tree and its own network namespace, but it does not have its own kernel. The TCP handshake for a connection to your app is handled by the host kernel, before a single byte reaches your process, before your reverse proxy or framework has a chance to authenticate anything. So the usual remedies do nothing here:
- Rebuilding your image does nothing. The kernel is not in the image.
- Updating your dependencies does nothing. No package in
node_modulesorvendorhandles a SYN. - Rate limiting at your app or proxy does nothing. The race is completed, or not, before your proxy sees a request, and it is not a rate problem anyway.
- A firewall rule you control inside the container does nothing to the handshake, which is terminated by the host.
The fix is a kernel update and, for most of the affected series, a reboot or a live patch of the host. Only the operator of the host can do that. This is the demand-side reason behind a change this blog priced on 17 October: in one month Netlify, DigitalOcean and Railway each described moving some tenant workloads from containers to per-tenant kernels, and Railway put a rate card on it. A pre-authentication bug in the shared kernel is exactly the case that argument is made for. It is also exactly the case where the per-tenant kernel's cost, five times the container RAM rate on Railway's sheet, is being paid for something: a kernel that is yours to patch, on your schedule, with your reboot.
What a container tenant can actually do
Less than usual, and that is the honest answer. But not nothing.
Know which kernel you are on. Inside a container, uname -r reports the host kernel, because there is no other kernel to report. Compare the version you see against the fixed versions above. This tells you whether the series you are on has the fix available; it does not by itself tell you whether your host has applied it, because distributions backport fixes without changing the upstream version string. For that, you need the host's own statement.
Ask your host the specific question. Not "are you patched" but "which kernel build is in production and does it include the fix for CVE-2026-98432". A host that runs a shared kernel owes its tenants that sentence, in writing, with a date. Akamai's advisory is a template for the first half of that duty, acknowledgement and a promise of updates; the second half is the update that names the build.
Treat the kernel as part of your supply chain. When you evaluate a host, the questions you ask about runtime versions and image rebuild policy apply equally to the kernel: how fast do fixes reach production, is live patching used or is a reboot required, and will you be told. On a shared kernel these answers are the patch cadence for the one component you cannot rebuild yourself.
Do not reach for a flood defence. Connection limits, SYN cookies and rate limiting are answers to a different question. They are worth having for their own reasons, but none of them changes whether one correctly formed SYN and its retransmission can race in the kernel.
If you are weighing a container against a per-tenant kernel for a workload, this CVE is the clean example of what the extra money buys and what it does not: it buys the right to apply this patch yourself, today, and it does not buy any protection from the bug until you do.
Sources: Linode Status, "Customer Security Advisory: CVE-2026-98432", updates posted 30 October 2026 at 18:10 and 21:18 UTC; CVE record CVE-2026-98432 at cveawg.mitre.org, assigner Linux, published 15 October 2026, updated 30 October 2026, including the CNA's CVSS 3.1 scenario text; NVD entry for the same CVE. All read 31 October 2026. Earlier DeployBase posts linked above are ours.