BridgeBreak espone 20.000 dispositivi industriali, mentre i sandbox AI e npm diventano vettori di attacco

Le minacce emerse nell’aprile 2026 mostrano quanto sia fragile il confine tra infrastrutture legacy, sviluppo software moderno e strumenti AI. Le 22 vulnerabilità BridgeBreak colpiscono convertitori serial-to-IP usati in ambienti industriali e sanitari, mentre una falla critica in Terrarium di Cohere consente esecuzione di codice con privilegi root all’interno del sandbox. Nello stesso momento un attacco worm alla supply chain npm compromette pacchetti collegati a Namastex Labs, e AWS corregge un bypass della policy di key commitment nel suo Encryption SDK per Python. Il quadro che emerge è quello di una superficie d’attacco molto più ampia, dove i rischi non arrivano solo dal malware tradizionale ma anche da librerie, container, bridge di rete e meccanismi di fiducia incorporati nelle pipeline moderne.

BridgeBreak espone quasi 20.000 dispositivi seriali-IP in ambienti critici

La ricerca BridgeBreak porta alla luce 22 vulnerabilità in convertitori serial-to-IP prodotti da Lantronix e Silex, dispositivi usati per collegare sistemi seriali legacy a reti TCP/IP moderne. Si tratta di componenti poco visibili ma centrali in utility, manifattura, sanità, retail e trasporti, dove fungono da ponte tra apparecchiature datate e infrastrutture digitali contemporanee. I ricercatori descrivono quasi 20.000 dispositivi esposti online, un dato che aumenta enormemente la possibilità di targeting da parte degli attaccanti. Il problema non riguarda solo la presenza di falle isolate, ma il ruolo operativo di questi apparati, spesso inseriti direttamente nei percorsi di comunicazione tra operatori, sensori, attuatori e sistemi di controllo.

Le vulnerabilità BridgeBreak aprono la strada a takeover e manomissione dei dati

Le debolezze identificate coprono scenari molto diversi: esecuzione di codice remoto, client-side code execution, denial-of-service, bypass di autenticazione, takeover del dispositivo, tampering del firmware, tampering della configurazione, information disclosure e upload arbitrario di file. In pratica, un aggressore può interrompere comunicazioni seriali con asset di campo, manipolare dati in transito, alterare letture di sensori e perfino influenzare il comportamento di attuatori. In un contesto OT o sanitario il rischio non è solo informatico ma operativo, perché valori falsati o comunicazioni interrotte possono compromettere decisioni umane e processi fisici. Il convertitore seriale, da semplice ponte tecnico, diventa così un punto di accesso ad alto impatto per movimenti laterali e sabotaggio.

Lantronix e Silex rilasciano patch ma resta essenziale la segmentazione

I vendor coinvolti hanno pubblicato aggiornamenti di sicurezza, ma la semplice disponibilità delle patch non elimina il rischio se i dispositivi restano esposti su internet o protetti con credenziali deboli. In questi scenari la mitigazione più efficace parte dalla rimozione dell’esposizione pubblica, dalla segmentazione delle reti e dal controllo stretto delle interfacce di management. È altrettanto importante sostituire le credenziali predefinite, applicare password robuste e monitorare il traffico est-ovest per individuare attività anomale. In ambienti mission-critical il problema dei bridge seriali conferma una lezione nota ma spesso ignorata: gli apparati legacy “adattati” al mondo IP non sono neutri, ma introducono una nuova classe di rischio infrastrutturale.

Terrarium di Cohere perde il sandbox e permette esecuzione come root

Sul fronte AI security, la vulnerabilità CVE-2026-5752 colpisce Terrarium, sandbox Python open source sviluppato da Cohere per eseguire codice non attendibile inviato dagli utenti o generato da LLM. Il problema deriva da una traversata della catena dei prototipi JavaScript nell’ambiente Pyodide WebAssembly, che consente al codice isolato di raggiungere oggetti globali dell’host Node.js e ottenere accesso a primitive sensibili come require(). Da lì l’attaccante può eseguire comandi arbitrari con privilegi root nel container. È una falla particolarmente seria perché colpisce proprio uno strumento progettato per validare o confinare codice potenzialmente pericoloso, trasformando il sandbox nel vettore stesso della compromissione.

