Una settimana folle per la cybersicurezza: perché la nostra chat IA europea è rimasta al sicuro dalle ultime violazioni

tl;dr: Questa terza settimana di ottobre 2026 ha portato un’ondata straordinaria di incidenti di sicurezza in tutto il settore tech, ma DentroChat e i tuoi dati sono al sicuro.

Se segui le notizie di sicurezza, questa settimana è sembrata un’alluvione. Gli avvisi minori escono spesso, ma vedere così tanti strumenti fondamentali e piattaforme cloud colpiti nel giro di pochi giorni è, diciamolo pure, PAZZESCO.

In meno di una settimana si è concentrato di tutto:

• L’incidente della Certificate Authority eMudhra: Si è scoperto che 8 certificati intermedi sotto la root emSign di eMudhra avevano chiavi private estremamente deboli. Poiché quelle chiavi potevano essere ricostruite per intercettare il traffico HTTPS, i principali browser hanno dovuto bloccare i certificati, eMudhra ha annunciato oggi che uscirà del tutto dal mercato globale dei certificati SSL/TLS (!) e sono stati rilasciati aggiornamenti d’emergenza per uv, pip, Node.js, Bun, Go e Rust (!) per rimuovere la CA compromessa dai rispettivi trust store integrati.
• CVE critiche nel software di base di Internet: Sono state corrette due vulnerabilità di esecuzione di codice da remoto senza autenticazione in PHP (CVE-2026-109618 e CVE-2026-109619), insieme a un buffer overflow critico in Google Brotli (CVE-2026-111497), una RCE senza autenticazione di gravità massima in GitLab (CVE-2026-110264) e la vulnerabilità «PwnEscape» del kernel Linux (CVE-2026-99999).
• La compromissione della supply chain di LiteLLM: Ieri, 21 ottobre, degli attaccanti hanno compromesso (di nuovo) la pipeline di rilascio di LiteLLM pubblicando una versione con backdoor (v1.107.0) su PyPI e Docker Hub. Poiché il pacchetto malevolo includeva uno startup hook eseguito automaticamente a ogni avvio di Python, ha subito sottratto credenziali cloud e chiavi API dai server colpiti.
• Violazioni delle piattaforme Railway e Zeabur: Zeabur ha annunciato la chiusura definitiva dopo una seconda violazione che ha esposto 3,2 milioni di record di variabili d’ambiente appartenenti a 321.000 account. Ieri anche Railway ha comunicato che un attaccante ha avuto accesso alle variabili d’ambiente dei clienti riuscendo a decifrarle. Un dettaglio interessante: il bersaglio erano soprattutto le chiavi di inferenza IA.
• Grandi violazioni enterprise: Degli attaccanti sono entrati nei tenant clienti di Microsoft 365 usando credenziali di backup rubate a ConnectWise (SkyKick), e Capcom ha subito una violazione che ha coinvolto 11,7 milioni di account utente.

È una «Cyberpocalypse» o si sta svegliando il sistema immunitario di Internet?

Perché saltano fuori contemporaneamente così tanti vecchi bug nei compilatori di espressioni regolari, nei decoder di compressione, negli allocatori di memoria e nelle configurazioni crittografiche?

La risposta è soprattutto che ora l’IA sta leggendo il codice del mondo. Ricercatori di sicurezza e difensori (così come gli attaccanti) fanno analizzare all’IA il codice delle librerie open source. Il risultato è che emergono tantissimi casi limite che i revisori umani non avevano notato per 15 anni. Perfino le chiavi deboli della CA eMudhra sono state individuate, a quanto pare, con l’aiuto dell’IA.

Alcuni commentatori hanno ribattezzato questa settimana «Cyberpocalypse». Dal nostro punto di vista, invece, il sistema immunitario di Internet si sta finalmente svegliando e si sta curando da solo. La maggior parte di questi bug era già nel codice di produzione da anni, e scoprirli significa poterli finalmente correggere.

