Vulnerabilitate critică a kernelului Linux CVE-2026-98432: Cum să verificați și să actualizați VPS-ul

În octombrie 2026, o vulnerabilitate critică, CVE-2026-98432 , a fost descoperită în kernelul Linux, fiind evaluată cu 9.8 din 10 pe scara CVSS. Aceasta afectează modul în care sunt gestionate conexiunile TCP IPv4 primite și, în anumite condiții, permite unui atacator să obțină acces root la un server de la distanță - fără parolă și fără a fi necesară nicio acțiune din partea administratorului.

Mai jos este prezentat cine este afectat, cum să verificați serverul și cum să îl protejați. Toate comenzile sunt executate ca root sau cu sudo.

Vulnerabilitatea pe scurt

• Ce este: o eroare de tip „use-after-free” în codul care configurează conexiunile TCP IPv4, cauzată de o condiție de concurență. Atacatorul trimite pachete special concepute către orice port TCP deschis.
• Boabele afectate: fiecare versiune de la Linux 4.4 încoace, ceea ce înseamnă practic fiecare distribuție actuală.
• IPv6 nu este afectat de eroarea principală.
• Cât de reală este amenințarea: Cercetătorii de la Anthropic au demonstrat un lanț de exploit-uri funcțional care a obținut acces root pe un server cu Multipath TCP (MPTCP) activat în aproximativ 53 de minute. Codul exploit-ului nu a fost publicat.
• Atacuri în sălbăticie: La 1 noiembrie 2026, nu a fost raportată nicio exploatare. Acesta este un motiv pentru a actualiza cu calm, nu pentru a o amâna.

Serviciile Go prezintă un risc separat. Începând cu versiunea Go 1.24, programele server de pe Linux ascultă porturi prin MPTCP în mod implicit, ori de câte ori kernelul permite acest lucru. Un administrator poate nici măcar să nu știe că serverul său acceptă astfel de conexiuni. Printre programele populare, Xray funcționează în acest fel - dezvoltatorii săi au lansat deja o versiune de urgență, v26.10.31, care dezactivează MPTCP în mod implicit.

Fiecare VPS rulează propriul kernel, așa că trebuie să actualizați singur kernelul din server. Noi actualizăm singuri nodurile de virtualizare.

Există o soluție pentru sistemul tău?

Starea la 1 noiembrie 2026. Corecțiile apar aproape zilnic — verificați linkurile de la sfârșitul acestui articol pentru starea actuală.

Pasul 1. Verificați ce kernel rulați

Află versiunea kernelului care rulează:

uname -r

Numărul versiunii în sine nu spune nimic: distribuțiile retroportează corecțiile în propriile kernel-uri fără a modifica versiunea de bază. Este mai sigur să verificați jurnalul de modificări al pachetului kernel - dacă acesta menționează numărul CVE, corecția este deja instalată.

Debian și Ubuntu:

apt changelog linux-image-$(uname -r) 2>/dev/null | grep CVE-2026-98432

Pe Debian, uname -v Comanda afișează și versiunea completă a pachetului kernelului care rulează: comparați-o cu tabelul de mai sus.

AlmaLinux, Rocky Linux, RHEL, Oracle Linux:

rpm -q --changelog kernel-core-$(uname -r) | grep CVE-2026-98432

Dacă comanda nu afișează nimic, kernelul care rulează este vulnerabil.

Apoi, verificați ce servicii acceptă conexiuni prin MPTCP. Servere ca acestea au fost ținta atacului demonstrat:

ss -lnMp

O ieșire goală înseamnă că nu există listener-e MPTCP.

Pasul 2. Instalați kernelul fix

Faceți o copie de rezervă sau o captură de ecran a serverului înainte de a actualiza kernelul.

Debian 12 și 13

Nucleele reparate se află în depozitul de securitate. Asigurați-vă că este activat:

grep -r security.debian.org /etc/apt/sources.list /etc/apt/sources.list.d/

Dacă nu se găsește nimic, adăugați security.debian.org repozitoriul pentru versiunea dvs. Apoi actualizați sistemul:

apt update
apt full-upgrade
reboot

Ubuntu

Nucleele reparate nu au fost încă lansate. Verificați dacă există actualizări:

apt update
apt list --upgradable | grep linux-image

Dacă serverul dvs. este conectat la Ubuntu Pro, puteți verifica planul de remediere:

pro fix CVE-2026-98432 --dry-run

După ce remedierea este lansată, instalați-o și reporniți sistemul:

apt update
apt full-upgrade
reboot

Până atunci, asigură-te că aplici protecția temporară de la Pasul 3.

AlmaLinux 8, 9, 10

Nucleele reparate sunt disponibile în prezent doar în depozitul de testare. Instalați-le dacă vă simțiți confortabil să faceți acest lucru pe un server de producție și asigurați-vă că faceți o instantanee înainte de actualizare:

dnf install -y almalinux-release-testing
dnf update 'kernel*' --enablerepo=almalinux-testing
dnf config-manager --disable almalinux-testing
reboot

După repornire, comparați uname -r cu versiunile din tabelul de mai sus. Dacă preferați să nu instalați pachete de testare, aplicați protecția temporară și așteptați ca remedierea să ajungă în depozitul principal.

Rocky Linux și alte sisteme bazate pe RHEL

Încă nu există o soluție. O poți urmări cu:

dnf --refresh updateinfo info --all --cves CVE-2026-98432

