Wasmtime, due sandbox escape critiche e SQL injection in AWS Redshift

🛡️ Executive Summary

• Bytecode Alliance corregge CVE-2026-115889 e CVE-2026-115893, due vulnerabilità critiche CVSS 9,9 che possono consentire a moduli WebAssembly malevoli di uscire dalla sandbox di Wasmtime.
• Le patch sono disponibili nelle versioni Wasmtime 36.0.19, 48.0.7, 49.0.4 e 50.0.0. Le applicazioni che incorporano il runtime devono essere ricompilate e le release non più supportate devono essere sostituite.
• AWS corregge CVE-2026-115418, una SQL injection nel modulo sperimentale CDK per Amazon Redshift che può eseguire istruzioni con privilegi superuser e concedere accessi non previsti agli utenti del cluster.

Due vulnerabilità critiche in Wasmtime possono permettere a codice WebAssembly malevolo di superare i confini della sandbox, mentre Amazon Web Services corregge una SQL injection nel proprio Cloud Development Kit capace di alterare le autorizzazioni di Amazon Redshift. Le falle CVE-2026-115889 e CVE-2026-115893, entrambe classificate con punteggio CVSS 9,9, interessano il compilatore Cranelift utilizzato dal runtime sviluppato dalla Bytecode Alliance. Il bollettino 2026-151-AWS, pubblicato il 26 ottobre 2026, riguarda invece CVE-2026-115418, vulnerabilità nel modulo sperimentale @aws-cdk/aws-redshift-alpha. Gli incidenti non risultano collegati e non sono accompagnati da segnalazioni pubbliche di sfruttamento attivo. Evidenziano tuttavia un problema comune: componenti progettati per eseguire operazioni controllate possono trasformarsi in punti di escalation quando vengono meno le garanzie sul codice compilato o sui parametri utilizzati per costruire istruzioni privilegiate.

Wasmtime permette a moduli WebAssembly di uscire dalla sandbox

Le due vulnerabilità pubblicate negli advisory della Bytecode Alliance il 19 ottobre interessano Wasmtime, runtime open source progettato per eseguire applicazioni WebAssembly al di fuori del browser. Il software viene utilizzato in ambienti cloud, piattaforme serverless e applicazioni che devono eseguire moduli sviluppati da terzi mantenendoli isolati dal processo ospitante. L’architettura prevede che il codice WebAssembly possa accedere soltanto alla propria memoria e alle funzioni esplicitamente autorizzate dall’host. Il compilatore Cranelift traduce le istruzioni WebAssembly in codice macchina, rispettando i vincoli che dovrebbero impedire a un modulo di raggiungere memoria o istruzioni esterne al proprio ambiente. Le vulnerabilità individuate compromettono proprio questa garanzia, introducendo condizioni nelle quali il codice generato non corrisponde al comportamento che il runtime dovrebbe consentire.

CVE-2026-115889 interessa tutte le architetture supportate dal compilatore predefinito e deriva da un errore nella rappresentazione degli indici SSA, utilizzati da Cranelift per identificare i valori intermedi durante la compilazione. Prima della versione 43, questi identificativi venivano conservati in campi da 24 bit, insufficienti quando una funzione WebAssembly particolarmente grande generava un numero elevato di valori. Nelle build di produzione, il superamento della capacità disponibile poteva produrre un overflow silenzioso e indurre il compilatore a utilizzare riferimenti errati. La descrizione ufficiale GHSA-897f-g5gm-fmxm conferma che un modulo appositamente costruito può provocare type confusion, compilazione scorretta ed evasione dalla sandbox. La correzione utilizza identificativi a 32 bit e introduce controlli sui limiti, eliminando la condizione che rendeva possibile il riferimento a valori differenti da quelli previsti.

Il risultato richiama, pur con un meccanismo differente, le vulnerabilità della sandbox vm2 per Node.js che consentivano di raggiungere il processo ospitante. In entrambi i casi l’isolamento viene compromesso da comportamenti inattesi del software che interpreta o esegue il codice non attendibile. Il rischio non riguarda automaticamente qualsiasi programma WebAssembly, ma soprattutto i sistemi che utilizzano versioni vulnerabili di Wasmtime per compilare ed eseguire moduli controllati da utenti esterni.

