Wat SCTPhantom werkelijk breekt

CVE-2026-64564 - door een deel van de onderzoekers die erover berichtten SCTPhantom genoemd - is een use-after-free-kwetsbaarheid in de Linux-kernelimplementatie van SCTP, het Stream Control Transmission Protocol dat vooral gebruikt wordt in telecomsignalering, sommige financiele berichtensystemen en enkele container- en clusternetwerkstacks. De fout zit specifiek in ASCONF, de code die Dynamische Adresherconfiguratie afhandelt en die een actieve SCTP-associatie toestaat IP-adressen toe te voegen of te verwijderen zonder de verbinding af te breken. De CVE werd formeel aangekondigd op 4 augustus 2026, na een privaat onthullingsproces dat al op 12 juli 2026 begon.

De onderliggende oorzaak is een identiteitsmismatch: wanneer de kernel een DEL-IP-verzoek verwerkt om een adres uit een associatie te verwijderen, valideert hij dat verzoek aan de hand van het bronadres van het binnenkomende pakket, terwijl een aparte gecachte pointer in de kernel zich blijft baseren op het adres dat in de parameter van het verzoek zelf staat. Een aanvaller die een doelbewust geordende reeks ASCONF-chunks opbouwt, kan dat gat tussen de twee controles misbruiken om een stuk kernelgeheugen vrij te geven terwijl een actieve pointer er nog naar wijst - de schoolboekdefinitie van een use-after-free, en een van de betrouwbaarste manieren om een kernelfout om te zetten in werkende code-executie.

Achttien jaar is de krantenkop, niet de les

De verantwoordelijke code gaat terug tot Linux 2.6.25, uitgebracht in december 2007, waardoor de fout ongeveer 18 jaar oud was op het moment dat Tencents Zhuque Lab hem vond. De onderzoekers schrijven de ontdekking toe aan Corvus AI, een autonome multi-agent pijplijn voor kwetsbaarheidsonderzoek die het team intern draait, die de ASCONF-codepad markeerde als de moeite van een diepere handmatige controle waard. Dat detail telt bijna net zo zwaar als de fout zelf: dit is geen geval van een bekend risicovol deel van de kernel dat eindelijk wordt gecontroleerd, het is een genuine obscure hoek die bijna twee decennia lang door vrijwel niemand grondig is bekeken.

Stabiele fixes verschenen op 3 augustus 2026 in de kerneltakken 6.6.148, 6.12.101, 6.18.42 en 7.1.6, en distributiebeheerders zijn al begonnen die in hun eigen pakketbomen op te nemen. Dat is het deel van het verhaal dat elk medium meldt, en tegelijk het deel dat voor de meeste lezers het minst belangrijk is. Een kloof van 18 jaar tussen het uitkomen van de fout en het vinden ervan bewijst dat een beleid van wachten op de patch precies op dit codepad al achttien jaar stilzwijgend faalde - er is geen reden om aan te nemen dat de volgende onbekeken hoek van de kernel sneller gevonden wordt, en daarom telt het verkleinen van wat op een gegeven machine daadwerkelijk bereikbaar is, los van elke afzonderlijke patchdatum.

Root-toegang en container-escape, aangetoond

Tencents Zhuque Lab toonde de exploit van begin tot eind aan, niet alleen een crash. Op systemen met Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 en OpenCloudOS zette het team de use-after-free om in volledige root-rechtenescalatie vanaf een onbevoorrecht lokaal account, en gebruikte vervolgens dezelfde techniek om in zes van de acht pogingen uit een container naar de host te ontsnappen, zonder CAP_NET_ADMIN of CAP_SYS_ADMIN nodig te hebben, de verhoogde rechten die de meeste hardeningsgidsen voor containers als eerste vereiste voor een aanvaller veronderstellen.

De exploitketen omzeilde de address space layout randomization van de kernel, koppelde een tweede use-after-free met behulp van door de aanvaller gecontroleerde SCTP-authenticatiesleutels, en bouwde een vervalste kernelobjectgraaf om root te bereiken, dit alles zonder shellcode of een return-oriented-programmingketen, precies de technieken waar de meeste kernel-exploitmitigaties op gebouwd zijn om te onderscheppen. De tests bestreken kernelversies vanaf 5.14 tot en met de 7.2-releasekandidaat, en de upstream-fix kwam binnen als commit 9b2854f86f0b voordat hij werd teruggeporteerd naar de vier hierboven genoemde stabiele takken.

De eenregelige fix die de meeste teams overslaan

De patch is echt en het loont om hem toe te passen, maar hij behandelt een symptoom. Vrijwel geen van de organisaties die deze vijf distributies draaien, koos er bewust voor om SCTP in te schakelen - het zit standaard gecompileerd in de mainline-kernel, en de meeste beheerders hebben geen idee dat het aanwezig is, laat staan dat een lokaal proces erbij kan. Dat is de eigenlijke les die verscholen zit in de eigen oss-security-discussie van de onderzoekers: een deelnemer aan die discussie wees erop dat systemen uit de RHEL-familie SCTP standaard buiten houden, geleverd als los pakket kernel-modules-extra met het automatisch laden op de blacklist, terwijl kernels uit de Debian- en Ubuntu-families SCTP rechtstreeks inbouwen en laten laden zodra een willekeurig proces erom vraagt. Twee systemen kunnen dezelfde CVE dragen en toch een heel ander reëel risico lopen, en dat verschil heeft niets te maken met welke patch geïnstalleerd is.

De actie die deze week de moeite waard is, is niet wachten op de distributie-update, maar controleren of SCTP sowieso iets nuttigs doet op een gegeven vloot. Het commando lsmod | grep sctp laat zien of de module momenteel geladen is; controleren of /etc/modprobe.d/ al een blacklist-item bevat, laat zien of automatisch laden al geblokkeerd is. Waar niets legitiem van SCTP afhangt - en op de meeste algemene servers is dat niets - sluit het op de blacklist zetten van de module de deur, ongeacht welke kernelversie uiteindelijk arriveert, een gewoonte die aansluit bij wat het Nederlandse NCSC (Nationaal Cyber Security Centrum) al aanraadt voor elke ongebruikte kernelmodule, niet alleen voor deze ene.

Lees hierna: Uw MSP-tool heeft een tweede bypass-fout  |  Het telefoontje dat de MFA van uw bedrijf omzeilt