Vad SCTPhantom egentligen förstör

CVE-2026-64564 - av en del av forskarna som rapporterat om den kallad SCTPhantom - är en use-after-free-sårbarhet i Linux-kärnans implementation av SCTP, Stream Control Transmission Protocol, som mest används inom telesignalering, vissa finansiella meddelandesystem och några få nätverksstackar för containrar och kluster. Buggen sitter specifikt i ASCONF, koden som hanterar Dynamisk Adressomkonfigurering och låter en aktiv SCTP-association lägga till eller ta bort IP-adresser utan att stänga anslutningen. CVE:n offentliggjordes formellt den 4 augusti 2026, efter en privat avslöjandeprocess som redan hade inletts den 12 juli 2026.

Grundorsaken är en identitetsdiskrepans: när kärnan hanterar en DEL-IP-begäran om att ta bort en adress från en association valideras begäran utifran källadressen på det inkommande paketet, medan en separat cachad pekare i kärnan fortsätter att utgå från adressen som anges i själva begärans parameter. En angripare som bygger en medvetet ordnad sekvens av ASCONF-chunks kan utnyttja glappet mellan de två kontrollerna för att frigöra ett minnesområde i kärnan medan en aktiv pekare fortfarande pekar dit - läroboksdefinitionen av en use-after-free, och ett av de mer pålitliga sätten att göra en kärnbugg till verklig kodexekvering.

Arton år är rubriken, inte lärdomen

Den ansvariga koden går tillbaka till Linux 2.6.25, utgiven i december 2007, vilket gör buggen ungefär 18 år gammal vid den tidpunkt Tencents Zhuque Lab hittade den. Forskarna krediterar upptäckten till Corvus AI, en autonom multiagent-pipeline för sårbarhetsforskning som teamet driver internt, som flaggade ASCONF-kodvägen som värd en djupare manuell granskning. Den detaljen betyder nästan lika mycket som buggen själv: det handlar inte om ett känt riskområde i kärnan som äntligen granskas, utan om ett genuint förbisett hörn som nästan ingen undersökt på allvar under nästan två decennier.

Stabila rättningar landade den 3 augusti 2026 i kärngrenarna 6.6.148, 6.12.101, 6.18.42 och 7.1.6, och distributionernas underhållare har redan börjat föra in dem i sina egna paketträd. Det är den del av historien som alla medier rapporterar, och samtidigt den del som betyder minst för de flesta läsare. Ett gap på 18 år mellan att buggen fanns och att den hittades bevisar att en policy att vänta på patchen redan misslyckades tyst i arton år på just denna kodväg - det finns ingen anledning att anta att nästa förbisedda hörn av kärnan hittas snabbare, vilket är därför det spelar roll, oberoende av något enskilt patchdatum, att minska vad som faktiskt går att nå på en given maskin.

Root-åtkomst och container-flykt, påvisade

Tencents Zhuque Lab påvisade exploiten från början till slut, inte bara en krasch. På system med Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 och OpenCloudOS omvandlade teamet use-after-free-buggen till en fullständig root-rättighetseskalering från ett obehörigt lokalt konto, och använde sedan samma teknik för att ta sig ut ur en container och in i värden i sex av åtta försök, utan att behöva CAP_NET_ADMIN eller CAP_SYS_ADMIN, de förhöjda rättigheter som de flesta härdningsguider för containrar förutsätter som första hinder för en angripare.

Exploitkedjan kringgick kärnans address space layout randomization, kedjade samman en andra use-after-free med hjälp av angriparkontrollerade SCTP-autentiseringsnycklar, och byggde en förfalskad kärnobjektgraf för att nå root, allt utan shellcode eller en return-oriented-programming-kedja, just de tekniker som de flesta motatgärder mot kärnexploit är byggda för att fånga upp. Testerna täckte kärnversioner från 5.14 till och med release-kandidaten 7.2, och uppströmsrättningen landade som commit 9b2854f86f0b innan den portades tillbaka till de fyra stabila grenarna som nämns ovan.

Den enkla åtgärden som de flesta team hoppar över

Patchen är verklig och värd att installera, men den behandlar ett symptom. Nästan ingen av de organisationer som kör dessa fem distributioner valde själva att aktivera SCTP - det är kompilerat i kärnan som standard, och de flesta driftansvariga har ingen aning om att det ens finns, än mindre att en lokal process kan nå det. Det är den verkliga lärdomen som gömmer sig i forskarnas egen oss-security-diskussionstrad: en deltagare i tråden påpekade att system i RHEL-familjen håller SCTP utanför som standard, levererat som separat paket kernel-modules-extra med automatisk laddning svartlistad, medan kärnor i Debian- och Ubuntu-familjerna bygger in SCTP direkt och låter det laddas så fort någon process begär det. Två system kan bära samma CVE och ändå stå med helt olika verklig risk, och skillnaden har inget att göra med vilken patch som är installerad.

Åtgärden som är värd att vidta denna vecka är inte att vänta på distributionens uppdatering, utan att kontrollera om SCTP överhuvudtaget gör någon nytta på en given serverflotta. Kommandot lsmod | grep sctp visar om modulen för närvarande är laddad; att kontrollera /etc/modprobe.d/ efter en befintlig svartlistpost visar om automatisk laddning redan är blockerad. Där inget legitimt beror på SCTP - och på de flesta allmänna servrar beror inget på det - stänger en svartlistning av modulen dörren oavsett vilken kärnversion som så småningom kommer, en vana som stämmer överens med vad svenska MSB och CERT-SE redan rekommenderar för varje oanvänd kärnmodul, inte bara denna.

Läs vidare: Din MSP-lösning har ytterligare en bypass-brist  |  Samtalet som kringgår ert företags MFA