Pe 4 august 2026, echipa CVE a kernelului Linux a atribuit CVE-2026-64564 unui use-after-free din implementarea Stream Control Transmission Protocol, poreclit SCTPhantom de cercetătorii care l-au găsit. Dezvăluirea privată începuse pe 12 iulie.
Codul responsabil a fost introdus în ciclul de dezvoltare Linux 2.6.25, în decembrie 2007. Logica vulnerabilă a rămas aproape optsprezece ani în ramura upstream, până la raportare; expunerea efectivă depinde însă de build-ul kernelului și de posibilitatea utilizării SCTP.
Ce permite
Ultimul punct contează pentru cum îl prioritizezi. SCTPhantom nu bagă un atacator în mediul tău. Convertește un punct de sprijin mic — o aplicație web compromisă, o dependență otrăvită, un credențial de developer furat — în control complet asupra gazdei și a tot ce rulează pe ea. Dat fiind câte dintre incidentele lunii acesteia au început exact așa, acel pas de conversie merită închis.
- Un atacator local — cineva care are deja o execuție de cod pe mașină, oricât de neprivilegiată — poate escalada la root
- În anumite configurații, același defect permite evadarea dintr-un container pe gazdă, ceea ce prăbușește granița de izolare pe care e construită o bună parte din infrastructura modernă
- Nu e exploatabil de la distanță în sine. Tratează-l ca a doua etapă a unui atac, nu ca prima
Bug-ul, pe scurt
SCTP suportă Dynamic Address Reconfiguration, care permite unei asocieri să adauge și să elimine adrese în timp ce rulează, prin chunk-uri ASCONF. Defectul apare când SCTP procesează o secvență ASCONF ordonată, construită special, care elimină un obiect transport în timp ce o referință învechită către el supraviețuiește în interiorul asocierii.
Nepotrivirea de bază e precisă: adresa sursă a pachetului IPv4 folosită pentru verificarea de validare DEL-IP nu e aceeași valoare cu Address Parameter folosit pentru a selecta ce transport e efectiv eliminat. Un atacator care înțelege acel decalaj poate construi o secvență care șterge un transport viu, în timp ce pointerii primary_path și active_path ai asocierii încă indică obiectul eliberat — un use-after-free de manual, accesibil prin operațiuni obișnuite de protocol.
E aceeași formă de defect ca vulnerabilitatea WordPress XSS2Shell pe care am acoperit-o acum două zile: două părți ale aceluiași sistem care nu se înțeleg asupra valorii ce identifică obiectul operat. Alt limbaj, alt deceniu, aceeași clasă de eșec.
Kernele remediate
Remedierea a ajuns upstream ca commit-ul 9b2854f86f0b și a fost portată pe ramurile stabile — între ele 6.6.148, 6.12.101, 6.18.42 și 7.1.6. Kernelele de distribuție au propriile numere de versiune, deci verifică avizul furnizorului tău, nu doar comparația cu upstream; intrarea din Debian Security Tracker, linkată mai jos, e un bun punct de plecare pentru Debian și derivatele Ubuntu.
Verifică ce rulezi, apoi decide
# Kernelul care rulează
uname -r
# E modulul SCTP încărcat acum?
lsmod | grep -i sctp
# E măcar disponibil pentru încărcare?
modinfo sctp 2>/dev/null | head -3 || echo "modulul sctp nu e prezent"
# Ascultă ceva efectiv pe SCTP?
ss -a --sctp 2>/dev/null || echo "fara socketuri sctp / ss fara suport sctp"Mitigarea pragmatică: majoritatea nu aveți nevoie de SCTP
SCTP e un protocol real, cu utilizatori reali — transportă semnalizare în nucleele de telecomunicații și apare în unele stive de clustering și în canalele de date WebRTC. Dar pe marea majoritate a serverelor web, gazdelor de aplicații, runner-elor de CI și nodurilor Kubernetes e pur și simplu compilat și niciodată folosit.
Dacă asta descrie parcul tău, împiedicarea încărcării modulului elimină complet suprafața de atac și nu costă nimic, ceea ce o face o măsură de urgență mai bună decât așteptarea unei ferestre de repornire.
- Confirmă că nimic nu depinde de SCTP înainte de blacklist — telecom, SS7/Diameter, unele workload-uri SIP și de clustering chiar îl folosesc
- Patch-uiește oricum. Blacklist-ul e o mitigare rapidă pentru fereastra de expunere, nu un înlocuitor pentru un kernel remediat
- Prioritizează gazdele multi-tenant și platformele de containere, pentru că acolo scenariul de evadare din container are cea mai mare valoare pentru un atacator
# Împiedică încărcarea modulului (persistent)
echo "install sctp /bin/true" | sudo tee /etc/modprobe.d/disable-sctp.conf
echo "blacklist sctp" | sudo tee -a /etc/modprobe.d/disable-sctp.conf
# Descarcă-l acum, dacă e încărcat și nefolosit
sudo modprobe -r sctp 2>/dev/null || echo "in uz sau neincarcat"
# Verifică să rămână afară după repornire
lsmod | grep -c sctpCine l-a găsit și de ce contează în continuare
SCTPhantom a fost raportat de cercetători de la Tencent Zhuque Lab, care lucrează la un proiect numit Corvus AI. Asta îl face a doua descoperire asistată de AI pe care o acoperim în trei zile, după lanțul WordPress XSS2Shell reprodus de un sistem autonom multi-agent în aproximativ patru zile.
Două puncte de date nu fac o tendință, dar direcția e consistentă cu ce scriam atunci: optsprezece ani de review uman nu au scos la iveală acest bug, iar analiza automată da. Pentru apărători, consecința practică rămâne aceeași și merită repetată — presupune că intervalul dintre „acest defect există în stack-ul tău" și „cineva știe de el" se comprimă și setează-ți cadența de patch pentru realitatea aceea, nu pentru cea în care am crescut.
Awarely Monitor urmărește NVD, CISA KEV, EUVD și GitHub Advisories față de propriul tău inventar de active, cu prioritizare CVSS + EPSS, SLA tracking și audit trail imutabil — ca un CVE de kernel care afectează distribuția pe care chiar o rulezi să ajungă la echipa ta ca alertă, nu ca titlu pe care îl citește cineva întâmplător luni dimineață.
Surse și verificare
Deschide sursele originale pentru context, actualizări și formularea exactă a afirmațiilor.