O eroare de memorie veche de 16 ani dintr-o componentă folosită la pornirea prin rețea poate permite executarea de cod înainte ca sistemul de operare și mecanisme precum Secure Boot să intre în funcțiune. Vulnerabilitatea CVE-2026-97631 are un scor de severitate de 9,5 din 10 și afectează codul open-source TianoCore EDK II, utilizat pe scară largă la construirea firmware-ului UEFI pentru servere și centre de date.
Problema nu înseamnă că orice server conectat la internet poate fi compromis printr-un singur exploit. Atacul presupune acces la rețeaua locală, transmiterea mesajului în timpul pornirii prin PXE și adaptarea exploitului la configurația dispozitivului vizat, însă momentul execuției îi oferă atacatorului o poziție neobișnuit de puternică.
O eroare în PXE care apare înaintea sistemului de operare
EDK II este o bază de cod de referință folosită de producătorii de hardware și furnizorii de cloud pentru a crea firmware UEFI. Un reprezentant al UEFI Forum a descris-o anul trecut drept „soluția de referință” pentru implementarea specificațiilor UEFI, iar furnizori precum AMI, Insyde și Phoenix folosesc extensiv codul său; și Project Mu, ramura EDK II consolidată de Microsoft, a inclus componenta vulnerabilă.
CVE-2026-97631 se află în driverul PXE-Base Code, identificat prin calea NetworkPkg/UefiPxeBcDxe. Acesta permite serverelor, echipamentelor de stocare și altor dispozitive să pornească folosind cod descărcat dintr-o rețea locală, într-un proces cunoscut drept pornire în mediul de preexecuție, sau PXE.
În această etapă, driverul păstrează deschisă o solicitare de recepție pentru mesaje de eroare ICMP și copiază datele într-un câmp fix de 504 octeți, numit Mode.IcmpError, dintr-o structură privată. Defecțiunea apare deoarece rutina de copiere nu gestionează corect limitele, iar traseul de recepție nu restricționează anterior lungimea mesajului.
Sursă foto: AI
Avizul TianoCore arată că problema există atât în handlerul IPv4, PxeBcIcmpErrorDpcHandle, cât și în cel IPv6, PxeBcIcmp6ErrorDpcHandle. Pentru mesajele mai mari de 504 octeți, codul continuă să copieze date în câmp și avansează indicatorul destinației folosind lungimea cumulată, nu lungimea fragmentului curent; astfel, date controlate de atacator pot suprascrie memoria adiacentă.
Un mesaj ICMP malițios poate fi transmis printr-o comunicare unicast către adresa IP a dispozitivului, de la orice distanță de rețea, dacă ajunge în fereastra de pornire PXE. În varianta mai simplă, acesta poate bloca procesul de boot; dacă atacatorul cunoaște versiunea firmware-ului, poate încerca să declanșeze un „eveniment contrafăcut” care execută cod în mediul UEFI.
Codul ar rula în ring 0, cel mai privilegiat nivel de execuție al procesorului, înainte ca sistemul de operare și unele măsuri de apărare să fie disponibile. Potrivit materialului, atacul poate ocoli și procese de atestare care încearcă să demonstreze criptografic unor servere la distanță că echipamentul este sigur, ceea ce poate transforma un acces limitat într-un nivel superior de control.
De ce fereastra de boot schimbă miza
Secure Boot construiește un lanț de încredere pentru codul încărcat în timpul pornirii, inclusiv componente asociate Trusted Platform Module (TPM). Dar o vulnerabilitate exploatată înainte ca aceste mecanisme să-și poată aplica protecțiile oferă atacatorului ocazia de a interveni într-o etapă sensibilă a pornirii.
Alex Matrosov, de la Anthropic, și Dan Holmes, de la Google, au descoperit vulnerabilitatea și conveniseră ca informațiile să rămână confidențiale până la o divulgare coordonată programată pentru ianuarie. Situația s-a schimbat după ce AMI, producător de plăci de bază și alte echipamente, a publicat luna trecută o cerere de modificare a codului care descria problema și includea remedierea.
După ce cercetătorii au aflat de publicarea cererii, membrii proiectului TianoCore au emis săptămâna trecută un aviz public. Codul de remediere disponibil public poate ajuta atacatorii avansați să înțeleagă cum se declanșează defectul și să construiască exploituri funcționale, în timp ce actualizarea firmware-ului pe dispozitive provenite de la numeroși producători este lentă și dificilă.
Divulgarea a venit la șase zile după un alt incident de publicare gestionată defectuos, legat de o vulnerabilitate critică de execuție de cod în limbajul PHP. În cazul firmware-ului, decalajul dintre publicarea detaliilor și disponibilitatea actualizărilor pentru toate modelele poate lăsa administratorii cu puține instrucțiuni aplicabile imediat.
HD Moore, creatorul Metasploit și director de cercetare la Dragos, a spus că defectul din parserul ICMP al stivei de rețea EDK II este important prin efectul său asupra lanțului de încredere. Un atacator care a compromis deja un punct final sau un server din apropiere ar putea deturna fluxul de execuție când firmware-ul are încă acces la componente sensibile, precum TPM.
Moore a avertizat că această poziție ar putea fi folosită pentru a compromite criptarea discului atunci când atacatorul obține temporar acces la rețea; într-un scenariu de furt al dispozitivului, exploatarea ar putea fi și mai ușoară. Totuși, materialul nu indică faptul că CVE-2026-97631 ar oferi, de una singură, o cale inițială de intrare într-o rețea.
Exploatarea cere acces local și firmware potrivit
Sunt necesare mai multe condiții pentru un atac reușit: sistemul trebuie să pornească prin PXE, să folosească firmware bazat pe EDK II și să fie expus în timpul secvenței de boot. Deși funcționalitatea PXE este activată implicit în configurațiile vizate, vulnerabilitatea nu afectează utilizatorii casnici sau birourile mici care își pornesc dispozitivele exclusiv de pe disc.
Jesse Michael, cercetător principal la firma de securitate firmware Eclypsium, a explicat că atacatorul trebuie să ghicească anumite adrese din sistemul vizat. Prin urmare, nu este vorba despre un exploit universal care poate fi folosit fără modificări împotriva unor echipamente diferite: acesta trebuie ajustat pentru fiecare model, versiune și configurație, deoarece adresele se schimbă.
Cerința de acces la rețea limitează probabil atacul la persoane din interior sau la grupuri care au obținut deja acces de nivel scăzut, inclusiv actori statali ori operatori de ransomware, și caută să-și mărească privilegiile. Nu există, în materialul publicat, dovezi că vulnerabilitatea a fost exploatată în atacuri reale sau că ar constitui un vector inițial de compromitere.
Riscul amintește de alte vulnerabilități din UEFI și din componentele care lucrează cu acesta. LogoFail a pornit de la erori în procesarea imaginilor cu sigle incluse în firmware-ul multor producători, iar PixieFail a implicat probleme de pornire PXE în EDK II; după descoperirea acesteia au fost lansate proiecte de fuzzing pentru a găsi alte defecte, fără ca eforturile să identifice vulnerabilitatea actuală.
Lista include și PKFail, o problemă de lanț de aprovizionare în care chei de testare, neadecvate pentru produse comerciale, au rămas publice mai mult de un deceniu și au fost folosite în sute de modele. BootHole, Bootkit și BlackLotus sunt alte exemple de amenințări legate de pornire, atractive pentru atacatori deoarece pot viza sistemele înainte de încărcarea sistemului de operare și a apărărilor asociate.
Moore consideră că amploarea utilizării EDK II face probabil ca această vulnerabilitate să rămână o problemă pe termen lung în sistemele ajunse la sfârșitul perioadei de suport — un „bug perpetuu”. Spre deosebire de unele atacuri care ocolesc Secure Boot, Michael spune că remedierea poate fi un patch de cod obișnuit, livrat printr-o actualizare BIOS/UEFI, fără revocări sau modificări ale cheilor PK, KEK, db și dbx ori actualizări ale sistemului de operare și mediilor de instalare.
Ce trebuie să facă organizațiile din România și UE
Pentru companiile, instituțiile publice și furnizorii de infrastructură din România și Uniunea Europeană, primul pas este inventarierea sistemelor care folosesc pornirea prin rețea, nu presupunerea că toate serverele sunt vulnerabile sau, dimpotrivă, sigure. Administratorii ar trebui să verifice modelul, versiunea și producătorul firmware-ului, precum și dacă implementarea folosește EDK II și driverul PXE afectat.
Organizațiile trebuie să ceară instrucțiuni de la producătorul sistemului sau al firmware-ului și să urmărească publicarea actualizărilor BIOS/UEFI. Dacă pornirea prin rețea nu este necesară operațional, dezactivarea temporară a funcției reduce suprafața de atac; acolo unde PXE este esențial pentru administrare, accesul la segmentul de rețea relevant ar trebui limitat și supravegheat atent.
TPM și Secure Boot trebuie activate acolo unde este posibil, dar nu trebuie tratate ca soluție directă pentru această problemă: exploatarea poate avea loc înainte ca aceste protecții să fie aplicate. Echipele de securitate ar trebui, de asemenea, să monitorizeze jurnalele și telemetria disponibilă pentru indicii de tentative în perioada de boot, fără a interpreta lipsa alertelor drept dovadă că firmware-ul este sigur.
Pozițiile furnizorilor nu clarifică încă situația pentru întregul ecosistem. Intel a declarat că nu cunoaște produse comerciale aflate în prezent sub suport de securitate care să fie afectate și a spus că funcționalitatea EDK II vulnerabilă nu este inclusă în codul său de referință, deși un producător OEM de plăci de bază sau sisteme o poate integra; compania recomandă clienților să ceară îndrumare producătorului.
Această precizare nu închide întrebarea: codul de referință Intel disponibil public face referire la EDK II, iar TianoCore afirmă că fiecare kit de dezvoltare UEFI furnizat de Intel este o implementare validată pentru o anumită versiune a codului EDK II. Numeroase documente Intel menționează, de asemenea, EDK II, astfel că răspunsul companiei nu poate fi extrapolat automat la toate sistemele construite de parteneri.
Arm a afirmat că CVE-2026-97631 nu se aplică direct portofoliului său de produse. Totuși, firmware-ul pe care îl pune la dispoziție folosește și el cod EDK II, iar TianoCore a documentat această dependență; asta nu dovedește că fiecare produs Arm este vulnerabil, dar justifică verificarea implementării concrete de către producătorii de sisteme.
AMD, Phoenix Technologies, AMI, Microsoft și Amazon nu răspunseseră solicitărilor de comentarii la momentul publicării materialului, iar reprezentanții TianoCore nu au răspuns nici ei. În lipsa unor informații detaliate despre utilizarea EDK II și despre modelele afectate, nu se poate stabili câte dispozitive sunt vulnerabile și ce acțiuni sunt disponibile pentru fiecare platformă.
Până la clarificarea situației, organizațiile ar trebui să trateze verificarea firmware-ului ca pe o prioritate de administrare, mai ales în centrele de date și mediile care folosesc PXE pentru instalare sau recuperare. Defectul nu transformă orice server într-o țintă accesibilă de la distanță, dar arată cât de mult poate conta o eroare veche atunci când este activată într-un moment în care sistemul încă nu și-a pornit apărarea.
