Vad SCTPhantom egentligen slår sönder

CVE-2026-64564 - av en del av de forskare 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 framför allt används inom telesignalering, vissa finansiella meddelandesystem och några enstaka nätverksstackar för containrar och kluster. Sårbarheten sitter specifikt i ASCONF, koden som hanterar dynamisk adressomkonfigurering och som låter en aktiv SCTP-anslutning lägga till eller ta bort IP-adresser utan att bryta förbindelsen. 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 anslutning validerar den begäran utifrån källadressen i 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-block 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äroboksexemplet på en use-after-free, och en av de mer tillförlitliga metoderna för att omvandla en kärnbugg till fungerande kodexekvering.

Arton år är rubriken, inte lärdomen

Den ansvariga koden går tillbaka till Linux 2.6.25, som gavs ut i december 2007, vilket gör buggen omkring 18 år gammal vid den tidpunkt då Tencents Zhuque Lab hittade den. Forskarna tillskriver upptäckten Corvus AI, en autonom multiagent-pipeline för sårbarhetsforskning som teamet driver internt och som flaggade ASCONF-kodvägen som värd en djupare manuell granskning. Den detaljen betyder nästan lika mycket som buggen i sig: det handlar inte om ett känt riskfyllt område i kärnan som äntligen granskas, utan om ett genuint förbisett hörn som nästan ingen undersökte på allvar under närmare 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 om, och samtidigt den del som betyder minst för de flesta läsare. Ett glapp på 18 år mellan att buggen fanns och att den hittades visar att en strategi där man väntar på patchen redan misslyckades i det tysta 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 varför det spelar roll, oavsett enskilt patchdatum, att minska vad som faktiskt går att nå på en given maskin.

Root-åtkomst och container-flykt, bevisade i praktiken

Tencents Zhuque Lab visade exploateringen 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-sårbarheten 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 på värdsystemet 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 angriparens första hinder.

Exploateringskedjan kringgick kärnans address space layout randomization, kedjade samman en andra use-after-free med hjälp av SCTP-autentiseringsnycklar som angriparen själv kontrollerade, och byggde upp en förfalskad kärnobjektgraf för att nå root - allt utan shellcode eller en return-oriented-programming-kedja, det vill säga just de tekniker som de flesta motåtgärder mot kärnexploatering är byggda för att fånga upp. Testerna omfattade kärnversioner från 5.14 fram till och med release-kandidaten 7.2, och rättningen mot uppströmsprojektet landade som commit 9b2854f86f0b innan den portades tillbaka till de fyra stabila grenarna som nämns ovan.

Enradsfixen som de flesta team hoppar över

Patchen är verklig och väl 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 - modulen är kompilerad rakt in i huvudkärnan som standard, och de flesta driftteam har ingen aning om att den ens finns, långt mindre att en lokal process kan nå den. Det är den egentliga lärdomen som ligger gömd i forskarnas eget diskussionstråd på oss-security: en deltagare i tråden påpekade att system i RHEL-familjen håller SCTP avstängt som standard, levererat som ett separat paket, kernel-modules-extra, med automatisk inladdning svartlistad, medan kärnor i Debian- och Ubuntu-familjerna bygger in SCTP direkt och låter det laddas så fort någon process efterfrågar det. Två system kan bära exakt samma CVE och ändå ha en helt olika verklig risknivå, och skillnaden har inget att göra med vilken patch som är installerad.

Åtgärden som är värd att vidta den här veckan är inte att vänta på distributionens uppdatering, utan att kontrollera om SCTP över huvud taget gör någon nytta i en given serverflotta. Kommandot lsmod | grep sctp visar om modulen för närvarande är laddad; en kontroll av /etc/modprobe.d/ efter en befintlig svartlistningspost visar om automatisk inladdning 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 den dörren oavsett vilken kärnversion som så småningom kommer, en vana som stämmer väl överens med vad svenska MSB och CERT-SE redan rekommenderar för varje oanvänd kärnmodul, inte bara den här.

Läs vidare: Cisco ISE: en perfekt tia, ingen workaround  |  En anställds AI-inloggning nådde OpenAIs källkod