Mitchel van Emmerik Full-stack developer
Steam LinkedIn Twitch
© 2026 Mitchel van Emmerik
English version RSS feed
Blog

Linux TCP-lek CVE-2026-98432: waarom MPTCP uitzetten niet genoeg is

Een kritiek lek in de TCP-code van Linux, een root-exploit geschreven door een AI en nog geen fix voor Ubuntu LTS. Wat wel en niet helpt, en wat je nu checkt.

7 min lezen 2 weergaven

  • linux
  • security
  • kernel
  • cve-2026-98432

Op 27 oktober meldde Anthropic dat een intern, nog niet uitgebracht Claude-model een werkende exploit had geschreven voor een bug in de Linux-kernel. Een aanvaller zonder account stuurt netwerkpakketten naar een server en kan daarna commando's uitvoeren als root. Inmiddels hebben Debian en Amazon Linux een fix. Ubuntu 22.04, 24.04 en 26.04 staan op 7 november nog op "work in progress". En het advies dat het snelst rondging, MPTCP uitzetten, lost het niet op.

Wat er mis is #

CVE-2026-98432 is een use-after-free in de IPv4 TCP-handshake. Een verbindingsverzoek kan IP options meesturen, zoals Record Route of Timestamp. Wordt dat verzoek opnieuw verstuurd, dan kan de kernel die options vrijgeven terwijl een andere CPU-kern ze nog gebruikt om een SYN-ACK te bouwen. Volgens Akamai zit de fout in de kernel sinds versie 4.4, dus sinds 2016.

De fix staat sinds 5 oktober upstream. Het CVE-nummer volgde op 15 oktober, en op 24 oktober gaf het CVE-team van de kernel het een CVSS-score van 9.8. Ubuntu en Red Hat noemen het lek inmiddels allebei "Critical". Deze stable kernels hebben de fix:

Kerneltak Gefixt vanaf
5.10 5.10.272
5.15 5.15.223
6.1 6.1.190
6.6 6.6.159
6.12 6.12.113
6.18 6.18.56
7.2 7.2.10
7.3 alle versies

Distributies backporten fixes naar hun eigen kernelversies, dus voor je eigen servers is de advisory van je distributie leidend, niet deze tabel.

De exploit #

Het Frontier Red Team van Anthropic beschrijft een aanval in twee stappen. Eerst gebruikt de exploit de race om kernelgeheugen te lekken en zo KASLR te omzeilen. Daarna overschrijft hij een callback-pointer, zodat de kernel code van de aanvaller uitvoert. Het lekken van een kernelpointer kostte 48 minuten, root halen nog eens vijf. Een verloren race laat alleen de handshake mislukken en laat het systeem niet crashen, dus een aanvaller kan het eindeloos blijven proberen.

De code, de kernelversie en de testopstelling zijn niet gepubliceerd. Anthropic geeft leveranciers 90 dagen om te patchen, en wacht daarna nog 45 dagen voordat het meer details deelt.

De gedemonstreerde aanval werkt op servers met een Multipath TCP-listener (MPTCP). Daar ging de discussie daarna over.

Waarom MPTCP uitzetten niet genoeg is #

Het eerste advies dat rondging was net.mptcp.enabled=0. Maar MPTCP is alleen de route die Anthropic liet zien, de bug zelf zit in gewone TCP-code. Red Hat zegt het letterlijk: "Having MPTCP enabled is not a precondition of this vulnerability." RHEL heeft MPTCP standaard uit en is volgens Red Hat toch kwetsbaar. CIQ testte het op Rocky Linux: met MPTCP uit beantwoordde een gewone TCP-listener nog steeds een SYN met een Record Route-option.

MPTCP uitzetten verkleint het risico wel. AWS zegt dat het de voorwaarden voor de aanval beperkt, maar "does not resolve the issue". MPTCP-sockets die al open staan, blijven bovendien open tot je de service herstart.

Er zijn twee plekken waar je meer MPTCP draait dan je denkt:

  • Go 1.24 en nieuwer. Volgens het Go Security Team gebruiken listeners op Linux standaard MPTCP als de kernel het ondersteunt. Zet het uit met GODEBUG=multipathtcp=0 of met godebug multipathtcp=0 in go.mod.
  • Containers. De MPTCP-instelling geldt per network namespace, dus de waarde op de host zegt niets over je containers. De kwetsbare code draait wel in de kernel die alle containers delen. Volgens de Cloud Security Alliance kan één blootgestelde listener in één container de hele host in gevaar brengen.

