CVE-2026-97631: cod executat înainte de Secure Boot, dar numai pe mașinile care pornesc din rețea

Vectorul de atac este clasificat drept rețea, cu complexitate scăzută și fără privilegii sau interacțiune din partea utilizatorului. Dar vectorul include și un element pe care mulți îl trec cu vederea: cerințe de atac „prezente”. Adică exploatarea depinde de o condiție care trebuie să existe în mediul țintă.

Condiția aceea, potrivit relatărilor tehnice, este fereastra de boot PXE. Atacul presupune trimiterea unui mesaj de eroare ICMP supradimensionat către o mașină care pornește din rețea, ceea ce poate bloca procesul de boot sau, dacă atacatorul cunoaște build-ul exact de firmware, poate duce la execuție de cod la cel mai înalt nivel de privilegiu, înainte ca Secure Boot să verifice ceva.

Consecința practică este liniștitoare și trebuie spusă clar: mașinile care pornesc doar de pe disc local nu sunt expuse pe acest drum. Dacă nu folosești provizionare prin rețea, urgența scade dramatic — fără ca vulnerabilitatea să dispară din inventarul tău.

• Produs afectat, conform înregistrării publicate de proiect: TianoCore EDK2, componenta NetworkPkg, versiunile până la și inclusiv edk2-stable202608.
• Clasificare: CWE-120, CWE-131 și CWE-787 — depășire de buffer, calcul incorect al dimensiunii și scriere în afara limitelor.
• Scor CVSS 4.0: 9,5, critic, cu impact ridicat asupra confidențialității, integrității și disponibilității, inclusiv asupra sistemelor subsecvente.
• Evaluarea CISA din 30 octombrie 2026, în cadrul metodologiei SSVC: exploatare „niciuna”, automatizabil „nu”, impact tehnic „total”. Cu alte cuvinte, o autoritate spune că nu se observă exploatare, dar că impactul ar fi complet dacă s-ar produce.
• Corecția a fost integrată în amonte, iar proiectul Microsoft mu_basecore are pull request-uri publice pentru preluarea ei — semn că furnizorii de firmware derivat lucrează pe ea.

• Numărul real de servere afectate. Relatările vorbesc despre „majoritatea serverelor”, dar nicio sursă nu oferă o listă de produse sau o cifră verificabilă.
• Starea patch-urilor la nivel de producător. Corecția există în amonte, însă disponibilitatea unui firmware actualizat depinde de fiecare producător de placă sau server, iar relatările notează că mulți nu listaseră încă o versiune corectată.
• Poziția exactă a atacatorului. Înregistrarea oficială clasifică vectorul drept rețea; unele relatări descriu un atacator din rețeaua locală sau adiacentă. Diferența contează pentru modelarea riscului, iar am ales să redăm clasificarea din înregistrarea proiectului, nu interpretările.
• Starea înregistrării în NVD este „Deferred”, ceea ce înseamnă că analiza suplimentară a bazei naționale nu este finalizată.
• Vârsta de aproximativ 16 ani a erorii apare în relatări, nu în înregistrarea oficială.

Un patch de aplicație se aplică de echipa ta. Un patch de firmware îl aștepți de la producătorul plăcii sau al serverului, care îl preia de la furnizorul de firmware, care îl preia din proiectul open-source. Sunt trei verigi între corecția existentă și serverul tău, iar niciuna nu este sub controlul tău.

A doua diferență este momentul execuției. Cod care rulează înainte de Secure Boot rulează înaintea sistemului de operare, a agentului de securitate și a oricărui mecanism de detecție pe care l-ai cumpărat. Nu există log în care să apară, pentru că nu există încă nimic care să scrie loguri.

A treia diferență este durata. O eroare introdusă în cod acum mulți ani se află în fiecare generație de servere livrată de atunci, inclusiv în cele ieșite din suport, pentru care nu va exista niciodată un firmware corectat. Pentru acelea, decizia nu este „când aplicăm”, ci „izolăm sau înlocuim”.

• Întâi stabilește expunerea, nu versiunea. Întreabă echipa de infrastructură o singură întrebare: ce mașini din parcul nostru pornesc prin rețea, fie permanent, fie doar la provizionare? Dacă răspunsul este „niciuna”, ai redus problema la igienă pe termen mediu.
• Dacă folosiți PXE, verificați dacă rețeaua de provizionare este separată de rețeaua de utilizatori. Un VLAN dedicat, accesibil doar din segmentul de administrare, elimină practic poziția de atac.
• Dezactivați stiva de rețea din UEFI pe mașinile care nu au nevoie de ea. Este o setare de firmware, nu o schimbare de arhitectură, și reduce suprafața permanent.
• Cereți producătorului de servere un răspuns scris: afectează CVE-2026-97631 modelele noastre, în ce versiuni de firmware, și când estimați o versiune corectată? Un furnizor care nu răspunde în scris la o întrebare cu CVE este, el însuși, o constatare.
• Faceți lista mașinilor ieșite din suport de firmware. Pentru ele nu va veni nicio corecție, iar decizia aparține conducerii, nu administratorilor.

Nu declanșa o campanie de actualizare de firmware pe întregul parc din cauza acestui CVE. Actualizările de firmware au propriul risc operațional — o mașină care nu mai pornește după un update de BIOS costă mai mult decât o vulnerabilitate fără exploatare observată. CISA notează explicit, la 30 octombrie, că nu se observă exploatare.

Nu trata nici invers, ca pe un non-eveniment. Impactul tehnic evaluat este total, iar odată apărut un exploit public pentru un build de firmware anume, fereastra de reacție este scurtă tocmai pentru că lanțul de livrare a corecției este lung.

Pentru o organizație aflată în sfera NIS2, trasabilitatea acestei decizii — ce aveți, ce este expus, ce ați cerut furnizorului și ce ați decis să amânați, cu termen — susține managementul vulnerabilităților și securitatea lanțului de aprovizionare, fără a echivala automat cu conformitatea legală. Awarely Monitor poate lega CVE-ul de active, responsabili și dovada închiderii; decizia de actualizare rămâne a echipei.