L’assenza di patch per Terrarium alza il rischio nelle pipeline AI

Il problema di Terrarium è aggravato dal fatto che il progetto non risulta più attivamente mantenuto e non ha ricevuto una patch ufficiale. Questo lascia le organizzazioni che lo usano in una posizione delicata, soprattutto se il sandbox viene impiegato per eseguire codice prodotto da agenti AI, workflow autonomi o utenti esterni. In questi casi il breakout dal container può portare non solo alla lettura di file sensibili come /etc/passwd o variabili d’ambiente, ma anche al raggiungimento di database e API interni collegati alla rete del container. In assenza di fix, le contromisure diventano obbligatorie: disabilitare dove possibile l’esecuzione di codice utente, segmentare la rete, limitare gli accessi, usare strumenti di orchestrazione più sicuri e monitorare i container per comportamenti anomali.

Il caso Terrarium mostra i limiti reali dei sandbox per codice generato da LLM

La criticità di Terrarium non è solo tecnica ma anche strategica. Sempre più organizzazioni stanno introducendo ambienti di esecuzione per codice generato o corretto da modelli linguistici, spesso ritenendo che il confinamento in container o runtime browser-based basti a neutralizzare i rischi. La falla dimostra il contrario. Quando il sandbox dipende da catene di prototipi, oggetti globali o bridge tra linguaggi e runtime differenti, un singolo difetto nella separazione logica può annullare l’intero modello di sicurezza. In pratica, il problema non riguarda solo Cohere ma tutto il settore dei tool che promettono esecuzione sicura del codice generato dall’AI senza una vera hardening strutturale dei confini tra guest e host.

L’attacco ai pacchetti npm di Namastex trasforma un installer in un worm

Parallelamente emerge un nuovo attacco alla supply chain npm che colpisce pacchetti collegati a Namastex Labs e replica molte delle tecniche già viste nel filone CanisterWorm. Le versioni compromesse di pacchetti come @automagik/genie, pgserve, @fairwords/websocket, @fairwords/loopback-connector-es, @openwebconcept/theme-owc e @openwebconcept/design-tokens eseguono codice malevolo in fase di installazione attraverso hook postinstall. Il payload non si limita a sottrarre segreti dall’ambiente locale, ma tenta anche di propagarsi verso altri pacchetti pubblicabili dalla vittima. Questo rende l’attacco molto più pericoloso di un classico stealer: una singola workstation compromessa può diventare il punto di partenza per una contaminazione ricorsiva di altri namespace e pipeline.

Il malware npm ruba segreti cloud SSH CI/CD e perfino wallet

Il comportamento del payload è estremamente aggressivo. Il codice cerca token, chiavi API, credenziali cloud, chiavi SSH, file .npmrc, .git-credentials, .netrc, configurazioni Kubernetes, Docker, Terraform, Pulumi, Vault, file .env, cronologie delle shell e altri asset sensibili tipici di workstation di sviluppo e ambienti CI/CD. In alcuni casi tenta anche l’accesso a dati di browser e wallet come MetaMask, Phantom, Exodus e Atomic Wallet. I dati vengono esfiltrati tramite endpoint HTTPS e infrastruttura Internet Computer Protocol, con cifratura ibrida quando disponibile una chiave pubblica incorporata. L’obiettivo è chiaro: trasformare l’ambiente di sviluppo in una miniera di credenziali ad alto valore, da riutilizzare per ulteriori compromissioni.

La propagazione verso npm e PyPI alza il livello della supply chain compromise

