În octombrie 2026, kernelul Linux, partea de sistem care stă sub fiecare magazin online, a primit cea mai gravă notă de securitate posibilă. CVE-2026-98432, 9,8 din 10, prezent în Linux din 2016. Vestea bună e că rezolvarea e simplă, deci un update de kernel și o repornire acoperă problema. În articol îți explic problema, povestea și pașii concreți de securitate Magento.
Problema, explicată simplu
Kernelul e partea din Linux care deschide și ține fiecare conexiune făcută spre magazinul tău. La fiecare conexiune nouă, sistemul își notează câteva detalii despre ea, ca pe o fișă de monitorizare. Bug-ul lasă două acțiuni să lucreze pe aceleași note deodată: una le golește, cealaltă le mai citește. Din întâlnirea asta poate ieși o eroare gravă. Iar declanșarea se face de la distanță, printr-un pachet pregătit special, fără parolă și fără cont.
Gravitatea se vede din scorul de 9,8 din 10, cel mai ridicat nivel de risc folosit în industrie. Defectul e prezent în Linux din 2016, deci fiecare server neactualizat de ani îl are deja în el. Iar pentru că aproape orice magazin online rulează pe Linux, securitate Magento include obligatoriu și serverul. Riscul nici nu lasă urme în rapoartele magazinului, pentru că totul se întâmplă sub aplicație.
Apărare există și la nivel de rețea, pentru serverele care nu pot fi atinse imediat. Buletinul AWS include o regulă de firewall care aruncă pachetele cu opțiuni, exact tipul de trafic folosit la declanșare. E o măsură de urgență, nu un înlocuitor, pentru că filtrul nu repară memoria serverului. Ordinea rămâne aceeași: întâi update-ul de kernel, apoi filtrul ca protecție suplimentară.
Povestea: cum a apărut și de ce contează acum
Povestea începe în 2016, când o modificare aparent banală din Linux a adus defectul. Nouă ani mai târziu, cercetătorul Xinyang Ge, de la Anthropic, l-a raportat. Echipa kernelului l-a rezolvat pe 5 octombrie 2026, cu doar două linii de cod modificate de inginerul Eric Dumazet. Apoi luna octombrie a transformat un fix tehnic într-o poveste de piață. Pe 27 octombrie, Anthropic a anunțat că modelul său Claude a scris un exploit funcțional, cu comenzi de administrator. Exploitul nu e public, iar echipa CloudLinux a spus limpede că nu l-a putut reproduce în testele lor. Deci povestea arată cât de repede se mută riscul de la teorie la exploit funcțional.
- 5 octombrie 2026 — fix-ul intră în Linux, cu două linii de cod schimbate. E momentul în care problema devine rezolvabilă.
- 15 octombrie 2026 — echipa kernelului publică CVE-2026-98432, cu scorul de 9,8. Toată lumea află oficial ce se întâmplă.
- 16–22 octombrie — Oracle și Debian livreză primele kerneluri corectate, iar Debian acoperă ambele versiuni aflate în suport.
- 27–29 octombrie — Anthropic dezvăluie exploitul construit de Claude, iar Go anunță că versiunile 1.24 pornesc Multipath TCP implicit.
- 30 octombrie — NCSC Irlanda și AWS publică avertizări proprii, dar Ubuntu rămâne încă fără kernel corectat.
- 1–3 noiembrie — Red Hat livrează kernelurile reparate, iar Rocky Linux, des folosit la serverele de magazin, îl urmează pe 3 noiembrie.
Repornirea e, tocmai de aceea, partea care se uită cel mai des la update-urile de kernel. Update-ul instalat nu schimbă nimic din ce rulează, pentru că kernelul vechi rămâne în memoria serverului, odată cu vulnerabilitatea. Confirmarea înseamnă comanda uname -r pe server, nu un simplu mesaj că pachetul a rulat. În securitate Magento, planul se termină la repornire confirmată, nu la pachet descărcat.
Soluția clară: update de kernel și repornire
Aici nu e nevoie de manevre complicate. Kernelurile corectate există pentru toate distribuțiile mari, deci aplicarea înseamnă update la pachetul de kernel, apoi repornirea serverului în fereastră programată, anunțată din timp. În proiectele Incognito, update-urile se rulează pe rând, server cu server, și se termină în săptămâna aceasta. Deci subiectul are un termen clar, fără servere lăsate pe din urmă.
Dacă serverul e administrat de un furnizor, cererea e simplă: kernel la zi, repornire la ora stabilită, versiune confirmată după. Un serviciu de găzduire web matur face asta de rutină, la fel ca patch-urile de aplicație. Iar dacă tu administrezi serverul, ordinea e aceeași, doar că mâinile sunt ale tale. Alegerea resurselor se face de la începutul proiectului, nu după primul incident. Cum arată un server potrivit pentru magazin am detaliat în articolul despre server dedicat ecommerce.
Operațiunea pe partea de server are patru pași, tocmai ca magazinul să nu fie luat prin surprindere. Începe cu un check complet pe servere, continuă cu un pre-check de restart și cu update-ul de kernel. Apoi urmează monitorizarea repornirii și verificarea tuturor serviciilor după restart. Durata e în jur de 25–75 de minute de la magazin la magazin, în funcție de configurația clusterului fiecăruia. Iar toate se anunță înainte, ca echipa de mentenanță să nu improvizeze.
Partea de TCP: cum stați cu riscul
Exploitul cunoscut azi țintește serverele cu Multipath TCP pornit, o funcție care unește mai multe rute de rețea. Pe sistemele de tip Red Hat, care domină hostingul comercial, funcția stă oprită din fabrică. Pe lângă asta, programele scrise în Go 1.24 o pot porni singure. Red Hat subliniază în buletinul oficial că funcția nu e o condiție obligatorie pentru vulnerabilitate.
Deci pe majoritatea serverelor comerciale din România, cu distribuții din familia Red Hat, exploatarea cunoscută nu se poate desfășura așa cum a fost prezentată. Rămâne în picioare riscul general al cursei de conexiuni. Asta se închide doar cu kernelul corectat. Pentru un comerciant, scenariul din știri e mai puțin probabil, dar nu imposibil. Asa ca prioritatea nu se schimbă: update-ul și repornirea rămân planul principal.
Securitate Magento: ce aplici de acum înainte
Lecția din octombrie se rezumă la trei rânduri de acțiune. Mai exact, verifici ce versiune de kernel rulează acum pe serverul magazinului tău. Apoi o aduci la nivelul corectat de distribuția ta, cu update din repo. La final, programezi repornirea și confirmi versiunea care a rămas după. Dacă platforma, modulele și PHP-ul au deja calendarul lor de patch-uri, adaugi Linux-ul în același ciclu lunar. Iar magazinul online Magento 2 primește așa acoperire completă, de la aplicație până la sistem.
Securitate Magento nu se oprește la platformă, ci se termină în Linux-ul serverului. Octombrie 2026 a arătat cât costă nivelul pe care nimeni nu-l mai verifică luni de zile. Cu un update, o repornire și un minut de verificare TCP, subiectul se închide curat. Iar dacă vrei pe cineva care ține aceste calendare la zi pentru tine în fiecare lună, drumul scurt trece prin pagina de contact.