Een reverse proxy beschermt je niet #

De TCP-handshake gebeurt in de kernel van de machine die de verbinding aanneemt. Staat nginx of HAProxy op dezelfde host als je applicatie, dan is die host gewoon bereikbaar voor de aanval. Staat de proxy op een aparte Linux-machine, dan is dat de machine die je eerst moet patchen. Een beheerde load balancer die zelf de TCP-verbindingen afhandelt, zoals bij AWS, houdt de pakketten van een aanvaller wel weg bij je servers. Ook dan moet je de servers erachter bijwerken.

Wordt het al misbruikt? #

Er is geen publieke werkende exploit en er zijn geen bevestigde aanvallen. AWS schreef op 6 november: "We have no evidence that this issue has been leveraged at this time." Volgens Aikido meldde Marcus Hutchins op X dat residentiële proxies en VPN-servers sinds 2 november poort 443 via MPTCP aftasten, en hij vermoedt dat ze naar dit lek zoeken. Een tweede bron die dat bevestigt, heb ik niet gevonden.

Wat je nu doet #

1. Kernel bijwerken en herstarten #

Dit is de enige echte oplossing. Een nieuwe kernel doet niets tot je de machine herstart.

  • Debian: gefixt in 6.1.190-1 (bookworm) en 6.12.115-2 (trixie), via de security-repository.
  • Amazon Linux 2 en 2023: fixes zijn uit.
  • Ubuntu: alleen 26.10 heeft een fix (7.3.0-10.10). Voor 22.04, 24.04 en 26.04 staan gefixte kernels in -proposed, en die installeert apt niet standaard. Houd de Ubuntu CVE-pagina in de gaten.
  • RHEL 8, 9, 10 en OpenShift 4: het bulletin van Red Hat staat nog op "Ongoing". Kijk in de errata van jouw versie.

2. Kijk wat je draait #

uname -r                                           # draaiende kernel
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req  # MPTCP aan? request-migratie aan?
sudo ss -Mlnp                                      # processen met een MPTCP-listener

Op RHEL, Rocky en Alma zie je zo of de fix in je draaiende kernel zit. Een uitkomst groter dan 0 betekent ja:

rpm -q --changelog kernel-core-$(uname -r) | grep -c CVE-2026-98432

3. Nog geen fix? Filter TCP-pakketten met IP options #

Red Hat, CIQ, AlmaLinux en AWS geven dezelfde tijdelijke maatregel: TCP-pakketten met IP options weggooien. Normaal verkeer gebruikt ze bijna nooit. Een IPv4-header zonder options is precies vijf woorden van 32 bits lang, dus alles boven de 5 heeft options. Dit is de regel van CIQ:

sudo nft add table inet cve_2026_98432
sudo nft add chain inet cve_2026_98432 prerouting '{ type filter hook prerouting priority -300; policy accept; }'
sudo nft add rule inet cve_2026_98432 prerouting ip hdrlength gt 5 meta l4proto tcp counter drop

Let op een paar dingen:

  • Niet blijvend. Na een reboot is de regel weg, en ook systemctl stop nftables haalt hem weg.
  • Kan legitiem verkeer breken. Verkeer dat IP options echt nodig heeft, zoals CIPSO/NetLabel, wordt ook geblokkeerd. Test de regel daarom eerst op één machine.
  • Niet volledig. Volgens Ubuntu verkleint deze regel het risico, maar voorkomt hij misbruik niet helemaal.
  • Weghalen doe je met sudo nft delete table inet cve_2026_98432.

4. Kleiner maken wat aanvallers kunnen raken #

Gebruik je MPTCP niet, zet het dan uit en zet ook net.ipv4.tcp_migrate_req op 0. Die instelling hoort bij een tweede kwetsbaar pad in dezelfde code. Leg beide vast in een bestand onder /etc/sysctl.d/, start daarna je services opnieuw en vergeet je Go-services en containers niet.

Dezelfde les als bij PHP2Shell #

Net als bij PHP2Shell kan je applicatie helemaal bijgewerkt zijn en bepaalt de laag eronder of je veilig bent. Dit keer is dat de kernel, en die is pas bijgewerkt als je de machine herstart.

Bronnen #