Quando i ricercatori hanno spiegato come Mythos di Anthropic avesse contribuito a costruire una catena completa di sfruttamento, Rejetto aveva già corretto la falla critica nel suo HTTP File Server. La versione 3.2.1 è uscita il 13 luglio 2026, Horizon3 ha pubblicato l’analisi tecnica il 30 settembre e VulnCheck ha osservato tentativi di sfruttamento il 1º ottobre. L’intervallo significativo non è un giorno senza patch disponibile, ma oltre due mesi durante i quali alcune installazioni esposte sembrano essere rimaste senza protezione.
CVE-2026-61500 interessa HFS da 3.0.0 a 3.2.0. Secondo Horizon3, la ricerca assistita dall’IA ha collegato casualità prevedibile, valori visibili nel login e cookie di sessione firmati all’esecuzione di codice con privilegi amministrativi. È una capacità di ricerca rilevante, non la prova di un hacking autonomo universale né una misura delle infezioni globali.
Una chiave di firma ricostruibile
HFS condivide file tramite un server web. Il ramo 3.x è una riscrittura in TypeScript, eseguita su Node.js con Koa; il vecchio 2.x usava Delphi. Nelle versioni vulnerabili, HFS generava la chiave predefinita per firmare i cookie con Math.random() di JavaScript: un generatore pseudocasuale generico, non una fonte crittograficamente sicura.
Un cookie firmato protegge l’integrità solo finché la chiave rimane segreta e imprevedibile. Parallelamente, un flusso di login non autenticato esponeva risultati a precisione completa dello stesso generatore. Non erano indipendenti dai valori usati all’avvio per costruire la chiave: il generatore segue una sequenza deterministica a partire dal proprio stato interno.
Horizon3 riferisce che un agente specializzato nell’analisi crittografica ha identificato tre estrazioni per la chiave iniziale e collegato i valori esposti all’implementazione xorshift128+ di V8. Il suo stato reversibile consentiva la ricostruzione a ritroso, una volta raccolte sufficienti osservazioni correlate. La reversibilità da sola non rende sfruttabile ogni applicazione: HFS forniva anche osservazioni e relazione con il segreto.
Il caso dimostrato usava 12 osservazioni e Z3, il risolutore di soddisfacibilità modulo teorie di Microsoft, per trovare uno stato compatibile con i vincoli. Un cookie esistente e il suo codice di autenticazione del messaggio permettevano di verificare offline le chiavi candidate. Era ricostruzione matematica, non ripetuti tentativi online di indovinare password. Il cookie era firmato ma non cifrato, quindi il client poteva leggere i propri dati di sessione.
La chiave recuperata permetteva di creare un cookie che dichiarava identità amministrativa conservando una firma valida. La catena descritta verificava la presenza dell’account amministratore incorporato. Accettata la sessione, la funzione legittima di HFS per JavaScript personalizzato lato server apriva la strada a comandi arbitrari. Si raggiungeva una funzione privilegiata mediante identità falsificata, non semplicemente sfruttando un parser con input malformati.
La correzione modifica entrambi i punti: byte casuali crittograficamente sicuri per la chiave e un UUID casuale per l’identificatore esposto dal login. Impostare esplicitamente una chiave robusta può mitigare una parte della catena, ma non sostituisce l’installazione di 3.2.1 o di una versione stabile successiva.
Che cosa ha davvero aggiunto l’IA
Uno scanner poteva già segnalare Math.random() vicino al codice di autenticazione. La difficoltà era collegare l’avviso a risultati osservabili, formato esatto della sessione, chiave recuperata e operazione privilegiata dalle conseguenze reali. Ogni passaggio aumenta incertezza e lavoro specialistico, fino a rendere poco conveniente proseguire l’indagine.
Horizon3 sostiene che Mythos abbia connesso file, comportamento del framework e matematica del generatore, producendo poi una prova di concetto funzionante che eseguiva comandi sull’host. Ricercatori umani hanno controllato e riprodotto il risultato prima della divulgazione. Un exploit funzionante rende la priorità più concreta di un arresto inspiegato o una riga sospetta.
Era un caso di Project Glasswing, con un ambiente su misura e agenti specializzati in parallelo. Persone hanno scelto il bersaglio, organizzato l’indagine, verificato il risultato e coordinato la segnalazione. Non era un normale chatbot per consumatori che comprometteva istantaneamente un repository qualsiasi senza aiuto.
Anche il rapporto sulle capacità di Anthropic sottolinea lo sfruttamento completo come prova dell’impatto. Il possibile cambiamento è economico: indagini che prima richiedevano competenze crittografiche eccezionalmente costose potrebbero diventare convenienti. I singoli ingredienti erano noti; il valore consisteva nell’unirli in una catena verificata.
Il caso pubblico non fornisce il denominatore per valutare la produttività generale. Calcolo totale, esecuzioni fallite, falsi positivi e risultati scartati restano incognite importanti. Un successo eccezionale non stabilisce con quale regolarità il sistema trovi falle critiche né se il costo sia adatto a un programma più ampio.
Tentativi dopo la divulgazione, non conteggio delle infezioni
La patch del 13 luglio precedeva di oltre due mesi la spiegazione del 30 settembre. Le osservazioni VulnCheck del 1º ottobre riguardano quindi sistemi con una correzione già disponibile, non una falla appena pubblicata senza rimedi per gli amministratori.
Il traffico iniziale riportato usava infrastrutture ospitate in Cina contro sistemi statunitensi. Richieste successive provenivano da due indirizzi americani nella stessa sottorete, apparentemente proxy; sono stati segnalati anche bersagli in Giappone. La geografia dell’hosting non identifica gli operatori né dimostra sostegno statale.
Le rilevazioni attestano tentativi, non quanti bersagli abbiano accettato sessioni amministrative falsificate o eseguito comandi. Non giustificano stime globali delle compromissioni né l’affermazione di una grande campagna persistente. Payload successivi e vittime confermate cambierebbero sostanzialmente la valutazione.
Neppure l’intervallo di circa un giorno dimostra che gli aggressori usassero IA o avessero risolto da soli tutti i passaggi matematici durante la notte. Potrebbero aver adattato materiale pubblico, lavorato in precedenza o utilizzato altre informazioni. Scanner, confronto delle patch, framework di exploit e reverse engineering umano consentivano già un riuso rapido.
La politica di divulgazione coordinata di Anthropic prevede generalmente notifica ai manutentori, revisione umana e un periodo di 90 giorni, normalmente attendendo 45 giorni dalla patch prima dei dettagli completi. Qui l’intervallo è stato maggiore. Il margine offre un’opportunità per aggiornare, non garantisce di aver individuato ogni servizio vulnerabile.
Il cronometro si ferma dopo la verifica del rilascio
Server leggeri per file possono sfuggire all’inventario e alle responsabilità ordinarie: un servizio temporaneo resta attivo, un vecchio container rimane fissato oppure un inoltro di porta dimenticato mantiene l’host raggiungibile. Pochi utenti non rendono meno utile l’esecuzione non autenticata come punto d’ingresso.
Conta il tempo dalla disponibilità del rimedio all’aggiornamento, isolamento o rimozione di tutte le istanze vulnerabili esposte, non la data di assegnazione di un ticket. Inventari, registri container, installazioni sugli endpoint, carichi cloud e servizi raggiungibili dall’esterno sono tutti rilevanti. La verifica deve individuare il binario o l’immagine che risponde davvero.
Distinguere le versioni è essenziale. CVE-2024-23692, precedente falla HFS inserita nel catalogo CISA delle vulnerabilità sfruttate nel 2024, interessava la differente base 2.x. Non è questa catena crittografica e non implica che ogni installazione HFS sia compromessa.
VPN, liste consentite o gateway autenticati possono limitare l’esposizione superflua per gruppi ristretti, ma non sostituiscono l’aggiornamento. Un endpoint fidato può essere compromesso, una configurazione cambiare e un confine presunto fallire.
I log attorno al 30 settembre e successivi meritano controlli per autenticazioni ripetute, sessioni amministrative inattese, cambiamenti di configurazione e codice server sconosciuto. Sono piste investigative, non indicatori universali e definitivi. Su un host compromesso con certezza, aggiornare non rimuove eventuale persistenza in account, attività pianificate, script di avvio o altri servizi. Restano pertinenti isolamento, conservazione delle prove, rotazione delle credenziali, valutazione delle risorse collegate e ricostruzione se l’integrità è incerta.
La scoperta deve diventare rimedio
Per gli sviluppatori la lezione supera una singola funzione. I generatori pseudocasuali generici non dovrebbero fornire segreti di autenticazione, token di ripristino, nonce crittografici o identificatori di sessione sensibili. Occorre seguire stato condiviso e fughe di risultati correlati: un middleware di firma non rende sicura una chiave prevedibile.
L’IA può seguire relazioni tra file e verificare se una debolezza teorica raggiunga privilegi reali. La validazione umana deve ancora controllare versioni, presupposti ambientali e trasferibilità della dimostrazione da un harness ai sistemi distribuiti.
Tre sviluppi chiariranno l’impatto: se i sondaggi diventano attacchi persistenti con payload successivi alla compromissione; se spariscono le versioni esposte interessate; e se i successivi rapporti Glasswing restano riproducibili, importanti e gestibili dai manutentori, anziché sommergerli di segnalazioni poco utili.
HFS sostiene una conclusione più circoscritta ma sostanziale: un sistema di ricerca assistito dall’IA ha aiutato specialisti a dimostrare un exploit insolito dall’inizio alla fine. Il valore difensivo dipende infine dalla capacità dei manutentori di elaborare il risultato e degli operatori di convertire una correzione disponibile in protezione verificata.
Fonti
Analisi tecnica Horizon3 · Versione HFS 3.2.1 · Rapporto sulle capacità di Mythos · Traffico di attacco osservato · Politica di divulgazione · Precedente vulnerabilità HFS · Notizia originale