Patch-uri de securitate Magento aplicate la timp, 2FA pe admin, scan curat: ai bifat tot ce ține de platformă. Totuși, pe 15 octombrie 2026, echipa kernelului Linux a publicat CVE-2026-98432, o vulnerabilitate notată cu 9,8 din 10, prezentă în Linux din 2016. Mai jos ai 5 întrebări care arată în câteva minute dacă serverul e la adăpost.
Ce este CVE-2026-98432 și de ce contează
Vulnerabilitatea vizează mecanismul prin care Linux deschide fiecare conexiune TCP. La începutul unei conexiuni, kernelul negociază cu clientul și salvează opțiunile din pachetul de start. Bug-ul, un use-after-free, lasă două operațiuni să ruleze simultan: una golește zona de memorie, alta o citește. De aceea poartă numele de condiție de cursă: rezultatul depinde de momentul în care sosesc pachetele. Nu ai nevoie de parolă, de cont și nici de acces în panoul de administrare.
Scara problemei se vede din trei detalii. Scorul CVSS este de 9,8 din 10, nivelul critic maxim, pentru că atacatorul nu are nevoie de privilegii. Defectul există din Linux 4.4, versiune lansată în 2016, deci practic orice server vechi îl poartă. Iar aproape fiecare magazin online rulează pe Linux, deci zona de expunere e cât se poate de reală.
Riscul nu lasă urme în logurile aplicației, pentru că dialogul are loc sub ea, la nivel de pachete. Apărarea concretă există însă în buletinul AWS: o regulă de firewall care aruncă pachetele IPv4 cu opțiuni, exact traficul de care are nevoie condiționarea exploitului. E o măsură de urgență, nu un înlocuitor, pentru că filtrarea rețelei nu repară memoria kernelului. De aceea lista ta de priorități începe cu patch-ul și continuă cu filtrarea.
Securitate Magento: capcana stratului invizibil
Patch-urile de securitate Magento rezolvă problemele aplicației, nu problemele mașinii pe care rulează. Fiecare magazin stă pe un stack cu mai multe straturi: aplicația, PHP, baza de date și serverul web, apoi kernelul dedesubt. Un CVE de la nivel de kernel trece neobservat exact pentru că nu apare în niciun buletin Adobe. Deci întrebarea utilă se mută de la patch-urile magazinului la ce primește sistemul de operare. Stratul de jos setează regulile pentru toate celelalte. Un kernel compromis citește, modifică sau trimite orice trece prin server, inclusiv sesiunile de admin. Iar alegerea serverului se face la început: ce cere un server dedicat ecommerce l-am detaliat separat.
Aici intră în scenă partea care a făcut valuri în comunitatea de securitate. Cercetătorul Xinyang Ge, de la Anthropic, a raportat defectul. Pe 27 octombrie, Anthropic a anunțat că modelul Claude a construit un exploit funcțional, cu comenzi de root. Ținta e mai îngustă: servere cu Multipath TCP (MPTCP) activ, funcție care unește rute de rețea diferite. Pe sistemele de tip Red Hat, funcția stă oprită din fabrică. Pe lângă asta, programele scrise în Go 1.24 o activează implicit. Exploitul nu e public, iar echipa CloudLinux a anunțat public că nu l-a putut reproduce în laboratorul lor.
Cum a decurs criza patch-urilor, cronologic
Fixul a ajuns în kernelul Linux pe 5 octombrie 2026, cu doar două linii de cod schimbate, semnate Eric Dumazet. Restul lunii a arătat exact cine și cât de repede își sincronizează distribuția de kernel. Oracle a livrat patch-uri pentru kernelurile UEK încă din 16 octombrie, iar Debian a urmat între 16 și 22 octombrie. Red Hat a livrat kernelurile corectate în primele zile ale lui noiembrie, iar Rocky Linux, obișnuit pe serverele de magazin, a urmat pe 3 noiembrie. Numerotarea versiunilor derutează: un kernel 6.12.0-211.73 poate conține fix-ul dintr-o linie 6.12.113 upstream, pentru că distribuția adaugă corecția prin backport.
Ubuntu e lecția inversă. La finalul lunii octombrie, distribuția rămânea încă fără kernel corectat, deși NCSC Irlanda și AWS publicaseră deja avertizări proprii. Detaliul contează acum, pentru că hostingul magazinului tău poate rula oricare dintre aceste distribuții, fără să afli tu. Update-ul instalat nu înseamnă nimic până nu repornești serverul, pentru că kernelul vechi rămâne în memorie, împreună cu vulnerabilitatea. De aceea un plan real include un reboot programat, nu doar un update rulat.
Cinci întrebări pe care le pui astăzi hostingului
Întrebările de mai jos transformă un subiect tehnic într-o discuție de cinci minute. Le poți trimite ca atare furnizorului de hosting sau echipei tale tehnice. Apoi răspunsurile îți arată dacă serverul e la zi sau doar presupus la zi. Formula merge la fel de bine pe mail, în conversație sau în ședința de luni dimineață. Diferența dintre cele două stări s-a văzut perfect în octombrie.
- Ce versiune de kernel rulează acum pe server? Comanda uname -r dă răspunsul în două secunde. Compari apoi versiunea cu erratele distribuției, nu cu versiunile upstream, pentru că fiecare distribuție adaugă fix-ul prin backport.
- Errata din 3 noiembrie e aplicată pe kernelul care chiar rulează? Un pachet descărcat nu modifică nimic din ce se execută acum. Kernelul activ se schimbă doar la repornire.
- Când e următoarea fereastră de reboot? Un reboot planificat ține câteva minute și se programează în afara orelor de vârf. Aproape orice hosting de calitate face asta la cerere.
- Multipath TCP e activ pe server? Implicit, pe distribuțiile de tip Red Hat, funcția stă oprită, deci vectorul cunoscut al exploitului nu există. Verifici totuși, pentru că aplicațiile scrise în Go modern îl pot porni.
- Cine urmărește erratele de securitate și cu ce ritm le aplică? Un furnizor serios de securitate Magento are proces: anunț, test, fereastră de mentenanță, confirmare. Întreabă care e timpul obișnuit dintre publicare și aplicare.
Un set de răspunsuri clare te scapă de presupuneri. Un furnizor pregătit răspunde în aceeași zi, cu versiuni exacte și date concrete. Un furnizor care tratează erratele de kernel ca pe o formalitate răspunde cu promisiuni. Aici un serviciu de găzduire web matur face diferența, pentru că urmează erratele ca patch-urile de aplicație, urgent și confirmat.
Decizia ta de astăzi: ce aplici și ce eviți
Decizia corectă nu ține de panică, ține de ritm. CVE-2026-98432 are fix public, kernelurile corectate există pentru distribuțiile mari și aplicarea se rezolvă cu un update plus un reboot scurt. În noaptea de 3 spre 4 noiembrie am trecut propriile servere prin update. Apoi am confirmat kernelul nou rulat, serviciu cu serviciu. Exact dovada asta o ceri și de la furnizorul tău, nu promisiuni goale.
Patru greșeli lasă magazinele expuse la exact acest tip de risc. Le vedem în proiectele pe care le menținem chiar acum, la verificările de după incident. Vestea bună e că toate se repară cu obiceiuri simple, nu cu buget nou. Iar sezonul de vânzări care vine nu iartă experimentele.
- Aplici update, dar nu repornești. Kernelul rulat rămâne cel vechi, deci vulnerabilitatea tot acolo stă. Ceri confirmarea versiunii după repornire.
- Presupui că hostingul s-a ocupat. Presupunerea e gratuită doar până la primul incident. O întrebare de un minut o înlocuiește.
- Aștepți sezonul liniștit. Black Friday e la orizont, deci ferestrele de mentenanță se strâng. Patch-ul se aplică acum, în fereastră controlată, nu după vârf.
- Tratezi securitatea ca pe un strat unic. Aplicația, PHP-ul, baza de date și kernelul au calendarul lor de patch-uri. Monitoring-ul care le urmărește pe toate merită locul în checklist.
Securitate Magento nu se oprește la platformă, ci se termină în kernelul serverului. Platforma, modulele și PHP-ul au ritmul lor de patch-uri. Sistemul de operare cere la fel. Octombrie 2026 a arătat ce costă stratul uitat. Dacă menții un magazin online Magento 2, pune kernelul în același ciclu lunar cu aplicația. Iar dacă vrei pe cineva care bifează aceste calendare pentru tine în fiecare lună, drumul scurt trece prin pagina de contact.
