Wat er aan de hand is
Kort antwoord
CVE-2026-98432 is een kritiek lek in de TCP-code van de Linux-kernel. Via het netwerk kan een aanvaller proberen root te worden op een server, zonder in te loggen. De fix bestaat, maar nog niet voor elke distributie. Wie een eigen server draait, moet wachten op een kernel-update, die installeren en de server herstarten. Applicaties die serverless draaien hebben geen eigen kernel: daar patcht het platform de onderlaag.
Op 15 oktober 2026 publiceerde het kernel-CVE-team CVE-2026-98432. Het lek zit in tcp_v4_syn_recv_sock(), de functie die een binnenkomende TCP-verbinding over IPv4 afrondt. Daarbij geeft de kernel de IP-opties van het verzoek door aan de nieuwe verbinding zonder ze te kopiëren. Komt er tegelijk een herhaald SYN-pakket binnen, dan kan de kernel die opties nog gebruiken terwijl ze al zijn vrijgegeven. Dat heet een use-after-free, en dat is precies het soort fout waarmee een aanvaller de controle over geheugen kan overnemen.
De bug zit al in de kernel sinds versie 4.4, dus ruim tien jaar. Op 24 oktober gaf het kernel-CVE-team hem een CVSS-score van 9.8: bereikbaar via het netwerk, zonder inloggegevens en zonder dat er een gebruiker iets hoeft te doen. Red Hat, Oracle en SUSE schatten de kans op misbruik lager in en komen op 8.1, omdat de aanvaller een race moet winnen. Een verloren race kost hem alleen één mislukte verbinding, dus hij kan het blijven proberen.
De exploit van Anthropic
De bug is gemeld door een onderzoeker van Anthropic. Volgens berichtgeving over het onderzoek liet het Frontier Red Team van Anthropic een nog niet uitgebracht Claude-model, na een eerste opdracht, een exploit bouwen tegen een server met een MPTCP-listener. Het lekken van een geheugenadres om de beveiliging van de kernel te omzeilen duurde ongeveer 48 minuten. Van daaruit naar een root-shell op afstand kostte nog zo’n vijf minuten.
Daar horen twee kanttekeningen bij. Anthropic heeft de exploit, de kernelversie en de configuratie niet gepubliceerd, dus de claim is niet onafhankelijk bevestigd. En het is onbekend of een server zonder MPTCP op dezelfde manier over te nemen is. Het lek staat niet in de CISA-lijst van actief misbruikte kwetsbaarheden. Toch is de boodschap helder: wat vroeger weken werk van een specialist was, kan nu in een middag. De tijd tussen het bekend worden van een lek en het eerste misbruik wordt korter.
Waarom patchen hier lastig is
De fix zit in de stable kernels 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 en 7.3. Maar een eigen server draait de kernel van zijn distributie, en die moet de fix eerst overnemen. Op 29 oktober 2026 was de stand volgens Rescana:
| Distributie | Status op 29 oktober 2026 |
|---|---|
| Debian 12 en 13 | Gepatcht (Debian security tracker) |
| Oracle Linux (UEK 7 t/m 10) | Gepatcht |
| SUSE (o.a. SLES 16) | Grotendeels gepatcht |
| Ubuntu 22.04, 24.04 en nieuwer | Kwetsbaar, fix in voorbereiding |
| RHEL 8, 9 en 10 | Kwetsbaar, fix uitgesteld zonder datum |
| Amazon Linux 2 en standaardkernel AL2023 | Kwetsbaar, fix in afwachting |
Draai je een VPS op Ubuntu, een veelgebruikte keuze bij TransIP, DigitalOcean en Hetzner, dan kun je dus nog niet patchen. Er is ook geen instelling die het lek dichtzet: net.ipv4.tcp_migrate_req uitzetten sluit alleen een tweede route, niet de hoofdroute. En komt de update er, dan werkt een nieuwe kernel pas na een herstart. Dat betekent een onderhoudsmoment, vaak ’s avonds of ’s nachts, en bij een enkele server ook even downtime.
Bij die hosters huur je een virtuele machine en ben je zelf de beheerder van alles wat erop draait, inclusief de kernel. Hetzelfde geldt voor servers die via een tool als Laravel Forge worden beheerd: Forge regelt de installatie, maar de kernel-update en de herstart liggen bij wie de server beheert.
Waarom dit bij serverless niet jouw probleem is
Bij serverless hosting heb je geen server, dus ook geen kernel om bij te houden. De applicatie draait in een omgeving die het platform voor je opstart en weer afsluit. De machines eronder, met hun besturingssysteem en kernel, zijn van de provider en worden door de provider gepatcht.
Bij Coding Agency gebruiken we daarvoor twee platformen:
- Laravel Vapor op AWS Lambda. Je applicatie draait in een Lambda-functie. Die functie draait in een lichtgewicht virtuele machine van AWS, met een kernel die AWS levert en bijhoudt. De naam van de runtime, zoals
php-8.4:al2023, gaat over de software in de functie, niet over de kernel eronder. Lees meer in ons artikel over Laravel Vapor. - Brewless, ons eigen platform voor serverless Laravel-hosting in Europa. Brewless draait applicaties op Serverless Containers van Scaleway, in het eigen Scaleway-account van de klant. Scaleway beheert de machines; er is niets om te patchen of te herstarten.
Er is nog een tweede verschil. Het lek wordt misbruikt met TCP-pakketten die rechtstreeks de kernel van een server bereiken. Bij Vapor en Brewless komt verkeer binnen via de HTTP-laag van het platform, zoals API Gateway of een load balancer. Een aanvaller praat dus niet met een open TCP-poort op een machine die bij jouw applicatie hoort.
Dat betekent niet dat serverless onkwetsbaar is. Ook AWS en Scaleway moeten deze fix uitrollen, en een fout in je eigen code blijft je eigen fout. Het verschil zit in wie verantwoordelijk is: bij serverless is de onderlaag het werk van een team dat niets anders doet, op een schaal waar patchen geautomatiseerd is. Er is geen nachtelijke patchsessie die jij moet plannen, en geen server die je moet herstarten.
Eigen server of serverless naast elkaar
| Hosting | Wie patcht de kernel? | Wat moet jij doen bij CVE-2026-98432? |
|---|---|---|
| VPS bij TransIP, DigitalOcean of Hetzner | Jij | Wachten op de distributie, kernel installeren, server herstarten |
| Beheerde server via Forge | De beheerder | Hetzelfde, maar dan door je beheerder |
| Laravel Vapor op AWS Lambda | AWS | Niets |
| Brewless op Scaleway | Scaleway | Niets |
Een bewuste keuze
Dit is geen toevallig voordeel. We kiezen voor nieuwe projecten bewust voor serverless, juist omdat lekken in de onderlaag steeds sneller elkaar opvolgen. Eerder dit jaar was het Copy Fail in de kernel, deze maand PHP2Shell in PHP, en nu dit TCP-lek. Elke keer opnieuw ligt het zware werk bij wie servers beheert. Alle klantprojecten die op Vapor of Brewless draaien, profiteren daarvan zonder dat ze er iets voor hoeven te doen.
Een eigen server blijft soms de juiste keuze, bijvoorbeeld voor software die niet in een serverless omgeving past. Voor de servers die we nog via Forge beheren, ligt de kernel-update bij ons, net als bij elke andere beheerder. Wil je weten hoe die afweging voor jouw applicatie uitvalt, lees dan traditionele hosting vs serverless op AWS.
De kern in vijf zinnen
- CVE-2026-98432 is een use-after-free in de TCP-handshake van de Linux-kernel, sinds 4.4, met een CVSS-score van 9.8.
- Een aanvaller kan het via het netwerk en zonder inloggen proberen; volgens Anthropic leidde dat in een test tot root op afstand.
- De fix zit in de stable kernels, maar Ubuntu en RHEL leveren hem op 29 oktober 2026 nog niet.
- Op een eigen server moet je wachten, de kernel installeren en herstarten; serverless heb je geen kernel om te patchen.
- Daarom kiest Coding Agency waar het kan voor Laravel Vapor of Brewless.
Vragen over jouw hosting?
Draait je applicatie op een eigen server en weet je niet of je hostingpartner dit lek in de gaten houdt? Of wil je weten of je applicatie naar serverless kan? Neem contact op voor een vrijblijvend gesprek.
