Firefox, una sola lettera nel codice apre la strada a un bug critico

Un refuso di una sola lettera nel codice di Firefox poteva aprire la strada a un bug di memoria con rischio esecuzione di codice. La vulnerabilità è stata individuata e corretta rapidamente da Mozilla e non ha mai raggiunto le versioni stabili del browser.

A febbraio 2026 è emerso un caso didatticamente “perfetto” di vulnerabilità da runtime moderno: una svista minuscola, introdotta durante un refactoring legittimo, che apre la strada a una catena di corruzione di memoria fino all’esecuzione di codice nel processo di rendering del browser. Il problema riguarda Firefox e, in particolare, il componente WebAssembly Garbage Collection (Wasm GC) di SpiderMonkey.

L’errore interessa di fatto una sola lettera nel codice. Tuttavia, quel refuso “critico” ha fatto sì che, in certe condizioni, Firefox potesse continuare a usare un pezzo di memoria vecchio e già spostato, aprendo la strada a un grave problema di sicurezza.

Il “refuso” che ha causato un grave problema in Firefox

In un punto del codice, Firefox doveva salvare un “segnalino” che dice: “questo buffer è stato spostato, e qui c’è l’indirizzo nuovo”. Per farlo, usa una tecnica comune: prende un puntatore e imposta un bit (una sorta di etichetta).

Il problema? Invece di usare l’operatore giusto, gli sviluppatori del browser Mozilla hanno digitato quello sbagliato. Risultato pratico: invece di salvare un riferimento valido, il sistema salvava zero, cioè un valore che confondeva completamente i controlli successivi.

Firefox ha un Garbage Collector (GC) che sposta oggetti in memoria per ottimizzare e ripulire. Quando qualcosa si sposta, chi lo stava usando deve essere “aggiornato” al nuovo indirizzo.

Con questo bug, in alcuni casi Firefox “pensava” che l’oggetto non fosse stato spostato, quindi non aggiornava i riferimenti e continuava a usare il vecchio indirizzo, ma quel vecchio spazio poteva essere già libero e riutilizzato. È un problema di gestione della memoria e il classico punto di partenza per bug seri che portano all’esecuzione di codice dannoso (RCE, Remote Code Execution).

Perché il bug si attivava solo in condizioni particolari

Come si evince nell’analisi del ricercatore che ha fatto emergere il problema di sicurezza, la vulnerabilità non era immediatamente visibile perché richiedeva una combinazione precisa di fattori interni a livello di motore SpiderMonkey.

Si manifestava solo quando codice WebAssembly veniva eseguito dal livello di esecuzione più veloce di Firefox, chiamato Ion, che lavora con riferimenti diretti agli oggetti in memoria e deve aggiornarli manualmente ogni volta che il Garbage Collector li sposta.

Era inoltre necessario che l’array WebAssembly fosse abbastanza grande da essere salvato in un’area di memoria separata e che il Garbage Collector intervenisse proprio mentre veniva utilizzato.

In quel momento, a causa del refuso, il sistema non segnalava correttamente lo spostamento dell’oggetto e continuava a usare il vecchio riferimento. Il problema diventava davvero concreto solo se quella porzione di memoria era subito riutilizzata per altro: in quel caso Firefox finiva per leggere o scrivere dati non più validi.

La parte importante: zero-day risolto in fretta e mai arrivato nelle versioni stabili

Una volta individuato il problema, il ricercatore lo ha comunicato a Mozilla attraverso il programma ufficiale di responsible disclosure, fornendo una descrizione tecnica e una dimostrazione del comportamento anomalo. Il team di sicurezza di Firefox ha preso in carico la segnalazione con priorità elevata, ha riprodotto il difetto e ha rapidamente individuato la causa nel refactoring recente del codice Wasm.

Nel giro di pochi giorni è stata preparata e integrata una patch correttiva, accompagnata da controlli aggiuntivi per evitare regressioni simili in futuro.

Proprio grazie alla rapidità del processo interno, la vulnerabilità non ha mai superato il canale di sviluppo Nightly e non è arrivata né alle versioni Beta né a quelle stabili distribuite agli utenti.

Il caso rappresenta un esempio concreto di collaborazione efficace tra ricerca indipendente e team di sicurezza: segnalazione tempestiva, verifica rapida, correzione mirata e distribuzione controllata. Mozilla ha poi assegnato, l’11 febbraio scorso, la ricompensa prevista dal programma bug bounty.

Ti consigliamo anche

Link copiato negli appunti