L’elemento più preoccupante è la logica di propagazione automatica. Se il malware trova token di pubblicazione npm nell’ambiente o nei file di configurazione locali, individua i pacchetti che l’utente può pubblicare, scarica i tarball, inietta un nuovo postinstall malevolo e ripubblica versioni compromesse. In parallelo include anche logiche orientate a PyPI tramite file .pth pensati per eseguire codice all’avvio di Python. Questo significa che l’attacco non resta confinato a una sola supply chain ma prova a muoversi tra ecosistemi differenti. Per i team di sicurezza la risposta deve essere immediata: rimuovere le versioni compromesse, ruotare tutti i segreti potenzialmente esposti, verificare mirror interni, artifact cache e cronologia delle pubblicazioni.

AWS corregge un bypass crittografico nell’Encryption SDK per Python

Meno appariscente ma comunque rilevante è la vulnerabilità CVE-2026-6550 nell’AWS Encryption SDK per Python. Il problema interessa il layer di caching delle chiavi e permette a un attore locale autenticato di bypassare la policy di key commitment attraverso una cache condivisa, causando un downgrade algoritmico. Il risultato è che uno stesso ciphertext può diventare decifrabile in più plaintext distinti, compromettendo l’integrità del modello di crittografia client-side. Le versioni interessate includono i rami 2.0–2.5.1, 3.0–3.3.0 e 4.0–4.0.4, mentre le correzioni arrivano con 3.3.1 e 4.0.5. In questo caso non si parla di RCE o worm, ma di una rottura delle garanzie crittografiche attese da chi usa l’SDK per proteggere dati sensibili.

La cache condivisa dimostra che anche la crittografia applicativa può fallire

La lezione del caso AWS è importante perché mostra come anche una libreria progettata per offrire garanzie forti possa essere indebolita da scelte implementative apparentemente secondarie come la gestione della cache. Se più istanze dell’SDK con policy diverse condividono lo stesso key cache, la separazione prevista dal modello di sicurezza non è più affidabile. Per questo l’aggiornamento è indispensabile e, come mitigazione temporanea, AWS raccomanda di non condividere la cache tra istanze configurate con politiche di key commitment differenti. In ambienti cloud e applicazioni Python che trattano dati regolamentati o informazioni sensibili, questo tipo di difetto impone una revisione immediata delle dipendenze e delle configurazioni operative.

BridgeBreak Terrarium npm e AWS descrivono un problema unico di fiducia

Sebbene i quattro casi appartengano a contesti diversi, tutti raccontano la stessa fragilità di fondo: la fiducia implicita in componenti considerati di supporto. I convertitori serial-to-IP vengono spesso trattati come semplici adattatori, i sandbox per codice AI come contenitori sicuri per definizione, i pacchetti npm come blocchi riutilizzabili e le librerie crittografiche come primitive affidabili per default. In realtà, proprio questi livelli intermedi diventano i punti ideali per attacchi con impatto elevato. Un bridge vulnerabile altera processi fisici, un sandbox rotto spalanca il container, una dipendenza malevola infetta la pipeline e una cache condivisa rompe il commitment della cifratura. La sicurezza moderna non può più limitarsi al perimetro tradizionale.

Le priorità operative per le aziende sono patch visibilità e rotazione dei segreti

Per le organizzazioni enterprise il messaggio è molto concreto. Nei contesti OT occorre identificare subito i convertitori Lantronix e Silex, applicare le patch e rimuovere ogni esposizione internet non necessaria. Nei flussi AI bisogna rivalutare l’uso di Terrarium e di sandbox simili per codice generato da LLM, soprattutto se non più mantenuti. Nelle pipeline di sviluppo è essenziale bloccare le versioni compromesse dei pacchetti npm, analizzare i sistemi che le hanno installate e ruotare segreti, token e chiavi potenzialmente esfiltrati. Infine, chi usa l’AWS Encryption SDK per Python deve aggiornare immediatamente le versioni vulnerabili e verificare le modalità di condivisione della cache delle chiavi. In sintesi, aprile 2026 conferma che il vero rischio non è una singola vulnerabilità, ma la convergenza tra AI, legacy, supply chain e cloud in un’unica superficie d’attacco operativa.