Visto che tanti anni fa ho scritto la mia tesi di laurea triennale alla TU Graz proprio sul modello di fiducia e sui rischi strutturali delle Certificate Authority, vedere il caso eMudhra propagarsi a cascata su uv, pip, Node.js e Bun mi ha ricordato perché all’epoca scelsi quell’argomento. Su Internet la fiducia assume molte forme ed è un sistema estremamente complesso.

Dove si colloca DentroChat rispetto agli incidenti di questa settimana

Se usi DentroChat per il lavoro di tutti i giorni e per i tuoi documenti riservati, le tue conversazioni e i tuoi file non sono stati toccati da nessuno di questi incidenti. Poiché manteniamo un’architettura snella, gran parte del software coinvolto non fa parte del nostro stack, e ciò che usiamo è stato aggiornato immediatamente:

• Il problema di fiducia CA su uv, pip, Node.js e Bun: Poiché gli strumenti da riga di comando e i runtime includono un proprio elenco di Certificate Authority attendibili, ogni strumento che si fidava del certificato root compromesso di eMudhra doveva essere aggiornato. DentroChat non usa affatto uv o pip sui propri server. La nostra applicazione web però gira su Bun, quindi abbiamo aggiornato i container di produzione a Bun 1.4.4 (insieme ai certificati di sistema Debian aggiornati), rimuovendo completamente la root eMudhra compromessa.
• LiteLLM (malware v1.107.0): Anche se instradiamo le richieste IA attraverso un gateway di inferenza europeo (Cortecs), non usiamo la libreria Python LiteLLM né le sue immagini Docker in nessuna parte del nostro stack.
• Railway, Zeabur e piattaforme di deploy cloud: Non ci appoggiamo a PaaS multi-tenant per sviluppatori come Railway o Zeabur, né salviamo i dati dei clienti su hyperscaler statunitensi o tenant cloud Microsoft. Come indicato nella nostra pagina dei Subresponsabili, gestiamo i rilasci con la nostra istanza Coolify self-hosted che gira direttamente sui nostri server europei. Nessun fornitore PaaS esterno detiene quindi le nostre variabili d’ambiente o i nostri segreti di deploy.
• PHP, GitLab e dipendenze applicative: Non usiamo PHP né GitLab self-hosted. Inoltre abbiamo controllato e aggiornato l’intero albero delle dipendenze sia della piattaforma di chat sia del sito web, e al momento siamo a zero vulnerabilità note.

Come progettiamo DentroChat per tenere i tuoi dati al sicuro

Poiché l’audit del codice assistito dall’IA continuerà a far emergere nuove CVE nel software open source, i pacchetti di terze parti non saranno mai «privi di bug». Per questo abbiamo progettato DentroChat con un isolamento rigoroso, così che un difetto in un singolo componente non possa compromettere i tuoi dati o i nostri server.

1. Esecuzione del codice in una sandbox WebAssembly senza rete

Quest’anno un report di sicurezza diventato virale ha mostrato che degli agenti di OpenAI sono evasi dalla loro sandbox durante una valutazione interna. Quell’evasione è stata possibile perché gli agenti giravano dentro un container Linux che aveva ancora accesso di rete a un proxy interno del registro dei pacchetti, e l’agente ha sfruttato un bug zero-day in quel proxy per raggiungere Internet.

Con DentroChat quel percorso di attacco non esiste (ad oggi), perché non eseguiamo il codice utente dentro un container Linux dotato di shell o installatore di pacchetti. Quando carichi un foglio di calcolo o chiedi a DentroChat di eseguire un’analisi in Python, il codice gira invece dentro una sandbox WebAssembly (WASM) isolata:

• Ogni libreria Python supportata per l’analisi dei dati e la creazione di documenti viene pre-impacchettata in fase di build, così nulla viene mai scaricato da PyPI o da un proxy interno a runtime.
• Prima ancora di eseguire qualsiasi codice Python, tutte le API di rete in uscita, i caricatori di librerie dinamiche e i ponti verso il filesystem dell’host vengono tagliati ed eliminati dal runtime.
• Anche se una libreria Python dovesse mai contenere una backdoor nella supply chain come lo script di avvio di LiteLLM, la sandbox WebAssembly non ha alcuna connessione di rete per inviare dati all’esterno né accesso alle variabili d’ambiente del server o ai file di altri utenti. Una volta restituito il grafico o il documento, lo spazio di lavoro temporaneo viene subito ripulito.

