Google e Mozilla hanno rilasciato Chrome 154 e Firefox 157 il 30 settembre 2026, correndo ai ripari su oltre cento falle combinate che abilitano esecuzione remota di codice, evasione dalla sandbox e escalation di privilegi. La finestra per il patching proattivo resta stretta: benché nessuno dei due vendor segnali exploitation attiva al momento della pubblicazione, la storia recente mostra che i difetti dei browser vengono rapidamente weaponizzati dopo la disclosure.
- Chrome 154 risolve 32 difetti: un solo critico (CVE-2026-102331, buffer overflow in ANGLE), 25 di gravità alta e il resto distribuito su severità inferiori; 15 segnalazioni provengono da ricercatori esterni.
- Firefox 157 corregge circa 76 vulnerabilità, di cui 38 di gravità alta: la maggioranza sono use-after-free e bug di evasione dalla sandbox, con anomalie di compilazione JIT e memoria non inizializzata.
- La classificazione della severità è asimmetrica: Google distingue critico/alto/medio/basso, mentre Mozilla concentra quasi la metà del totale nella sola fascia alta, rendendo più difficile il confronto inter-vendor per i team di risk management.
- I fix di Firefox sono stati retroportati sulle versioni ESR 153.4, 140.17 e 115.42; nessun vendor riporta exploitation attiva in-the-wild al momento del rilascio.
Chrome 154: un solo critico, ma ANGLE e V8 restano bersagli appetibili
La versione 154.0.8037.92/.93 per Windows e macOS — e .92 per Linux — di Google corregge 32 difetti di sicurezza, secondo SecurityWeek. Un solo bug è classificato critico: CVE-2026-102331, un buffer overflow nel motore grafico ANGLE (Almost Native Graphics Layer Engine), con CVSS 9.6 assegnato nel record NVD [CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H]. Il vettore di attacco è remoto, non richiede privilegi, ma dipende dall'interazione utente; la scope changed indica che il compromesso supera il singolo componente.
I restanti 25 difetti di gravità alta sono principalmente use-after-free e vulnerabilità su risorse non inizializzate. Cinque di questi — tutti nella stessa fascia alta — riguardano type confusion nel motore V8 JavaScript/WebAssembly: un componente che da anni rappresenta uno dei surface di attacco più produttivi per exploit chained. La distribuzione geografica delle segnalazioni è parziale: 15 dei 32 bug provengono da ricercatori esterni, ma Google ha reso pubblico l'importo del bounty solo per un difetto di gravità bassa nel modulo Payments (1.000 dollari); i 14 premi rimanenti non sono documentati, lasciando ignota la severità effettiva delle falle più redditizie.
Firefox 157: la mole dei fix nasconde una tassonomia meno granulare
Mozilla ha distribuito Firefox 157 lo stesso 30 settembre con circa 76 vulnerabilità corrette — un numero che SecurityWeek, Offseq Radar e CloudLinkTech convergono nel descrivere con qualificatori approssimativi ("approximately", "about"). La metà esatta, 38, è classificata alta gravità: la maggioranza sono use-after-free e sandbox escape, con un'aggiunta di boundary condition errate, memoria non inizializzata, escalation di privilegi, information disclosure, puntatori invalidi e JIT miscompilation.
La scelta di Mozilla di concentrare quasi il 50% del totale nella sola categoria "high" rende opaca la gerarchia del rischio. Google, con il suo unico critico e la distribuzione più sfaccettata, offre ai team di sicurezza una mappa più leggibile per la prioritizzazione. Mozilla invece non utilizza la label "critical" nel modo che la concorrenza impiega: il risultato è che un bug di sandbox escape — potenzialmente catastrofico per l'isolamento del processo — finisce nella stessa bucket di un information disclosure locale. Per gli enterprise che standardizzano su Firefox ESR, questa asimmetria complica il dialogo tra security operations e vendor management.
I fix sono stati retroportati su tre rami ESR: 153.4, 140.17 e 115.42. La copertura estesa all'ESR 115.42 — un ramo ormai consolidato per deployment aziendali conservativi — indica che alcune delle falle corrette erano presenti in codebase più datate e che Mozilla mantiene ancora commitment di backporting su versioni che altri vendor avrebbero già dichiarato end-of-life.
La memoria unsafe domina, la sandbox è il moltiplicatore di impatto
"Google and Mozilla make no mention of any of these security defects being exploited in the wild, but users are advised to update their browsers as soon as possible." — SecurityWeek
La classe prevalente di vulnerabilità resta la memory safety: use-after-free, buffer overflow, memoria non inizializzata. Questi difetti dominano sia Chrome che Firefox, confermando che — nonostante decenni di hardening e l'adozione di linguaggi memory-safe in componenti periferici — i motori di rendering e i compilatori JIT restano scritti in C/C++ per ragioni di performance. Il costo è un attack surface ricorrente e ben compreso dagli exploit developer.
Il elemento che eleva il rischio da "browser compromise" a "sistema compromesso" è la sandbox escape. I difetti di isolamento processo — presenti in entrambi i vendor, ma più numerosi nel bollettino Firefox — permettono a codice eseguito nel contesto del renderer di superare i confini della sandbox e operare con privilegi di sistema. In un browser enterprise, dove l'utente può accedere a risorse interne via web application, la combinazione RCE + sandbox escape equivale a un pivot point per movimento laterale nella rete aziendale.
La JIT miscompilation segnalata in Firefox aggiunge un vettore meno documentato: errori nel compilatore just-in-time che generano codice macchina semanticamente errato, potenzialmente bypassando controlli di tipo o boundary check che il source language garantirebbe. Questa categoria è storicamente sottostimata nei conteggi di superficie d'attacco, ma ha già prodotto exploit functional in passato.
Cosa fare adesso
- Verificare la distribuzione dei build 154.0.8037.xx e 157.x su tutti i desktop managed: gli auto-update dei browser possono essere ritardati da policy GPO (Chrome) o preferenze enterprise (Firefox) che i team IT devono esplicitamente forzare o sbloccare.
- Auditare i rami ESR Firefox in produzione: se l'organizzazione standardizza su ESR 115.x o 140.x, confermare che il punto release di backporting (115.42, 140.17) sia effettivamente rolloutato nei canali di update interni, non solo disponibile sul server Mozilla.
- Ricalibrare le soglie di severità nei runbook di prioritizzazione: la discrepanza tra la tassonomia Google (critico/alto/medio/basso) e quella Mozilla (alta concentrazione in "high") richiede che i team non applichino criteri uniformi cross-vendor, ma leggano il componente affetto e la presenza di sandbox escape come moltiplicatori indipendenti dalla label.
- Monitorare i threat intelligence feed per indicatori post-disclosure: benché nessuna exploitation sia confermata al momento della pubblicazione, i browser rappresentano target commoditizzati; la presenza di proof-of-concept pubblici per falle V8 o ANGLE tipicamente si manifesta entro 7-14 giorni dalla release.
La trasparenza della severità come variabile di rischio enterprise
L'headline "oltre 100 vulnerabilità" serve al traffico web, ma offusca una dinamica più rilevante per chi gestisce il rischio. Google, con il suo unico critico esplicito e la granularità per componente (ANGLE, V8, Payments), consente una prioritizzazione chirurgica. Mozilla, aggregando la metà dei propri difetti in una categoria alta indifferenziata, costringe a una lettura tecnica più approfondita — o a una gestione del rischio più conservativa, che tratta ogni "high" come potenzialmente critico.
Per le organizzazioni con deployment eterogenei, la lezione non è nel numero totale, ma nella non-interoperabilità delle scale di severità. Un vendor che non distingue critico da alto nel modo che il proprio framework di risk management presuppone introduce rumore nella pipeline di vulnerability management. Il patching rimane l'unica mitigazione documentata; tutto il resto — segmentazione, isolamento, monitoring comportamentale — non è menzionato nei bollettini come alternativa valida.
Domande frequenti
- Perché Firefox corregge più del doppio delle falle di Chrome?
- Il dato non implica necessariamente maggiore fragilità del codebase: Mozilla e Google usano cicli di rilascio, processi di disclosure interni e definizioni di "vulnerabilità di sicurezza" potenzialmente diversi. Chrome potrebbe consolidare più fix in un singolo CVE o differire la pubblicazione. Il dossier non documenta metodologie di conteggio comparabili.
- Il CVSS 9.6 di CVE-2026-102331 significa che è già sfruttabile da remoto senza interazione?
- No: il vettore CVSS:3.1/AV:N/AC:L/PR:N/UI:R specifica che è richiesta l'interazione utente (UI:R), tipicamente la visita a una pagina malevola o l'esecuzione di contenuto compromesso. La complessità dell'attacco è bassa (AC:L), ma non è completamente automatico.
- Perché alcuni bounty Chrome non sono stati resi pubblici?
- Google ha divulgato solo il premio per un bug di gravità bassa nel modulo Payments. Le motivazioni per la non-disclosure dei 14 restanti — importo, severità, richiesta del ricercatore — non sono specificate nelle fonti. Questa opacità è comune nei programmi di vulnerability reward, ma impedisce di correlare bounty massicci con gravità effettiva.
Fonti
- https://www.securityweek.com/chrome-firefox-updates-patch-over-100-vulnerabilities/
- https://radar.offseq.com/threat/chrome-firefox-updates-patch-over-100-vulnerabilities-2eaa63c1c6dbc366
- https://www.cloudlinktech.com/news/chrome-firefox-patch-100-security-flaws/
- https://www.rescana.com/post/chrome-150-and-firefox-152-patch-critical-vulnerabilities-cve-analysis-and-enterprise-risk-advisory
- https://www.itsecuritynews.info/chrome-firefox-updates-patch-over-100-vulnerabilities/
- https://podcast.securityweek.com/