L'AI trova i tuoi bug più velocemente di quanto tu riesca a correggerli

Questa settimana sono emerse due notizie che, considerate insieme, dovrebbero far drizzare le antenne a ogni team di sviluppo e sicurezza.

Prima, la più importante: Anthropic ha annunciato Claude Mythos Preview, un nuovo modello di AI che, secondo l'azienda, è troppo pericoloso per essere rilasciato pubblicamente. Il motivo? È straordinariamente bravo a trovare vulnerabilità di sicurezza. Non stiamo parlando di esempi di laboratorio nelle CTF challenge. Mythos ha trovato un bug vecchio di 27 anni in OpenBSD, uno dei sistemi operativi più sicuri al mondo. Ha trovato un difetto in FFmpeg che i tool di testing automatizzato avevano eseguito cinque milioni di volte senza mai rilevare. Ha concatenato più vulnerabilità del kernel Linux per passare da un accesso utente ordinario al controllo completo della macchina. Migliaia di zero-day in tutti i principali OS e browser, la maggior parte non corretti finché Anthropic non li ha segnalati.

Anthropic non rilascerà il modello al pubblico. Ha invece lanciato il Project Glasswing, dando accesso a circa 40 organizzazioni (tra cui alcune delle più grandi aziende tecnologiche al mondo) per analizzare e correggere il proprio codice. Sta inoltre mettendo a disposizione 100 milioni di dollari in crediti di utilizzo e 4 milioni di dollari a fondazioni per la sicurezza open-source.

La seconda storia, più piccola ma forse più istruttiva: CVE-2026-39987, una vulnerabilità di esecuzione di codice remoto pre-autenticazione in Marimo, un notebook Python open-source molto diffuso tra i data scientist. Punteggio CVSS 9,3. La vulnerabilità era in un endpoint WebSocket (/terminal/ws) che semplicemente non verificava l'autenticazione, nonostante tutti gli altri endpoint WebSocket nel codebase lo facessero. Sysdig ha distribuito degli honeypot e ha osservato lo sfruttamento della vulnerabilità entro 10 ore dalla divulgazione pubblica. Dieci ore.

Cosa hanno in comune queste due storie

Il filo che collega Mythos e il CVE di Marimo è lo stesso: la finestra tra l'esistenza di una vulnerabilità e il suo sfruttamento si è drasticamente ridotta.

Con Mythos, stiamo guardando a un'AI in grado di trovare bug che i ricercatori umani non hanno rilevato per decenni. Con il caso Marimo, stiamo guardando ad attaccanti che armano una vulnerabilità divulgata prima che la maggior parte dei team abbia anche solo letto l'advisory. Entrambi puntano nella stessa direzione: la velocità di patching e la consapevolezza della superficie d'attacco non sono più discipline facoltative. Sono una questione di sopravvivenza.

E questo è ciò che mi preoccupa. Il responsabile del red teaming di frontiera di Anthropic ha stimato che i modelli open-weight raggiungeranno le capacità di ricerca di bug di Mythos entro sei-diciotto mesi. Questo significa che non si tratta di una capacità destinata a restare rinchiusa per sempre dietro un accesso di ricerca ristretto. Si diffonderà.

Cosa significa per i team di sviluppo

Se sviluppate applicazioni web, API o qualsiasi cosa con un layer WebSocket, il bug di Marimo dovrebbe suonare fastidiosamente familiare. Un endpoint che ha saltato l'autenticazione. Tutti gli altri endpoint facevano la cosa giusta. È il tipo di incoerenza che scivola attraverso la code review, supera il QA e rimane in produzione per mesi.

Dal nostro lavoro con PHP e Docker per clienti enterprise, vediamo questo schema continuamente. Un team aggiunge un nuovo endpoint, lo copia da uno esistente, rimuove il middleware di autenticazione «temporaneamente» durante lo sviluppo, e lo manda in produzione. Il resto dell'applicazione è protetto alla perfezione. Una route non lo è. Basta questo.

Quando facciamo penetration testing per gaming studio e piattaforme di viaggio, cerchiamo specificamente queste incoerenze. L'endpoint di debug completamente aperto dietro un load balancer. Il pannello di amministrazione che controlla l'autenticazione ma non l'autorizzazione. L'API di staging che per errore è stata puntata al DNS di produzione. Questi sono i bug da cui nascono le vulnerabilità CVSS 9+, ed è esattamente il tipo di difetti logici che i modelli AI di classe Mythos inizieranno a trovare su larga scala.

Conta anche la dimensione mobile

