Tra le scoperte di Claude Mythos Preview rese pubbliche da Anthropic con il lancio di Project Glasswing, una in particolare ha catalizzato il dibattito tecnico delle ultime settimane: un bug nello stack TCP di OpenBSD, presente nel codice dal 1998, classificato dagli ingegneri come overflow di intero con segno nella gestione del Selective Acknowledgment (SACK), patchato dalla OpenBSD Foundation a fine marzo 2026 con la errata 025.
La sintesi tecnica è semplice. Il dato che pesa sul dibattito di settore non lo è.
OpenBSD non è un sistema qualunque
OpenBSD è il sistema operativo che, in tre decenni, ha costruito la propria reputazione sulla qualità del codice. La frase di copertina del progetto recita ancora oggi: «Only two remote holes in the default install, in a heck of a long time». La metodologia di sviluppo include audit sistematici, code review tra esperti, riscritture mirate quando una classe di problemi si manifesta, e test di fuzzing automatizzato di lunga durata. La stessa base di codice TCP del kernel viene scrutinata da decenni come pochi altri progetti al mondo.
In un ambiente del genere, la persistenza di un bug per 27 anni non è una bizzarria: è un fatto che obbliga a rivedere alcune ipotesi sulla efficacia delle review umane esperte rispetto a classi di vulnerabilità che richiedono un’analisi semantica fine.
Anatomia del bug: l’overflow ai 2 elevato 31
Il problema vive nel modulo che gestisce i blocchi Selective Acknowledgment (SACK) del protocollo TCP. SACK è quel meccanismo, definito da RFC 2018, con cui il ricevente di un flusso TCP comunica al mittente quali blocchi di dati ha già ricevuto, in modo che il mittente possa rispedire solo i pezzi mancanti senza dover ritrasmettere l’intero burst.
I numeri di sequenza TCP sono interi senza segno a 32 bit. Per definizione possono avvolgersi: dopo il valore 2 elevato 32 meno 1 si torna a zero, in maniera coerente con il design del protocollo. Per confrontare due numeri di sequenza nel modo corretto serve trattare la differenza come un intero con segno a 32 bit, intendendo che i valori positivi indicano «avanti» e i negativi «indietro».
Lo stack TCP di OpenBSD eseguiva, all’arrivo di un blocco SACK, due controlli di congruenza. Il blocco doveva essere sopra l’ultimo byte già riconosciuto e dentro il buco di ritrasmissione. Implementati come sottrazioni in interi con segno a 32 bit, i due confronti risultavano corretti per qualunque valore plausibile di sequenza. Si rompevano per valori al limite: se l’attaccante poneva il valore di inizio del blocco SACK a circa 2 elevato 31 di distanza dalla finestra reale, la sottrazione faceva tracimare contemporaneamente il bit di segno in entrambe le verifiche. Il kernel concludeva quindi due cose impossibili insieme: che il valore fosse al di sotto del buco e al di sopra del massimo riconosciuto.
Il valore «impossibile» passava i controlli di congruenza, raggiungeva il codice di gestione del blocco SACK, e produceva una NULL pointer dereference in una variabile di stato che il kernel non aveva inizializzato in quella branca. Risultato: panic del kernel.
Conseguenza operativa
Per innescare il panic basta che l’attaccante riesca ad aprire una connessione TCP verso un host OpenBSD. Tutti i servizi accessibili in TCP — un firewall pf, un server SSH, un web server, un router con OpenBGPD, un DNS — sono bersagli validi. La crash è remota, non richiede autenticazione, è ripetibile con una manciata di pacchetti accuratamente costruiti.
Il bug non consente, in sé e per sé, l’esecuzione di codice. È classificato come denial of service di livello kernel. In pratica significa che un attaccante può riavviare a piacere qualunque host OpenBSD con un servizio TCP esposto, e tenerlo in cycle di reboot finché non interviene un operatore. Per un router di produzione o per un firewall di una sede aziendale è un effetto sufficiente per costituire un’arma di disservizio.
La storia: 27 anni in pochi paragrafi
SACK arriva nel kernel di OpenBSD nel 1998 con il porting dell’estensione TCP. La condizione di overflow descritta sopra è presente fin dalla prima versione del codice. Negli anni successivi:
- il modulo SACK è rivisto più volte per ottimizzazioni di prestazioni, mai con un cambio di logica nei due confronti;
- nel 2019 il progetto rilascia errata su un altro bug TCP SACK (CVE-2019-8460, segnalato da Check Point Research): un problema diverso, di gestione di pacchetti con sequenze invalide, non legato all’overflow di intero;
- milioni di esecuzioni di fuzzing automatizzato sul modulo TCP non producono il path verso il bug, perché il fuzzing tende a esplorare valori di sequenza vicini alla finestra, non a 2 elevato 31 di distanza;
- il bug attraversa indenne l’intera vita del progetto fino al 2026.
La scoperta: meno di cinquanta dollari di calcolo
Nella documentazione tecnica di Mythos Preview, Anthropic colloca la scoperta di questo bug all’interno di una serie di esecuzioni del modello sull’intera base di codice OpenBSD. La cifra dichiarata per la singola scoperta è netta: meno di 50 dollari di compute per individuare e ricostruire la catena logica del bug in un singolo scaffold run. Mille esecuzioni complete su OpenBSD costano, sempre secondo Anthropic, sotto i 20.000 dollari.
Cinquanta dollari per un bug TCP di kernel su un sistema operativo che è sinonimo, da decenni, di scrutinio rigoroso. La cifra è quella che ha spinto la stampa di settore a usare il termine, ricorrente nelle ultime due settimane, di «commodification» della scoperta di vulnerabilità.
La patch: errata 025 del 25 marzo 2026
La OpenBSD Foundation ha rilasciato la patch il 25 marzo 2026, sotto la sigla errata 025. Il commit corrispondente sul repository git ufficiale del progetto è tracciabile al 0e8206e; il messaggio recita testualmente, secondo la prassi del progetto: «Ignore TCP SACK packets with invalid sequence numbers». La modifica aggiunge la verifica esplicita che la differenza tra il valore di sequenza del blocco SACK e l’ultimo byte riconosciuto sia entro un range plausibile, prima di proseguire con la logica di gestione.
La tempestività dell’intervento — meno di due settimane dalla disclosure coordinata da Anthropic ai manutentori OpenBSD — è coerente con la tradizione del progetto. Errata mirate, niente clamore, codice corretto.
Replicabilità: il punto più scomodo
Il dato meno discusso ma più importante è che, secondo i ricercatori indipendenti di Aisle, la scoperta del bug SACK non richiede Mythos Preview. In una serie di test pubblicati il 7 aprile 2026, Aisle ha mostrato che modelli pubblici e a costo molto inferiore — il loro confronto cita esplicitamente GPT-OSS-120b — possono ricostruire «the full public chain» del bug a partire dalle informazioni rese pubbliche. Kimi K2 ha prodotto, nei loro test, un trace di exploit step-by-step con valori specifici dei numeri di sequenza.
La conseguenza è quella che Aisle ha riassunto con l’espressione «jagged frontier»: la frontiera della capacità offensiva basata su modelli è dentata, non uniforme. Su questa specifica classe di bug, i modelli pubblici sono già oggi sufficienti. Il vantaggio di Mythos Preview rispetto al pubblico, su questa scoperta, è misurabile in costo e in tempo, non in possibilità.
Cosa porta a casa un security architect
Tre osservazioni che reggono al di là del singolo caso:
- L’audit umano paziente non è più sufficiente da solo. Una classe di bug che richiede di esplorare valori di sequenza ai limiti dello spazio aritmetico è difficile da identificare con review tradizionali. La revisione automatica con modelli capaci diventa parte integrante del processo di assurance, non un’aggiunta opzionale.
- Il fuzzing tradizionale ha angoli morti specifici. Le strategie standard di mutazione esplorano lo spazio dei valori in modo statisticamente uniforme intorno a punti rappresentativi. Bug come SACK vivono in regioni dello spazio di input che il fuzzing non vede mai, ma che un modello con conoscenza della semantica del protocollo va a cercare per primo.
- L’esposizione è ovunque. OpenBSD è usato in firewall, in router di carrier, in apparati di sicurezza enterprise, in nodi di routing BGP. Ogni macchina con un servizio TCP esposto è un potenziale bersaglio finché non è aggiornata all’errata 025. La verifica del parco macchine non è un’attività rinviabile.
Ventisette anni in produzione, cinquanta dollari per la scoperta, quattordici giorni per la patch, e una storia che è già un caso di scuola.
Fonti
Anthropic, «Claude Mythos Preview», 7 aprile 2026 (edited 9 aprile 2026): red.anthropic.com/2026/mythos-preview. OpenBSD Project, errata 025 e commit 0e8206e: github.com/openbsd/src. Aisle, «AI Cybersecurity After Mythos: The Jagged Frontier», 7 aprile 2026. Riferimento storico al precedente bug SACK CVE-2019-8460 (Check Point Research, 2019).