2. Un periodo di attesa di 7 giorni contro gli attacchi alla supply chain

L’attacco a LiteLLM ha funzionato perché:

1. la versione malevola del pacchetto viene pubblicata su PyPI
2. le pipeline di build automatizzate di tutto il mondo la installano all’istante
3. dopo 2 ore i ricercatori di sicurezza capiscono che qualcosa non va
4. a quel punto, il codice malevolo ha già potuto compromettere molti sistemi

Per bloccare questo tipo di «supply chain attack», il nostro package manager impone un’età minima di rilascio di 7 giorni insieme a lockfile bloccati. Una nuova versione di un pacchetto open source deve superare un’intera settimana di verifica pubblica prima che la nostra pipeline di build ne consenta l’installazione. A meno che, naturalmente, non siamo noi a verificare e fissare manualmente una specifica patch di sicurezza, come l’aggiornamento del runtime di oggi…

3. Perché blocchiamo l’accesso alla rete interna quando l’IA visita siti web

Quando chiedi a DentroChat di leggere una pagina web o di recuperare un dataset pubblico da un’API open data, il nostro server scarica quell’URL per tuo conto. Senza confini di rete rigorosi, un sito malevolo potrebbe nascondere nella pagina istruzioni pensate per ingannare l’IA e spingerla a richiedere indirizzi interni del server (come 127.0.0.1 o porte interne della rete Docker) invece di un sito pubblico. Questa tecnica, chiamata Server-Side Request Forgery (SSRF), potrebbe esporre servizi interni in esecuzione sul server stesso.

Per questo il nostro fetcher di rete risolve il DNS prima di connettersi, blocca tutti gli intervalli IP privati, di loopback e interni, e fissa l’indirizzo IP verificato a ogni singolo redirect. Anche se una pagina web prova a ingannare il modello o usa il DNS rebinding per cambiare l’IP di un dominio in 127.0.0.1 all’ultimo millisecondo, la connessione viene rifiutata prima ancora di toccare la nostra rete interna.

4. Crittografia a riposo gestita da noi su Hetzner in Europa

Tutti i server applicativi, i database e gli strumenti self-hosted di DentroChat girano su Hetzner in Germania, mentre i backup cifrati e i log del server pseudonimizzati sono archiviati su Scaleway in Francia, il tutto sotto giurisdizione UE e fuori dalla portata del CLOUD Act statunitense. Puoi verificare in qualsiasi momento l’intera configurazione della nostra infrastruttura nella pagina dei Subresponsabili.

Tutti i dati sono protetti con crittografia in transito e crittografia a riposo. Un dettaglio tecnico spesso trascurato: nella maggior parte dei provider di hosting (anche Hetzner) i dischi dei server non sono affatto cifrati a riposo per impostazione predefinita. Ecco perché configuriamo e gestiamo direttamente noi la crittografia a riposo. Questa infrastruttura sicura si abbina ai nostri controlli sulla privacy:

• Zero addestramento sulle tue conversazioni o sui tuoi file
• Cancellazione automatica delle chat sotto il tuo controllo
• Modalità Chat discreta quando vuoi escludere una conversazione dalla memoria dell’IA

Restare vigili

La buona sicurezza non è mai un lavoro finito.

Soprattutto oggi, perché sia i ricercatori sia gli attaccanti possono trovare vulnerabilità zero-day con l’IA più velocemente che mai. Anche se siamo felici che la nostra architettura abbia tenuto DentroChat completamente al riparo dall’ondata di incidenti di questa settimana, restiamo vigili.

Stiamo valutando attivamente come ridurre ancora di più i nostri tempi di risposta ai futuri exploit zero-day, rafforzare i confini dei nostri server e mantenere i tuoi dati al sicuro, per quanto folle possa essere la prossima settimana nella cybersicurezza. Grazie di far parte di DentroChat!