Se stai pensando «questo è un problema lato server, la mia app mobile è al sicuro», ripensaci. Nei nostri progetti nativi iOS e Android, abbiamo visto app che si affidano al server per gestire tutta la validazione della sicurezza. Se il backend viene compromesso attraverso una vulnerabilità come CVE-2026-39987, tutto ciò che l'app mobile invia e riceve è esposto. Token API, dati degli utenti, credenziali di sessione.

L'abbiamo visto in app healthcare e IoT dove il client mobile memorizza dati sensibili in locale e li sincronizza con un backend che il team riteneva sicuro perché «è dietro un firewall». La vulnerabilità di Marimo era sfruttabile tramite una singola connessione WebSocket non autenticata. I firewall non servono se la porta è già aperta dall'interno del layer applicativo.

Anche i nuovi requisiti dell'App Store di Apple per la conformità al watchOS e all'SDK iOS 26 stanno aggiungendo pressione sulle scadenze. I team che si affrettano a rispettare le scadenze di aprile mentre cercano contemporaneamente di mantenere sicuri i propri backend si trovano esattamente in quel tipo di stretta operativa in cui i controlli di autenticazione vengono saltati.

Una cosa che puoi fare adesso

Ecco un passo concreto: verifica la coerenza dell'autenticazione su ogni endpoint WebSocket e real-time della tua applicazione. Non solo «l'app richiede il login?», ma «ogni singolo endpoint, inclusi quelli di debug, terminal, monitoring e interni, applica davvero l'autenticazione?»

La vulnerabilità di Marimo esisteva perché il loro endpoint WebSocket del terminal usava websocket.accept() senza chiamare validate_auth(). Gli altri endpoint la chiamavano. Quel gap — una chiamata a funzione mancante in un singolo file — era una RCE pre-auth con CVSS 9,3.

Se fai parte di un team che gestisce applicazioni web o API, prenditi un'ora questa settimana e fai un grep del tuo codebase cercando i gestori di accept per WebSocket. Controllali uno per uno. Se usi Starlette, FastAPI, Express con ws, o qualsiasi framework che tratta le connessioni WebSocket come un percorso separato dal middleware HTTP, probabilmente hai endpoint che bypassano il tuo normale stack di autenticazione. Trovali prima che lo faccia qualcun altro.

Il quadro più ampio

Anthropic sta inquadrando il Project Glasswing come «i difensori prima di tutto». L'idea è dare ai buoni un vantaggio prima che le capacità di classe Mythos diventino ampiamente disponibili. È una posizione ragionevole, ma poggia anche su una premessa scomoda: l'unico modo per proteggersi da un'AI che trova bug è costruirla per prima e sperare di fare patch più velocemente di quanto gli attaccanti riescano a sfruttarle.

Dal nostro lavoro di sicurezza nella configurazione di Cloudflare e Akamai per la protezione DDoS su piattaforme di viaggio su larga scala, viviamo già in un mondo in cui gli attacchi automatizzati si muovono più velocemente dei tempi di risposta umani. La differenza con la scoperta di vulnerabilità assistita dall'AI è che gli attacchi non saranno solo più veloci. Saranno più intelligenti. Invece della scansione brute-force, si otterrà uno sfruttamento mirato di difetti logici che nessuna regola WAF può intercettare perché l'attacco sembra una richiesta legittima.

Questo cambia il modo in cui si progettano le difese. Le regole statiche non bastano. Serve una sicurezza a strati: autenticazione su ogni endpoint, una corretta segmentazione della rete affinché un notebook server compromesso non possa raggiungere il database di produzione, e un monitoraggio reale — non solo aggregazione di log, ma un'effettiva rilevazione delle anomalie su ciò che stanno facendo le connessioni WebSocket.

Abbiamo già parlato con i nostri clienti di questo cambiamento. Questa settimana lo ha reso tutto molto meno teorico.

Cosa succederà ora

Il settore della sicurezza sta per diventare molto più frenetico. I modelli AI in grado di trovare migliaia di zero-day in una settimana costringeranno i maintainer del software in uno sprint permanente. I progetti open-source con team piccoli — come Marimo — saranno i più colpiti, perché non hanno le risorse per fare patch alla velocità che la minaccia ora richiede.

Se il tuo team sta costruendo su tool open-source per la data science, notebook per sviluppatori o qualsiasi tooling interno progettato per reti fidate ma che ora si trova in qualche modo vicino a internet, questo è il tuo campanello d'allarme. Tratta ogni strumento del tuo stack come parte della tua superficie d'attacco. Fai patch in modo aggressivo. E non dare per scontato che qualcosa sia sicuro solo perché è «interno».

Se tutto questo ti sembra una conversazione che il tuo team deve fare, parliamone.