Kernel Linux CVE-2026-98432 (CVSS 9,8): atenuare

Publicat pe 6 noiembrie 2026 · Echipa mitza.es

O mare parte din infrastructura firmelor rulează pe Linux fără ca cineva să-și amintească: serverul web al magazinului online, mașina virtuală care găzduiește programul de gestiune, un container în cloud sau un echipament de rețea. Pe 30 octombrie 2026, Red Hat a publicat un buletin de securitate despre o vulnerabilitate a kernelului Linux (nucleul sistemului) pe care o identifică drept CVE-2026-98432 și o punctează cu 9,8 din 10. Buletinul a fost actualizat pe 4 noiembrie. Articolul rezumă ce a confirmat Red Hat la data de 6 noiembrie 2026, fără a merge dincolo de ceea ce spun avizele sale.

Ce spune Red Hat

Identificator și gravitate: CVE-2026-98432, buletinul RHSB-2026-016. Scor CVSS 3.1 de 9,8 cu vectorul AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, adică: se atacă prin rețea, în mod simplu, fără privilegii și fără intervenția vreunui utilizator. Red Hat și registrul CVE coincid în privința cifrei. Pentru produsele Red Hat, severitatea este critică.
Ce nu funcționează: o condiție de cursă în gestionarea rețelei TCP. Când sistemul procesează simultan cereri de conexiune retransmise sau migrări de socket-uri, opțiunile socket-ului pot fi eliberate din memorie în timp ce o altă parte a sistemului încă le folosește. Pe înțelesul tuturor: kernelul „aruncă” o dată de care încă are nevoie, iar un atacator ar putea profita de acest gol.
Ce îi trebuie atacatorului: să trimită pachete cu opțiuni IP către un sistem care acceptă conexiuni TCP prin IPv4 și să nimerească momentul exact al două operații concurente. Este un atac la distanță și fără autentificare, dar necesită o sincronizare precisă.
Ce consecințe are: Red Hat menționează refuz de serviciu, coruperea memoriei și execuție de cod la distanță. Execuția fiabilă de cod necesită un control precis al memoriei, așa că aceasta din urmă este cel mai greu de obținut; avizul din buletin o semnalează totuși ca posibilă.
Date: publicat pe 30 octombrie 2026 și actualizat pe 4 noiembrie.

Ce sisteme sunt afectate

Red Hat indică drept afectate direct Red Hat Enterprise Linux 8, 9 și 10 și Red Hat OpenShift Container Platform 4 (nodurile cu RHEL CoreOS). Pot fi afectate și produsele construite pe kernelul RHEL, precum Red Hat OpenStack Platform și Red Hat Virtualization. Sistemele care acceptă conexiuni TCP de intrare sunt cele mai expuse. Nu este necesar ca protocolul MPTCP să fie activ pentru ca riscul să existe.

O precizare importantă: Red Hat documentează doar produsele proprii și nu indică numere de versiune ale kernelului original (upstream) și nici pachete corectate concrete („accelerează publicarea corecțiilor”; starea figurează ca „în curs”). Nu am putut confirma starea în alte distribuții precum Debian, Ubuntu, AlmaLinux sau Rocky; consultă avizul de securitate al distribuției tale înainte să consideri problema exclusă.

Se exploatează deja?

Nici buletinul, nici fișa Red Hat nu spun că vulnerabilitatea este exploatată și nu figurează ca exploatată în informațiile pe care le-am consultat. Asta se poate schimba în orice moment, iar o vulnerabilitate care se atacă prin rețea și fără credențiale este un candidat evident. Merită tratată ca un patch prioritar, nu ca o sarcină pentru următoarea mentenanță.

Ce faci astăzi: lista de verificare

