Due falle critiche di Wasmtime richiedono la ricompilazione delle applicazioni che lo incorporano
Due falle critiche di Wasmtime potrebbero consentire a un modulo WebAssembly controllato da un aggressore di eludere le restrizioni predisposte per contenerlo. Wasmtime è un runtime, cioè un software che esegue codice WebAssembly al di fuori di un web browser, e può anche essere incorporato come libreria in altre applicazioni. La Bytecode Alliance, che gestisce il progetto, ha assegnato a entrambe le vulnerabilità un punteggio di 9,9 su 10 secondo il Common Vulnerability Scoring System (CVSS), una misura standard della gravità dei problemi di sicurezza. Le versioni corrette sono state pubblicate il 19 e 20 ottobre e i manutentori non hanno segnalato alcun attacco.
Le vulnerabilità si trovano in Cranelift, il compiler predefinito di Wasmtime per convertire i moduli WebAssembly in istruzioni eseguibili da un processore. CVE-2026-115889 interessa Wasmtime su ogni architettura di processore, mentre CVE-2026-115893 è limitata ad ARM64, nota anche come aarch64. Lo sfruttamento richiede che una build vulnerabile di Wasmtime compili un modulo controllato dall'aggressore. Ciò rende i servizi che accettano e compilano moduli forniti da altre persone gli ambienti maggiormente a rischio. Fastly, per esempio, afferma che la sua piattaforma Compute utilizza Wasmtime per eseguire il codice dei clienti, anche se gli avvisi non identificano servizi interessati né specificano quali risorse potrebbe raggiungere un aggressore dopo un escape.
Una sandbox di Wasmtime è progettata per limitare un modulo alla memoria assegnata e alle host functions, ossia le funzionalità approvate, fornite dall'applicazione. Limita inoltre l'esecuzione del codice a destinazioni verificate. Le due falle compromettono questi confini durante la compilazione. Al 26 ottobre, nessuna delle due vulnerabilità figurava nel catalogo Known Exploited Vulnerabilities gestito dalla Cybersecurity and Infrastructure Security Agency (CISA) degli Stati Uniti.
Le versioni interessate differiscono tra le due falle. Le versioni precedenti alla 36.0.19, compresa la linea 24.x, sono vulnerabili a entrambi i problemi su ARM64 e a CVE-2026-115889 sulle altre architetture. La versione 36.0.19 corregge entrambi i problemi. Le versioni dalla 37.0.0 alla 42.x sono interessate da entrambe le vulnerabilità nei sistemi ARM64. Le versioni dalla 43.0.0 alla 47.x non sono interessate da CVE-2026-115889, ma rimangono vulnerabili alla falla specifica per ARM64. Anche le versioni dalla 48.0.0 alla 48.0.6 e dalla 49.0.0 alla 49.0.3 sono interessate da CVE-2026-115893. Le versioni corrette sono 36.0.19, 48.0.7, 49.0.4 e 50.0.0 o successive.
Wasmtime classifica le versioni il cui numero è un multiplo di 12 come versioni long-term support (LTS) e le supporta per due anni. Le altre versioni ricevono due mesi di supporto, mentre le correzioni di sicurezza sono garantite soltanto per le linee ancora supportate. Al momento degli avvisi, rimanevano supportate soltanto le linee 36, 48, 49 e 50. Le altre linee non hanno ricevuto correzioni, compreso il branch 24.x LTS, il cui supporto è terminato il 20 agosto 2026. I sistemi ARM64 aggiornati ad aprile alle versioni 36.0.7, 42.0.2 o 43.0.1 per correggere un precedente escape da Cranelift sono ancora vulnerabili a CVE-2026-115893.
Gli amministratori dovrebbero passare alla versione 36.0.19, 48.0.7, 49.0.4 o 50.0.0, a seconda della linea utilizzata. Le installazioni non supportate devono migrare a uno di questi branch corretti. Aggiornare soltanto il programma a command-line di Wasmtime non è sufficiente quando un'applicazione contiene Wasmtime come libreria. Ogni applicazione interessata deve essere ricompilata utilizzando una versione corretta. Nessuno dei due avvisi fornisce un workaround, pertanto qualsiasi modulo fornito da una parte esterna rimane una potenziale fonte di rischio finché il relativo software host non viene aggiornato e ricompilato.
CVE-2026-115889 deriva dal modo in cui le versioni precedenti di Cranelift registravano gli identificatori utilizzati per tenere traccia dei valori all'interno di una funzione. Prima della versione 43, questi identificatori occupavano campi a 24 bit. Nelle build di release, un identificatore troppo grande per quel campo poteva causare un overflow senza produrre alcun errore. Di conseguenza, Cranelift poteva fare riferimento al valore sbagliato e generare codice macchina errato. Secondo l'avviso, una funzione WebAssembly molto grande, oppure costruita intenzionalmente per creare numerosi valori, poteva provocare type confusion e consentire un sandbox escape.
La principale linea di sviluppo di Wasmtime aveva già eliminato questa condizione prima che ne venissero documentate le implicazioni per la sicurezza. Una modifica sottoposta a merge il 18 febbraio ha ampliato i campi interessati a 32 bit ed è stata inclusa in Wasmtime 43.0.0 il 20 marzo. All'epoca, la modifica era stata descritta come supporto per la compilazione di funzioni più grandi, senza alcun riferimento alla sicurezza. Il branch 36.x LTS ha ricevuto la stessa modifica il 19 ottobre. L'avviso non specifica quando i manutentori abbiano riconosciuto l'impatto sulla sicurezza.
CVE-2026-115893 riguarda br_table, un'istruzione WebAssembly che seleziona una tra numerose destinazioni del codice in base a un indice e utilizza una destinazione predefinita quando l'indice è esterno alla tabella. Su ARM64, Cranelift gestiva un indice fuori intervallo con un branch che poteva raggiungere soltanto una distanza di circa 1 MiB. Una br_table contenente più di circa 256.000 destinazioni poteva diventare troppo grande per tale portata, facendo sì che il branch puntasse silenziosamente alla posizione sbagliata. I manutentori affermano che un modulo controllato dall'utente potrebbe sfruttare questa condizione per indurre un engine Wasmtime predefinito su ARM64 a saltare a codice arbitrario. La falla esisteva dall'introduzione del supporto per ARM64 nel 2020. La correzione instrada gli indici fuori intervallo attraverso la jump table stessa e rifiuta una br_table con più di 65.520 destinazioni.
Entrambe le vulnerabilità sono registrate in RustSec, il database di sicurezza utilizzato da cargo-audit per esaminare i file delle dipendenze Cargo.lock, con gli identificatori RUSTSEC-2026-0380 e RUSTSEC-2026-0379. Al 26 ottobre, il database degli avvisi di GitHub aveva verificato CVE-2026-115889, ma non disponeva di una voce verificata per CVE-2026-115893. Poiché GitHub afferma che le notifiche Dependabot richiedono una voce verificata, in quel momento gli utenti non avrebbero dovuto aspettarsi una notifica relativa alla falla ARM64. Spin, uno strumento open source per applicazioni WebAssembly serverless, ha adottato Wasmtime 50.0.0 nella versione 4.2.4 il 21 ottobre.
Gli operatori di siti web e applicazioni cloud dovrebbero quindi controllare sia le installazioni dirette di Wasmtime sia il software che incorpora il runtime, prestando particolare attenzione agli host ARM64 e alle linee di versioni non supportate. Per le organizzazioni che necessitano di assistenza nella verifica del proprio ambiente tecnologico, AEU-I offre servizi IT, infrastrutturali e di consulenza incentrati sulla sicurezza. La misura correttiva essenziale rimane l'installazione di una versione corretta di Wasmtime e la ricompilazione di ogni applicazione che include la libreria vulnerabile.