CVE-2026-98432: who patches the kernel under your app?

On 15 October 2026 the Linux kernel's CVE team published CVE-2026-98432, a flaw in the code that accepts every incoming IPv4 TCP connection. On 24 October they scored it 9.8 out of 10. The fix is in the stable kernels, but at the end of October not every distribution had shipped a fixed kernel yet.

This post explains what the flaw is, what is known about exploiting it, and who has to patch it, depending on how your Laravel application is hosted.

What is CVE-2026-98432?#

CVE-2026-98432 is a use-after-free in the Linux kernel's IPv4 TCP handshake. It has been in the kernel since Linux 4.4, so nearly every Linux server that accepts TCP connections over IPv4 is affected until it runs a fixed kernel.

When the kernel accepts a connection, tcp_v4_syn_recv_sock() hands the IP options of the pending request to the new socket without copying them. If a retransmitted SYN for the same request is handled on another CPU at that moment, the kernel can send a SYN-ACK built from options that were already freed. The fix frees those options only after an RCU grace period, when no other CPU can still be reading them. A second, similar race in moving pending requests between sockets (net.ipv4.tcp_migrate_req=1) is fixed in the same change.

Can it be exploited from the internet?#

It can be reached from the internet: an attacker only needs to open TCP connections to a port your server listens on, without signing in to anything. That is what puts the score at 9.8.

What is documented about the impact is a kernel crash, so a denial of service. Reports of a working exploit that gives root circulate, but we found none confirmed when we wrote this. Distributions also score the flaw differently. Treat it as urgent anyway: a crash on demand takes your application offline, and use-after-free bugs in the kernel have turned into code execution before.

Which kernels fix it?#

The fix is upstream commit e3f33b0a1d89, in Linux 7.3. The stable kernels that carry it:

Distributions build their own kernel packages, so look up your distribution's version. Debian has fixed packages for bookworm (6.1.190-1) and trixie (6.12.113-1). For Ubuntu, Red Hat Enterprise Linux and others, check their security trackers: when we wrote this, not all of them had a fixed kernel out.

Who patches the kernel under your Laravel app?#

That depends on who runs the machine your application runs on. The kernel is part of the machine, not of your code, so whoever runs the machine patches the kernel.

On a server of your own, installing the package is not enough: the old kernel keeps running until the server restarts. So patching means planning a restart, or moving traffic to another server first. Until your distribution ships a fixed kernel, there is nothing to install at all, and the flaw stays open.

Warning

Running Docker does not move the kernel away from you. Every container on a host shares that host's kernel, so a container on a server you run is exactly as exposed as the server itself.

What does serverless change?#

With serverless containers there is no server of yours. You hand the provider an image, and the provider decides on which machines it runs, starts and stops it, and keeps those machines up to date. AWS calls the same idea Lambda.

Brewless deploys your Laravel application to Scaleway Serverless Containers, in your own Scaleway project. Three things follow from that for a flaw like this one:

• There is no kernel of yours. Your image holds your application, PHP and the libraries it needs, built on Brewless's public base image. It holds no kernel: the kernel belongs to the machines Scaleway runs it on. According to Scaleway's documentation, every container also runs in a sandbox of its own, with gVisor or Kata Containers, rather than straight on the host's kernel.
• There is no maintenance window of yours. You do not install kernel packages, and you do not reboot anything. Your containers start and stop all day anyway, with traffic and with every deploy.
• Visitors do not reach a server of yours. With bunny.net in front, a visitor connects to bunny.net, and bunny.net to your container at Scaleway. Brewless itself is never in that path. See how Brewless works.

Note

Moving the kernel to Scaleway also means you rely on Scaleway to patch it. Neither you nor Brewless can see Scaleway's hosts or choose when they are updated. What you gain is that the work, the reboots and the planning around them are no longer yours.

What stays yours on serverless?#

The image does. The kernel moves to the provider, everything above it is still your application:

• PHP and its extensions. Brewless builds every release on its public base image, which carries FrankenPHP and PHP. The build pulls that image by digest, so an image swapped under its name is never built on, and a newer base image reaches your application with your next deploy after Brewless publishes it. See Deployments.
• Your Composer packages. composer audit names the packages with a known flaw. Run it in your pipeline, and deploy when you updated one.
• Servers you still run. A CI runner, a self-hosted database or a jump host next to your serverless application is a Linux server like any other, and needs a fixed kernel and a reboot for this flaw.

What should you do today?#

If you run Linux servers of your own, check which kernel they run and whether your distribution has a fixed package:

uname -r

On Debian, install the fixed kernel and restart:

sudo apt update && sudo apt full-upgrade
sudo reboot

After the restart, uname -r should name the fixed version. On other distributions, follow their advisory for CVE-2026-98432.

If your Laravel application runs on Brewless, there is no kernel for you to patch for this flaw. Use the moment to check the parts that are still yours: run composer audit, and look at the servers you still keep next to your application.