Fă un inventar. Notează ce servere, mașini virtuale, containere și echipamente de rețea din firma ta rulează Linux, cu ce distribuție și cine le gestionează. Dacă le gestionează un furnizor sau o firmă de hosting, cere-i în scris să confirme dacă ești afectat și când va aplica patch-ul.
Verifică versiunea și distribuția. Pe un server Linux, cat /etc/os-release îți dă distribuția, iar uname -r versiunea kernelului.
Aplică actualizarea kernelului imediat ce există pentru distribuția ta. Un kernel nou necesită repornirea sistemului (dacă nu folosești patch-uri la cald), așa că planifică-l din timp. Red Hat spune că este „singura soluție completă”.
Cât timp nu există patch, aplică atenuarea temporară. Red Hat propune respingerea pachetelor TCP de intrare care poartă opțiuni IP, cu o regulă nftables (vezi mai jos).
Limitează ce este expus. Un server care trebuie să servească doar pe tine nu ar trebui să accepte conexiuni de pe tot internetul. Verifică firewall-ul: dacă vrei să revezi cum se organizează, citește ghidul nostru despre ce este un firewall și de ce are nevoie un IMM.
Ai o copie de siguranță recentă și testată înainte să atingi ceva: regula 3-2-1 rămâne asigurarea ta.

Atenuarea temporară propusă de Red Hat

Red Hat propune o regulă nftables care respinge pachetele TCP IPv4 cu opțiuni IP. Se salvează într-un fișier (de exemplu, cve-2026-98432.nft) cu acest conținut:

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

Se verifică cu sudo nft --check --file cve-2026-98432.nft și se aplică cu sudo nft --file cve-2026-98432.nft. Două avertismente din partea Red Hat: regula nu persistă după o repornire și nu înlocuiește patch-ul. După actualizarea kernelului, se elimină cu sudo nft delete table inet cve_2026_98432. Testează regula mai întâi într-un mediu controlat și, dacă nu ești sigur ce faci pe un server de producție, lasă administratorul tău să o aplice.

Ceea ce Red Hat nu recomandă: dezactivarea MPTCP (net.mptcp.enabled=0) nu este o atenuare completă și, de fapt, RHEL îl livrează dezactivat implicit și rămâne vulnerabil. De asemenea, nu se poate folosi ss -Mlnp ca test de expunere. În OpenShift, traficul dintre pod-uri nu are încă o atenuare; Red Hat trimite la un articol de suport specific.

Și dacă nu gestionez servere?

Dacă site-ul tău este pe un hosting partajat sau gestionat, acest patch este responsabilitatea furnizorului: este rezonabil să îl întrebi dacă l-a aplicat deja. Dacă ai un server virtual (VPS) sau un server propriu, îți revine ție sau celui care îl administrează. În orice caz, este un bun prilej să stabilești un termen maxim de aplicare a patch-urilor pentru defectele critice și să verifici că furnizorul te informează atunci când se întâmplă așa ceva. Dacă te gândești să-ți găzduiești infrastructura în afara sediului, acest ghid despre cloud computing pentru IMM-uri te ajută să decizi ce parte gestionează fiecare.

Întrebări rapide

Mă afectează dacă folosesc Windows?

Nu această vulnerabilitate, care este una a kernelului Linux. Dacă folosești Windows, calendarul relevant este cel al actualizărilor lunare; de exemplu, în octombrie a fost un Patch Tuesday cu peste 1.400 de vulnerabilități.

Ce înseamnă „9,8” și este maximul?

Scala CVSS ajunge la 10. Un 9,8 indică un risc foarte mare: acces prin rețea, fără credențiale și cu impact total asupra confidențialității, integrității și disponibilității. Gravitatea reală depinde și de dacă sistemul este expus și de cât de greu este de exploatat, lucru care aici necesită o sincronizare precisă.

Are legătură cu reglementarea NIS2?

Gestionarea vulnerabilităților și a furnizorilor face parte din măsurile așteptate de la companiile vizate de directivă. Contextul îl găsești în ghidul nostru despre reglementarea NIS2 pentru IMM-uri.

Cum te ajutăm la Mitza

Verificăm ce servere și echipamente ai expuse, controlăm versiunile, aplicăm patch-uri și atenuări și lăsăm procesul documentat. Descoperă cum abordăm mentenanța IT pentru IMM-uri sau spune-ne cazul tău din pagina de contact.

Citește și: OpenSSH 10.6p2 și defectul parolelor lungi în Alpine Linux și ransomware în companiile din Spania.

Vulnerabilitate critică în kernelul Linux (CVE-2026-98432): ce servere sunt afectate și cum o atenuezi până apare patch-ul