Jeres servere har lige arvet en 18 år gammel fejl

Hvad SCTPhantom egentlig ødelægger

CVE-2026-64564 - af nogle af de forskere, der har dækket den, kaldt SCTPhantom - er en use-after-free-sårbarhed i Linux-kernens implementering af SCTP, Stream Control Transmission Protocol, som mest bruges i telesignalering, enkelte finansielle beskedsystemer og nogle få container- og klyngenetværksstakke. Fejlen sidder specifikt i ASCONF, koden der håndterer Dynamisk Adressekonfiguration og lader en aktiv SCTP-forbindelse tilføje eller fjerne IP-adresser uden at lukke forbindelsen ned. CVE'en blev formelt offentliggjort den 4. august 2026, efter en privat offentliggørelsesproces, der allerede startede den 12. juli 2026.

Grundårsagen er et identitetsmisforhold: når kernen behandler en DEL-IP-anmodning om at fjerne en adresse fra en forbindelse, validerer den anmodningen ud fra kildeadressen på den indkommende pakke, mens en separat cachet pointer i kernen fortsat forholder sig til den adresse, der er angivet i selve anmodningens parameter. En angriber, der bygger en bevidst ordnet række af ASCONF-chunks, kan udnytte det hul mellem de to tjek til at frigøre et stykke kernehukommelse, mens en aktiv pointer stadig peger på det - skolebogseksemplet på en use-after-free, og et af de mere pålidelige greb til at gøre en kernefejl til reel kodeeksekvering.

Atten år er overskriften, ikke læren

Den ansvarlige kode går tilbage til Linux 2.6.25, udgivet i december 2007, hvilket gør fejlen omkring 18 år gammel på det tidspunkt, Tencents Zhuque Lab fandt den. Forskerne krediterer fundet til Corvus AI, en autonom multi-agent-pipeline til sårbarhedsforskning, som teamet driver internt, og som markerede ASCONF-kodestien som værd en dybere manuel gennemgang. Den detalje betyder næsten lige så meget som selve fejlen: det er ikke et tilfælde af et kendt risikoområde i kernen, der endelig bliver revideret, det er et reelt overset hjørne, som næsten ingen har undersøgt grundigt i næsten to årtier.

Stabile rettelser landede den 3. august 2026 i kernegrenene 6.6.148, 6.12.101, 6.18.42 og 7.1.6, og distributionernes vedligeholdere er allerede begyndt at føre dem ind i deres egne pakketræer. Det er den del af historien, alle medier dækker, og samtidig den del, der betyder mindst for de fleste læsere. Et hul på 18 år mellem fejlens udgivelse og dens opdagelse beviser, at en politik om at vente på patchen allerede fejlede i stilhed i atten år på netop denne kodesti - der er ingen grund til at antage, at det næste oversete hjørne af kernen bliver fundet hurtigere, og derfor betyder det noget, uafhængigt af enhver enkelt patch-dato, at begrænse hvad der reelt er tilgængeligt på en given maskine.

Root-adgang og container-flugt, demonstreret

Tencents Zhuque Lab demonstrerede exploiten fra ende til anden, ikke blot et nedbrud. På systemer med Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 og OpenCloudOS omdannede teamet use-after-free'en til en fuld root-rettighedseskalering fra en uprivilegeret lokal konto og brugte derefter samme teknik til at bryde ud af en container og ind på værtsmaskinen i seks ud af otte forsøg, uden at have brug for CAP_NET_ADMIN eller CAP_SYS_ADMIN, de forhøjede rettigheder, som de fleste hærdningsguider til containere forudsætter som første forhindring for en angriber.

Exploit-kæden omgik kernens address space layout randomization, kædede en anden use-after-free sammen ved hjælp af angriberkontrollerede SCTP-godkendelsesnøgler og byggede en forfalsket kerneobjektgraf for at nå root, alt sammen uden shellcode eller en return-oriented-programming-kæde, netop de teknikker, som de fleste kerne-exploitmodforanstaltninger er bygget til at opfange. Testene dækkede kerneversioner fra 5.14 til og med release-kandidaten 7.2, og upstream-rettelsen landede som commit 9b2854f86f0b, før den blev tilbageport til de fire stabile grene nævnt ovenfor.

Den enkle rettelse, de fleste teams springer over

Patchen er reel og værd at installere, men den behandler et symptom. Næsten ingen af de organisationer, der kører disse fem distributioner, valgte selv at aktivere SCTP - det er kompileret ind i mainline-kernen som standard, og de fleste driftsansvarlige aner ikke, at det overhovedet findes, endsige at en lokal proces kan nå det. Det er den egentlige lære, der gemmer sig i forskernes eget oss-security-diskussionstråd: en bidragyder i tråden påpegede, at systemer i RHEL-familien holder SCTP ude som standard, leveret som separat pakke kernel-modules-extra med automatisk indlæsning sortlistet, mens kerner i Debian- og Ubuntu-familierne bygger SCTP direkte ind og lader det indlæse, så snart en vilkårlig proces beder om det. To systemer kan bære den samme CVE og alligevel stå med meget forskellig reel risiko, og forskellen har intet at gøre med, hvilken patch der er installeret.

Den handling, der er værd at tage denne uge, er ikke at vente på distributionsopdateringen, men at tjekke om SCTP overhovedet gør nytte på en given serverflåde. Kommandoen lsmod | grep sctp viser, om modulet aktuelt er indlæst; et tjek af /etc/modprobe.d/ for en eksisterende sortlisteindførsel viser, om automatisk indlæsning allerede er blokeret. Hvor intet legitimt afhænger af SCTP - og på de fleste generelle servere gør intet det - lukker en sortlistning af modulet døren, uanset hvilken kerneversion der en dag ankommer, en vane der stemmer overens med, hvad det danske CFCS (Center for Cybersikkerhed) allerede anbefaler for ethvert ubrugt kernemodul, ikke kun dette ene.

Læs videre: Dit MSP-værktøj har endnu en bypass-fejl  |  Opkaldet der omgår din virksomheds MFA