Da test di regressione a PoC: il caso Abraxas Labs su Chrome V8 Maglev

Abraxas Labs ha pubblicato una proof-of-concept incompleta per CVE-2026-126910 basata sui regression test di Google. Il caso mostra come i test ufficiali di patch possano accelerare la ricostruzione delle vulnerabilità.

Alle 02:23 UTC del 15 novembre 2026, un account GitHub denominato Abraxas Labs ha caricato il repository abraxas/chrome-v8-maglev-literal-stale, una proof-of-concept per CVE-2026-126910. La vulnerabilità è type confusion nel compilatore JIT Maglev di Chrome V8, con CVSS 3.1 pari a 8.8 (High). Il codice deriva in parte dai regression test che gli ingegneri Google hanno incluso nella patch rilasciata il 12 novembre 2026, tre giorni prima.

Punti chiave

Una proof-of-concept incompleta per CVE-2026-126910 è stata pubblicata su GitHub il 15 novembre 2026 da Abraxas Labs.
Il codice è costruito in parte dai regression test ufficiali Google inclusi nella patch del 12 novembre 2026.
L'autore dichiara esplicitamente che il PoC non consente code execution: "This pack is the stale load, not a shell".
La vulnerabilità ha CVSS 3.1 8.8 (High); il bug report Chromium 574059463 era chiuso al pubblico al momento della pubblicazione.
Chrome 157.0.8103.78 corregge la falla; applicazioni Electron rimangono vulnerabili fino ad aggiornamento indipendente.

La meccanica del bug: stale load in Maglev

Il cuore della vulnerabilità risiede nel compilatore JIT Maglev, il tier intermedio di V8 che Chrome attiva prima del più aggressivo TurboFan. Secondo l'analisi di Homeland411 — unica fonte con accesso diretto al repository — il bug si manifesta quando un valore caricato dall'Object.prototype non viene invalidato dopo la creazione di un oggetto o array che modifica il prototype. Il risultato è uno "stale load": il compilatore continua a trattare il valore come di un tipo, mentre il runtime ne ha già cambiato la natura.

La descrizione CVE indica che questa condizione permette "execute arbitrary code inside the sandbox" a un attaccante che induca la vittima a visitare una pagina HTML appositamente costruita. Il vettore è AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. La severità è High, non Critical. La patch, accreditata all'ingegnere V8 Marja Hölttä con review di Darius Mercadier, è arrivata nella release Chrome 157.0.8103.78.

La stessa release ha corretto complessivamente 83 vulnerabilità, tra cui 5 critiche secondo CybersecurityNews. CVE-2026-126910 non rientra in quel gruppo: è classificata High.

Dal test di regressione al repository GitHub

Quello che distingue questo caso è la provenienza del codice. Abraxas Labs ha esplicitato nel README che il PoC è "built in part from a regression test that Google's own engineers shipped with the fix". I regression test servono a garantire che una correzione non introduca nuovi bug: eseguono il codice vulnerabile, verificano che ora fallisca, e restano nel tree sorgente come guardrail.

Quando il test include un input che innesca la condizione di bug — la sequenza di manipolazione del prototype che produce lo stale load — diventa materiale tecnicamente utile per ricostruire la falla. La differenza con un exploit sta nel completamento: il test si ferma alla verifica del comportamento, l'exploit proseguirebbe verso la corruzione della memoria e l'esecuzione di payload. Abraxas Labs non ha tentato questo passaggio.

L'account Abraxas Labs ha pubblicato altri sei repository per CVE patchate nella medesima release Chrome. L'identità dell'account — individuo o gruppo organizzato — non è nota. Il bug report Chromium originale, issue 574059463, era chiuso al pubblico al momento della pubblicazione del PoC.

"This pack is the stale load, not a shell" — Abraxas Labs, README repository GitHub

Limiti confermati del PoC

Il README contiene una dichiarazione rara per chiarezza: "no attempt had been made to turn the flaw into code execution". Il PoC richiede flag sviluppatore per attivare il debugging command che forza il tier-up di Maglev. Il README aggiunge: "a real page would wait for Maglev's normal tier-up", ossia la compilazione JIT che avviene naturalmente dopo ripetute esecuzioni.

Il valore della proof-of-concept, anche incompleta, sta nel dimostrare che la vulnerabilità è riproducibile. Il gap per ottenere code execution, se superabile, è di natura tecnica: richiede engineering aggiuntivo non presente nel repository. L'attributo "sandbox" nella descrizione CVE è cruciale: l'esecuzione di codice arbitrario avviene dentro la sandbox renderer di Chrome. Per un compromesso reale servirebbe una seconda vulnerabilità, una sandbox escape, che al momento non risulta pubblica né indicizzata in Metasploit o Exploit-DB al 14 novembre 2026.

Non emergono evidenze di exploitation in-the-wild né inserimento nel CISA KEV. L'EPSS stima probabilità di exploitation dello 0,31-0,34% nei prossimi 30 giorni.

Cosa fare adesso

Chrome 157.0.8103.78 (Linux) e 157.0.8103.78/.79 (Windows/Mac) corregge la vulnerabilità. Gli utenti devono verificare di aver aggiornato il browser alla versione patched.

Le applicazioni Electron — inclusi Slack, Visual Studio Code e altri programmi che incorporano V8 — gestiscono release indipendenti con propri cicli di patching. Secondo Homeland411, la correzione di Chrome non si propaga automaticamente a queste applicazioni; gli utenti devono attendere aggiornamenti specifici dai rispettivi sviluppatori.

Analisi editoriale: la regressione come materiale di ricostruzione

La seguente sezione contiene analisi editoriale basata sui fatti verificati.

Il caso CVE-2026-126910 illustra una tensione strutturale nella pubblicazione di patch open source. I regression test, necessari per la qualità del software, contengono per definizione input che innescano il bug corretto. Quando il bug report è chiuso al pubblico, come nel caso del Chromium issue 574059463, questi test diventano la sola fonte tecnica accessibile per ricostruire la vulnerabilità.

Il pattern di Abraxas Labs — sette repository in una sola sessione — suggerisce operazione sistematica di raccolta e rielaborazione dei test ufficiali. La fonte non specifica le intenzioni dell'account. L'analisi del repository si basa esclusivamente su Homeland411; non abbiamo verificato indipendentemente il codice.

Il PoC incompleto non costituisce exploit funzionante, ma dimostra che la condizione di bug è riproducibile. Per il lettore tecnico, la distinzione è rilevante: tra descrizione CVE (RCE teorico nella sandbox), capacità del PoC (trigger della condizione, nessuna code execution), e scenario realistico (richiede secondo bug per sandbox escape).

Fonti

Fonti e riferimenti

Ricevi DeafLetter