CVE-2026-115893 colpisce ARM64 e sfrutta un errore nei salti condizionali

La seconda vulnerabilità, CVE-2026-115893, presenta caratteristiche differenti e riguarda esclusivamente i sistemi ARM64, identificati come aarch64. L’errore si trova nella compilazione dell’istruzione WebAssembly br_table, utilizzata per selezionare una destinazione di salto tra molteplici possibilità. Quando l’indice richiesto non corrisponde a una voce della tabella, l’esecuzione deve raggiungere una destinazione predefinita. Nella traduzione realizzata da Cranelift per ARM64, questo comportamento poteva dipendere da un’istruzione di salto con una portata limitata a circa 1 MiB. Un modulo contenente più di 256.000 destinazioni poteva superare tale limite, determinando la generazione di un salto verso una posizione differente da quella prevista.

Secondo l’advisory GHSA-mghf-wjfp-p5xm pubblicato dai manutentori, un attaccante capace di fornire un modulo WebAssembly controllato può utilizzare questa condizione per deviare l’esecuzione verso codice arbitrario all’interno del processo ospitante, superando le restrizioni della sandbox. Il problema è presente nelle implementazioni ARM64 di Cranelift sin dall’introduzione del supporto per questa architettura nel 2020. La patch modifica il percorso utilizzato per gestire gli indici fuori intervallo e impedisce la compilazione di tabelle con più di 65.520 destinazioni, evitando che l’istruzione generata raggiunga dimensioni incompatibili con il salto previsto.

La distinzione tra le due vulnerabilità è operativamente importante. CVE-2026-115889 può interessare anche sistemi x86-64, mentre CVE-2026-115893 riguarda soltanto host ARM64. Le piattaforme che utilizzano processori ARM per eseguire workload serverless devono quindi considerare entrambe le condizioni, anche quando hanno già installato precedenti correzioni Cranelift. La Bytecode Alliance precisa che gli aggiornamenti distribuiti ad aprile 2026 per una precedente sandbox escape su ARM64 non eliminavano il nuovo problema. Non risultano attacchi attivi confermati contro queste due CVE e, al 26 ottobre, nessuna delle due figurava nel catalogo CISA delle vulnerabilità sfruttate note.

Leggi anche: APT31 sfrutta il patch gap di Chrome e concatena tre zero-day per uscire dalla sandbox Windows

Wasmtime richiede aggiornamento e ricompilazione dei programmi che lo incorporano

Le patch sono state distribuite tra il 19 e il 20 ottobre 2026, ma la gestione degli aggiornamenti richiede attenzione perché Wasmtime mantiene linee di rilascio differenti. La versione 36.0.19 corregge entrambe le vulnerabilità nella linea LTS, mentre 48.0.7, 49.0.4 e 50.0.0 contengono le protezioni necessarie nelle versioni più recenti. Le release dalla 43 alla 47 non presentano più il problema degli indici SSA, ma rimangono vulnerabili alla falla ARM64. I rami precedenti non più supportati, incluso Wasmtime 24.x, non hanno ricevuto aggiornamenti dedicati e devono essere sostituiti con una versione mantenuta.

La documentazione delle release della Bytecode Alliance conferma anche un aspetto spesso trascurato: aggiornare il solo eseguibile Wasmtime non protegge necessariamente le applicazioni che incorporano il runtime come libreria. Ogni software che utilizza una versione vulnerabile deve aggiornare la dipendenza, essere ricompilato e successivamente distribuito. Gli sviluppatori Rust possono individuare le dipendenze interessate attraverso cargo audit e l’analisi del file Cargo.lock, utilizzando gli identificativi RUSTSEC-2026-0380 e RUSTSEC-2026-0379. Il progetto Spin, destinato allo sviluppo di applicazioni serverless WebAssembly, ha già integrato Wasmtime 50.0.0 nella versione 4.2.4. Il rischio più elevato rimane nelle piattaforme multi-tenant che compilano moduli forniti dagli utenti, perché la compromissione dell’isolamento può consentire di raggiungere risorse esterne al contesto autorizzato al codice eseguito.

AWS corregge CVE-2026-115418: SQL injection con privilegi Redshift superuser