Odată ce remedierea este lansată:

dnf update kernel
reboot

După actualizare: este necesară o repornire

Noul kernel intră în vigoare doar după o repornire. Pentru a verifica dacă este necesar unul:

# Debian and Ubuntu
[ -f /var/run/reboot-required ] && echo "Reboot required"

# AlmaLinux, Rocky, RHEL
needs-restarting -r

După repornire, repetați verificarea de la Pasul 1.

Pasul 3. Protecție temporară până când este disponibil un kernel fix

Aceste măsuri reduc riscul, dar nu înlocuiesc o actualizare a kernelului.

Blocați pachetele declanșatoare

Atacul folosește pachete TCP cu opțiuni IP în antetul IPv4. Acestea nu apar practic niciodată în traficul normal, iar RFC 7126 recomandă deja eliminarea lor. Regula nftables de mai jos elimină toate pachetele TCP IPv4 cu opțiuni primite și nu afectează IPv6, UDP sau ICMP. Funcționează alături de ufw și firewalld.

Instalați nftables dacă nu este deja instalat:

# Debian and Ubuntu
apt install -y nftables

# AlmaLinux, Rocky, RHEL
dnf install -y nftables

Creați fișierul de reguli:

cat > /etc/cve-2026-98432.nft <<'EOF'
table ip cve_2026_98432 {
    chain pre {
        type filter hook prerouting priority -300; policy accept;
        meta l4proto tcp ip hdrlength gt 5 counter drop
    }
}
EOF

Pentru a restaura regula după fiecare repornire, creați un serviciu systemd:

cat > /etc/systemd/system/cve-2026-98432.service <<'EOF'
[Unit]
Description=Mitigation for CVE-2026-98432
After=network-pre.target nftables.service firewalld.service ufw.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStartPre=-/usr/sbin/nft delete table ip cve_2026_98432
ExecStart=/usr/sbin/nft -f /etc/cve-2026-98432.nft
ExecStop=/usr/sbin/nft delete table ip cve_2026_98432

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now cve-2026-98432.service

Verificați dacă regula este încărcată:

nft list table ip cve_2026_98432

Dacă reporniți serviciul nftables cu o funcție globală flush ruleset domnește, aleargă systemctl restart cve-2026-98432 după aceea.

Important: nu aplicați această regulă în rețele care utilizează etichete CIPSO (SELinux sau Smack NetLabel) — opțiunile IP sunt utilizate în mod normal acolo. Dacă serverul dvs. direcționează traficul către alte mașini, regula va elimina și pachetele TCP ale acestora cu opțiuni IP.

Dezactivați MPTCP dacă nu aveți nevoie de el

sysctl -w net.mptcp.enabled=0
echo "net.mptcp.enabled = 0" > /etc/sysctl.d/99-disable-mptcp.conf

Această setare previne doar nou crearea de socketuri MPTCP. Serviciile care rulează deja vor continua să asculte prin MPTCP, așa că reporniți fiecare serviciu listat de ss -lnMp și asigurați-vă că ieșirea sa este acum goală.

Pe AlmaLinux, MPTCP este dezactivat în mod implicit, cu excepția cazului în care l-ați activat personal.

Dezactivați MPTCP în programele Go

Pentru serviciile construite cu Go 1.24 sau o versiune ulterioară, puteți dezactiva MPTCP cu o variabilă de mediu. De exemplu, pentru un serviciu numit myservice:

systemctl edit myservice

Adăugați următoarele în fișierul care se deschide:

[Service]
Environment=GODEBUG=multipathtcp=0

Apoi reporniți serviciul:

systemctl restart myservice

Actualizare radiografie

Dacă serverul dvs. rulează Xray, actualizați-l la versiunea 26.10.31 sau o versiune ulterioară. Versiunea anterioară, v26.10.29, a fost retrasă de dezvoltatori. Această actualizare dezactivează MPTCP, dar nu remediază kernelul, deci este necesară o actualizare a kernelului.

Bifați încă o setare

O a doua cale de exploatare, mai restrânsă, necesită activarea migrării cererilor. Este dezactivată în mod implicit — asigurați-vă de acest lucru:

sysctl net.ipv4.tcp_migrate_req

Comanda ar trebui să afișeze 0.

Restricționați accesul la serviciile dvs.

Închideți toate porturile firewall care nu trebuie accesibile de pe internet. Pe cât posibil, deschideți serviciile administrative — SSH, panouri de control, baze de date — doar la adrese IP de încredere.

Pasul 4. După instalarea kernelului reparat

1. Reporniți serverul și utilizați comenzile de la Pasul 1 pentru a confirma că kernelul reparat rulează.
2. Puteți elimina regula temporară:
   

   systemctl disable --now cve-2026-98432.service
   rm /etc/systemd/system/cve-2026-98432.service /etc/cve-2026-98432.nft
   systemctl daemon-reload

   
   
3. Dacă aveți nevoie de MPTCP, restaurați setarea: ștergeți /etc/sysctl.d/99-disable-mptcp.conf și fugi sysctl -w net.mptcp.enabled=1.

Dacă ceva nu merge bine

Dacă serverul dvs. nu pornește după actualizarea kernelului, conectați-vă prin consola VNC din panoul de control și selectați kernelul anterior din meniul de boot. Dacă nu sunteți sigur că puteți face acest lucru singur sau aveți nevoie de ajutor cu actualizarea, contactați echipa noastră de asistență.