Il secondo intervento di sicurezza riguarda Amazon Web Services e una vulnerabilità distinta, identificata come CVE-2026-115418. Nel bollettino ufficiale AWS 2026-151, pubblicato il 26 ottobre, Amazon descrive una SQL injection nel modulo sperimentale @aws-cdk/aws-redshift-alpha, utilizzato dal Cloud Development Kit per definire e gestire utenti, tabelle e autorizzazioni dei cluster Amazon Redshift attraverso codice infrastrutturale. L’errore interessa i gestori delle risorse personalizzate che costruiscono interrogazioni SQL a partire dai valori dichiarati nei costrutti CDK. In determinate condizioni, nomi utente, commenti o password appositamente preparati possono alterare le istruzioni eseguite durante il deployment, trasformando una configurazione apparentemente legittima in una modifica non autorizzata del database.

La criticità deriva dal contesto di esecuzione: le istruzioni SQL vengono eseguite utilizzando le credenziali amministrative del cluster Redshift, permettendo a un attaccante che controlla i parametri di influenzare operazioni dotate di privilegi superuser. La conseguenza documentata da AWS comprende la possibilità di concedere autorizzazioni a tutti gli utenti del cluster attraverso grant non previsti. Non si tratta però di una vulnerabilità di Amazon Redshift sfruttabile indiscriminatamente attraverso una normale connessione al database. L’aggressore deve prima poter influenzare i valori utilizzati dall’applicazione CDK, ad esempio attraverso configurazioni o input non attendibili che vengono incorporati nelle proprietà dei costrutti. L’advisory GHSA-25hh-xvj4-2cqv pubblicato da AWS su GitHub assegna al problema un punteggio CVSS 7,3, con classificazione alta.

La vulnerabilità interessa il pacchetto nelle versioni precedenti a 2.274.0-alpha.0, sia nella distribuzione npm @aws-cdk/aws-redshift-alpha sia nel corrispondente pacchetto Python. AWS raccomanda di aggiornare il modulo e controllare successivamente le autorizzazioni già presenti nei database, con particolare attenzione ai grant verso PUBLIC. La patch impedisce nuovi abusi della generazione SQL, ma non revoca automaticamente privilegi che potrebbero essere stati assegnati attraverso deployment precedenti. L’intervento interessa quindi anche la verifica dello stato effettivo del cluster e non soltanto l’aggiornamento della dipendenza. Il problema si colloca nello stesso ambito infrastrutturale in cui AWS sta ampliando le capacità di Amazon Redshift e Apache Iceberg nella gestione dei dati condivisi, rendendo ancora più importante proteggere i livelli che amministrano identità e autorizzazioni.

Continua con: Amazon Redshift sotto attacco, linee guida SIEM/SOAR da CISA e nuove allerte ICS

La sicurezza del cloud dipende anche dai confini tra codice e privilegi

Le vulnerabilità Wasmtime e AWS CDK intervengono su componenti differenti, ma mostrano un problema architetturale comune. Wasmtime deve garantire che il codice eseguito dentro una sandbox non possa raggiungere risorse esterne, mentre AWS CDK deve impedire che valori utilizzati per descrivere un’infrastruttura alterino istruzioni SQL eseguite con privilegi elevati. Nel primo caso il confine viene compromesso da errori nella generazione del codice macchina; nel secondo da un trattamento insufficiente dei parametri inseriti nelle istruzioni amministrative. Entrambi dimostrano che un componente intermedio, spesso percepito come parte affidabile della piattaforma, può diventare un vettore di escalation anche quando il codice applicativo principale non contiene direttamente la vulnerabilità. Per le organizzazioni italiane che utilizzano WebAssembly in ambienti serverless o Amazon Redshift attraverso AWS CDK, la priorità consiste nel verificare le dipendenze effettivamente distribuite, ricompilare i programmi che incorporano Wasmtime, aggiornare il modulo Redshift e controllare i privilegi presenti sui cluster. Nessuna delle disclosure consultate documenta sfruttamenti attivi delle tre vulnerabilità, ma questo non riduce la necessità di intervenire sui sistemi esposti a codice o configurazioni controllabili da soggetti esterni. L’isolamento non può essere considerato una proprietà garantita una volta per tutte dalla scelta di un runtime o di un servizio cloud: deve essere verificato anche nei compilatori, nei componenti di deployment e nelle autorizzazioni che permettono al software di modificare risorse condivise.