La vulnerabilità HFS di Anthropic Mythos è stata corretta, poi sono arrivati gli attaccanti
Mythos di Anthropic ha contribuito a individuare una grave falla in HFS, ma lo sfruttamento segnalato è iniziato poco dopo che i ricercatori hanno pubblicato la catena d'attacco completa. La vulnerabilità HFS di Anthropic Mythos consente a un attaccante non autenticato di ricostruire un segreto del server, falsificare una sessione di amministratore e arrivare all'esecuzione di codice remoto.
La falla, identificata come CVE-2026-61500, interessa Rejetto HTTP File Server nelle versioni dalla 3.0.0 alla 3.2.0. Rejetto l'ha corretta nella versione 3.2.1 nel luglio 2026. Horizon3 ha pubblicato la propria analisi tecnica dettagliata il 30 settembre e VulnCheck ha rilevato tentativi di sfruttamento il giorno successivo.
Questa sequenza rende il caso più di una semplice storia di scoperta di vulnerabilità assistita dall'AI. Mythos non si è limitato a evidenziare una funzione sospetta. Secondo Horizon3, ha collegato debolezze separate, modellato un generatore di numeri casuali reversibile, costruito i vincoli necessari e prodotto un exploit funzionante.
La parte inquietante è arrivata dopo la divulgazione. I difensori disponevano di una patch da oltre due mesi, eppure i sistemi vulnerabili sembravano ancora raggiungibili quando le meccaniche dell'exploit sono diventate pubbliche. La sfida centrale non è quindi Mythos contro un altro modello AI. È la ricerca accelerata delle vulnerabilità contro il processo più lento di identificazione, aggiornamento e verifica del software esposto.
La vulnerabilità HFS di Anthropic Mythos trasforma la casualità in accesso amministrativo
CVE-2026-61500 trasforma una fonte debole di casualità in un percorso non autenticato verso il controllo amministrativo completo.
Rejetto HFS è un server open source per la condivisione di file sul web. Il suo attuale ramo 3.x gira su Node.js e usa Koa, un framework JavaScript per il web, per gestire richieste e sessioni.
Un cookie di sessione indica a un'applicazione web quale utente autenticato sta effettuando una richiesta. Il server firma quel cookie con una chiave segreta, così un attaccante non può modificare nome utente o privilegi senza invalidare la firma.
HFS creava la propria chiave di firma predefinita con la funzione JavaScript Math.random(). Questa funzione è adatta ai normali comportamenti casuali, ma non è progettata per generare segreti crittografici.
Il problema andava oltre la scelta iniziale del generatore. HFS esponeva anche altri valori dallo stesso generatore di numeri pseudocasuali durante una parte del processo di accesso. Un generatore di numeri pseudocasuali, o PRNG, produce una sequenza deterministica a partire da uno stato interno.
La divulgazione tecnica di Horizon3 afferma che Mythos ha identificato entrambi i lati di questa relazione. Ha individuato la debole generazione della chiave di firma e un percorso separato, non autenticato, che rivelava output osservabili della stessa sequenza.
Il modello ha quindi dedotto che un numero sufficiente di output avrebbe permesso di ricostruire lo stato del generatore. Da lì, un attaccante avrebbe potuto procedere a ritroso nella sequenza e riprodurre i valori usati da HFS per creare la propria chiave di firma.
Non equivale a indovinare una password tramite tentativi di accesso ripetuti. L'attaccante risolve invece lo stato interno di un sistema deterministico. Una volta noto quello stato, la chiave apparentemente segreta diventa riproducibile.
La catena dimostrata da Horizon3 inizia verificando se esiste il nome utente dell'amministratore integrato. L'attaccante richiede quindi ripetutamente un'operazione di accesso per raccogliere gli output Math.random() esposti.
Nell'exploit descritto, i ricercatori hanno interrogato l'endpoint vulnerabile 12 volte. Tali osservazioni sono diventate vincoli per Z3, un solver di soddisfacibilità modulo teorie sviluppato da Microsoft.
Un solver SMT determina quali valori soddisfano un insieme di condizioni logiche e matematiche. In questo caso, ha aiutato a recuperare uno stato coerente con gli output casuali osservati e con il comportamento noto di HFS.
L'attaccante può quindi riportare indietro lo stato recuperato fino alla sequenza di avvio del server. Ciò rivela i valori usati per costruire la chiave di firma del cookie.
Con quella chiave, l'attaccante crea un cookie firmato correttamente che dichiara di rappresentare l'amministratore. HFS accetta la sessione falsificata perché la firma è valida, anche se il vero amministratore non ha mai autenticato l'attaccante.
L'accesso amministrativo fornisce l'ultimo anello. HFS supporta codice personalizzato lato server, quindi un amministratore può configurare JavaScript che viene eseguito sull'host. Horizon3 ha usato questa capacità legittima per dimostrare l'esecuzione di comandi arbitrari.
La distinzione è importante. Il comportamento pericoloso non dipende dall'iniezione di codice malformato tramite un bug accidentale del parser. Combina un'identità falsificata con una funzione intenzionalmente disponibile agli amministratori.
La correzione di Rejetto affronta entrambe le fonti di prevedibilità. La versione corretta utilizza byte casuali crittograficamente sicuri per la chiave di firma e un UUID casuale per l'identificatore di accesso esposto.
Gli operatori dovrebbero installare la release HFS 3.2.1 o una versione stabile più recente. L'impostazione di una chiave di firma esplicita e robusta può ridurre una parte del rischio, ma l'aggiornamento rimuove la catena documentata e resta la risposta appropriata.
Mythos ha individuato una catena che i revisori umani avrebbero potuto abbandonare
Il risultato importante di Mythos non è stato identificare `Math.random()`, ma dimostrare che diversi errori apparentemente ordinari formavano un exploit pratico.
Gli strumenti di analisi statica avvertono gli sviluppatori da anni sui generatori di numeri casuali deboli. Uno scanner può cercare Math.random() vicino al codice di autenticazione e segnalare la riga per la revisione.
Questa osservazione da sola non dimostra una compromissione remota. Un ricercatore deve comunque stabilire se un attaccante possa osservare output correlati, ricostruire il generatore, recuperare la chiave esatta, falsificare il corretto formato del cookie e trasformare l'autenticazione in un impatto concreto.
Ogni passaggio aggiunge lavoro e incertezza. Ciò spesso determina se un risultato riceve ulteriori indagini, soprattutto quando i ricercatori devono scegliere tra molte possibili piste.
Horizon3 afferma che Mythos ha gestito questo percorso di ragionamento più lungo. Il suo agente specializzato nell'analisi crittografica ha notato che HFS consumava tre output casuali durante la creazione della chiave di firma all'avvio.
Il modello ha inoltre identificato un percorso di accesso che restituiva valori a precisione completa prodotti dallo stesso generatore. Ha riconosciuto che il cookie era firmato ma non cifrato, consentendo al client di leggere i propri dati di sessione.
Mythos ha quindi collegato questi fatti all'implementazione xorshift128+ di V8. V8 è il motore JavaScript usato da Node.js e xorshift128+ mantiene uno stato interno reversibile.
La reversibilità non rende automaticamente sfruttabile ogni applicazione che usa il generatore. L'attaccante necessita comunque di un numero sufficiente di osservazioni utili e di un modo per correlarle alla sequenza che genera il segreto.
HFS forniva entrambe le condizioni. Esponeva valori consecutivi attraverso il flusso di accesso, mentre la chiave di firma proveniva dallo stesso generatore all'avvio del processo.
Il modello ha proposto di usare Z3 per recuperare lo stato invece di tentare una ricerca ingenua tra ogni possibile chiave. Ha anche identificato un cookie e una firma esistenti come meccanismo di verifica offline.
Questo passaggio di verifica è significativo. Un candidato recuperato può essere testato localmente rispetto al codice di autenticazione del messaggio di un cookie legittimo. L'attaccante non deve inviare ogni candidato al bersaglio e generare richieste fallite evidenti.
Secondo Horizon3, Mythos ha creato il proof of concept funzionante e dimostrato l'esecuzione di comandi arbitrari. I ricercatori umani hanno esaminato il risultato prima della divulgazione, aspetto essenziale quando l'analisi di un modello può contenere errori sottili.
Il più ampio report sulle capacità di Mythos di Anthropic descrive un'analoga enfasi sullo sfruttamento completo. L'azienda sostiene che produrre un exploit funzionante aiuti a distinguere le vulnerabilità rilevanti da crash o codice sospetto privo di impatto pratico.
Questo approccio può migliorare il triage difensivo. Un percorso confermato verso l'accesso amministrativo merita un trattamento diverso da un avviso isolato senza un trigger accessibile.
Riduce inoltre la barriera economica per perseguire classi di vulnerabilità insolite. I ricercatori di Horizon3 hanno affermato che i risultati crittografici possono essere deprioritizzati perché dimostrarli richiede conoscenze matematiche specialistiche e molto tempo.
Un sistema AI che completa questi passaggi può rendere praticabile una ricerca in precedenza non sostenibile economicamente. L'insieme dei bug che vale la pena investigare cresce quando il costo marginale di costruire e testare un exploit diminuisce.
L'exploit HFS di Mythos illustra chiaramente questo cambiamento. Nessun singolo elemento era senza precedenti. Casualità debole, output del generatore esposti, cookie firmati e funzioni amministrative privilegiate sono concetti di sicurezza consolidati.
Il cambiamento risiede nella sintesi. Secondo quanto riportato, Mythos ha seguito la relazione attraverso file, framework, comportamento matematico e funzioni applicative senza richiedere ai ricercatori di prescrivere ciascun passaggio intermedio.
È anche per questo che le affermazioni semplicistiche sull'AI che “trova un bug” non colgono la vera pressione. La scoperta ha valore, ma la costruzione dell'exploit determina se un risultato diventa un problema operativo urgente.
La divulgazione pubblica si è scontrata con un ciclo di patch lento
La patch esisteva prima dell'analisi completa dell'exploit, eppure i sistemi HFS esposti pubblicamente sarebbero rimasti vulnerabili quando il metodo è diventato più facile da riprodurre.
Rejetto ha rilasciato la versione 3.2.1 il 13 luglio 2026. I record CVE identificano come interessate le versioni dalla 3.0.0 alla 3.2.0.
Horizon3 ha atteso fino al 30 settembre per pubblicare la propria analisi dettagliata. Quel ritardo ha dato agli amministratori il tempo di aggiornare senza fornire agli attaccanti una spiegazione completa della vulnerabilità.
La divulgazione includeva le meccaniche importanti. Descriveva la fuga di numeri casuali, la ricostruzione dello stato, il recupero della chiave, la sessione amministrativa falsificata e il passaggio all'esecuzione di codice.
VulnCheck ha iniziato a rilevare tentativi di sfruttamento il 1° ottobre, secondo il traffico d'attacco osservato. L'attività iniziale avrebbe coinvolto infrastrutture ospitate in Cina che prendevano di mira sistemi vulnerabili negli Stati Uniti.
Richieste successive provenivano da due indirizzi statunitensi nella stessa subnet, che sembravano operare come proxy. I ricercatori hanno inoltre segnalato attività contro sistemi in Giappone.
Queste osservazioni supportano l'ipotesi di tentativi di sfruttamento attivi, ma non stabiliscono l'identità dell'attaccante né un'affiliazione governativa. La posizione dell'hosting e quella del proxy sono segnali deboli per l'attribuzione.
Non rivelano neppure quanti sistemi siano stati compromessi. Un rilevamento può mostrare che qualcuno ha inviato traffico correlato all'exploit senza dimostrare che il bersaglio abbia accettato una sessione falsificata o eseguito un comando.
Anche con questi limiti, la tempistica è importante. La prima attività osservata ha seguito la spiegazione tecnica pubblica di circa un giorno.
Ciò non dimostra che gli attaccanti abbiano riprodotto indipendentemente ogni passaggio matematico in quel periodo. Potrebbero aver sviluppato la tecnica in precedenza, adattato materiale divulgato o ottenuto informazioni sufficienti da record di vulnerabilità esistenti.
La lezione operativa resta la stessa. Una volta che informazioni dettagliate su un exploit diventano pubbliche, i difensori dovrebbero presumere che attori capaci possano tradurle rapidamente in attività di scansione e attacco.
La policy di divulgazione di Anthropic mira a bilanciare queste esigenze contrapposte. In generale prevede la notifica ai manutentori, un periodo di divulgazione di 90 giorni e la revisione umana delle segnalazioni generate dall’AI.
La policy afferma che Anthropic normalmente attende 45 giorni dopo una patch prima di pubblicare tutti i dettagli tecnici. Questo intervallo è pensato per dare agli utenti a valle il tempo di distribuire le correzioni.
CVE-2026-61500 ha avuto un intervallo più lungo tra la patch di luglio e l’analisi di Horizon3 a settembre. La comparsa di sistemi vulnerabili dopo tale intervallo mostra perché i tempi di divulgazione non possono compensare una visibilità incompleta delle risorse.
Un server può essere trascurato perché distribuito per un trasferimento temporaneo e mai inserito in un inventario. Un container può rimanere bloccato su un’immagine più vecchia. Un servizio self-hosted può anche trovarsi dietro una regola di port forwarding dimenticata.
HFS attrae proprio questi casi d’uso leggeri. La sua accessibilità semplifica la condivisione dei file, ma può anche incoraggiare distribuzioni al di fuori di un’infrastruttura gestita centralmente.
La storia del software rende concreta questa preoccupazione. Una precedente falla di HFS che interessava il vecchio ramo 2.x è entrata nel catalogo Known Exploited Vulnerabilities di CISA nel 2024.
Quel problema precedente era una vulnerabilità diversa, in una base di codice diversa. HFS 3.x è stato riscritto in TypeScript, mentre il ramo 2.x utilizzava Delphi.
Il precedente non significa che ogni installazione HFS sia compromessa. Mostra però che i file server esposti a internet sono bersagli interessanti, soprattutto quando lo sfruttamento porta direttamente all’esecuzione di codice.
Il patching richiede quindi una fase di verifica. I team di sicurezza non dovrebbero chiudere il ticket quando viene assegnato un aggiornamento. Dovrebbero confermare che ogni istanza raggiungibile riporti una versione corretta e che vecchi container o binari non rispondano più alle richieste.
La vera gara è tra la scoperta tramite AI e la velocità di remediation
Mythos accelera il ritmo della ricerca sulla sicurezza, ma l’esposizione di un’organizzazione dipende ancora dalla rapidità con cui riesce a individuare e aggiornare i propri sistemi.
I programmi di sicurezza spesso misurano la gestione delle vulnerabilità attraverso i numeri. I team riferiscono quante segnalazioni hanno aperto, quante patch hanno distribuito o quale percentuale ha rispettato un obiettivo di livello di servizio.
CVE-2026-61500 evidenzia un intervallo più significativo. L’orologio importante inizia quando una correzione diventa disponibile e termina quando ogni istanza vulnerabile esposta viene aggiornata, isolata o rimossa.
La ricerca assistita dall’AI riduce il tempo necessario per trasformare il codice sorgente in un percorso d’attacco convalidato. La divulgazione pubblica rende poi quel percorso più economico da riprodurre per altri ricercatori e aggressori.
Il processo di patching non accelera automaticamente allo stesso ritmo. Dipende ancora da registri di proprietà, finestre di manutenzione, test, approvazioni, distribuzione e conferma.
Questo crea una competizione asimmetrica. I ricercatori possono parallelizzare l’analisi tra repository, mentre i difensori devono gestire ogni sistema di produzione interessato nel proprio contesto aziendale.
La vulnerabilità Anthropic Mythos HFS dimostra inoltre perché i soli punteggi di gravità siano insufficienti. Una valutazione critica identifica il potenziale impatto, ma non dice a un’organizzazione se l’applicazione vulnerabile sia raggiungibile da internet.
Al contrario, un piccolo server per la condivisione di file può ricevere poca attenzione perché supporta solo pochi utenti. Se consente l’esecuzione remota di codice senza autenticazione, il suo modesto profilo aziendale non ne riduce l’utilità come punto di ingresso.
La risposta corretta inizia con la scoperta. I team dovrebbero cercare Rejetto HFS negli inventari software, nei registri dei container, nei carichi di lavoro cloud, nelle distribuzioni sugli endpoint e nei servizi accessibili esternamente.
Dovrebbero distinguere il ramo 3.x dalle versioni HFS più vecchie, poiché correzioni e meccanismi di vulnerabilità differiscono. Qualsiasi installazione 3.x supportata dovrebbe eseguire la versione 3.2.1 o successiva, anche se è preferibile la più recente release stabile.
I controlli di rete forniscono un ulteriore livello di protezione. Un’istanza HFS destinata a un gruppo limitato non dovrebbe rimanere aperta all’intera internet quando l’accesso può essere limitato tramite VPN, allowlist o gateway autenticato.
Questi controlli non sostituiscono l’aggiornamento. Un endpoint affidabile compromesso, un errore di configurazione o una futura modifica della rete possono esporre un servizio che gli amministratori ritenevano isolato.
I team dovrebbero inoltre esaminare i log del server attorno alla data della divulgazione pubblica. Chiamate ripetute agli endpoint di autenticazione, sessioni amministrative inattese, modifiche alla configurazione e codice lato server non familiare meritano un’indagine.
Un aggressore che abbia avuto successo potrebbe modificare più della configurazione HFS visibile. L’esecuzione remota di codice può consentire persistenza tramite account del sistema operativo, attività pianificate, script di avvio o servizi aggiuntivi.
Per questo motivo, applicare una patch a un host confermatamente compromesso non è sufficiente. Chi gestisce la risposta dovrebbe isolarlo, preservare le prove, ruotare le credenziali pertinenti, valutare le risorse connesse e ricostruire il sistema quando non sia possibile stabilirne l’integrità.
Le implicazioni difensive vanno oltre HFS. Gli sviluppatori dovrebbero considerare i generatori pseudocasuali general-purpose fonti inaccettabili per segreti di autenticazione, token di reset, nonce crittografici e identificatori di sessione.
La revisione del codice dovrebbe esaminare le relazioni tra stati condivisi, non solo le singole chiamate. Un segreto sicuro può comunque diventare prevedibile se lo stesso generatore espone altrove output correlati.
Le impostazioni predefinite dei framework richiedono un esame analogo. Talvolta gli sviluppatori presumono che una libreria renda sicuro un input non sicuro. Un framework di firma può proteggere l’integrità dei cookie solo se la chiave di firma fornita rimane segreta e imprevedibile.
L’analisi assistita dall’AI è adatta a seguire queste relazioni tra file diversi. I modelli possono cercare siti di chiamata, tracciare il flusso dei dati, confrontare il comportamento dei framework e verificare se una debolezza teorica raggiunge un’operazione privilegiata.
Questo vantaggio non elimina la necessità di una validazione umana. Un exploit generato può interpretare erroneamente una versione, omettere un presupposto ambientale o dimostrare un comportamento che non si generalizza oltre un ambiente di test.
Il flusso di lavoro più solido combina la scalabilità delle macchine con una revisione responsabile. L’AI propone e testa catene di attacco, mentre ricercatori esperti riproducono il risultato, valutano la gravità, coordinano la remediation e controllano la divulgazione.
Cosa non dimostra l’exploit Mythos HFS
Una catena di exploit riuscita mostra una capacità significativa, ma non dimostra che Mythos troverà in modo affidabile ogni vulnerabilità critica.
Il rapporto di Horizon3 è un caso di studio prodotto da un’organizzazione che partecipa al Project Glasswing di Anthropic. I ricercatori hanno utilizzato un harness personalizzato che eseguiva agenti specializzati in parallelo sull’intera base di codice HFS.
Questo contesto è importante. Il risultato non rappresenta un chatbot consumer privo di assistenza, a cui viene fornito un repository e che compromette istantaneamente il sistema.
L’harness ha modellato l’indagine assegnando agli agenti classi specifiche di vulnerabilità. I ricercatori umani hanno inoltre selezionato il bersaglio, esaminato i risultati e gestito la divulgazione responsabile.
Ciononostante, Mythos sembra aver contribuito con più del semplice completamento automatico o di una checklist di sicurezza generica. Secondo i ricercatori, ha collegato autonomamente il PRNG debole, la perdita di output, il formato della sessione, la ricostruzione retrograda dello stato e la funzione di esecuzione del codice amministrativo.
Le prove pubblicate supportano la scoperta relativa a HFS perché un exploit funzionante ha dimostrato la catena. Forniscono meno informazioni su falsi positivi, capacità di calcolo complessiva, esecuzioni non riuscite e risultati scartati durante l’analisi più ampia.
Questi denominatori mancanti limitano i confronti generali di produttività. Un modello che trova una vulnerabilità eccezionale dopo molti tentativi costosi presenta una proposta operativa diversa da uno che riesce con costanza.
Il caso non dimostra inoltre che l’AI da sola abbia causato lo sfruttamento rapido. Gli aggressori si muovono da tempo rapidamente dopo che codice proof-of-concept e analisi tecniche diventano pubblici.
Scanner convenzionali, strumenti di diffing, framework di exploit e reverse engineering umano supportano già questo flusso di lavoro. L’AI aggiunge velocità e accessibilità, ma si inserisce in una toolchain offensiva già esistente.
Né una localizzazione della sorgente stabilisce l’attribuzione. Gli attacchi segnalati hanno utilizzato infrastrutture in Cina e negli Stati Uniti, ma proxy e host compromessi oscurano regolarmente la posizione dell’operatore.
Le affermazioni su una campagna sponsorizzata da uno Stato richiederebbero ulteriori prove, incluse sovrapposizioni di strumenti, cronologia dell’infrastruttura, selezione delle vittime e comportamento dopo l’accesso.
Esiste inoltre incertezza sulla portata dello sfruttamento riuscito. Le informazioni pubblicate descrivevano un numero ridotto di richieste rilevate contro sistemi vulnerabili reali.
Questo è sufficiente a giustificare un patching urgente. Non è sufficiente per stimare un conteggio globale delle infezioni o affermare l’esistenza di una campagna diffusa.
I difensori dovrebbero resistere a entrambi gli estremi. Liquidare Mythos come marketing ignora un exploit convalidato e tecnicamente interessante. Trattare un singolo caso come prova di hacking autonomo universale esagera ciò che le prove pubbliche supportano.
La conclusione equilibrata è più circoscritta, ma comunque importante. Un sistema di ricerca assistito dall’AI ha aiutato specialisti a trasformare un sottile errore di progettazione crittografica in un exploit end-to-end che ha raggiunto l’esecuzione remota di codice.
Questa capacità amplia il tipo di risultati che i ricercatori possono perseguire economicamente. Aumenta inoltre il valore della riduzione del ritardo tra la disponibilità di una patch e la sua distribuzione verificata.
Tre segnali mostreranno se i difensori riescono a tenere il passo
Il prossimo test è stabilire se lo sfruttamento si espande, l’adozione delle patch migliora e le divulgazioni generate dall’AI restano gestibili per i manutentori del software.
Il primo segnale è la portata degli attacchi osservati. Più indirizzi sorgente, varianti di exploit, payload post-compromissione o organizzazioni coinvolte rafforzerebbero la conclusione che CVE-2026-61500 sia andata oltre i test opportunistici.
Un continuo ma limitato flusso di semplici sonde supporterebbe un’interpretazione più ristretta. Suggerirebbe che gli aggressori stanno sperimentando la tecnica pubblica senza aver ancora costruito una campagna sostenuta.
Il secondo segnale è se gli operatori di Rejetto HFS rimuovano davvero le versioni vulnerabili. Le misurazioni su internet e i rapporti sugli incidenti possono rivelare se installazioni che eseguono versioni dalla 3.0.0 alla 3.2.0 persistano dopo la diffusione degli avvisi.
Un rapido calo mostrerebbe che manutentori, fornitori di sicurezza e amministratori hanno trasformato la divulgazione in azione. Un’esposizione prolungata confermerebbe che inventario e distribuzione restano i fattori limitanti.
Il terzo segnale è la qualità e il volume delle successive divulgazioni del Project Glasswing. Anthropic afferma che le segnalazioni di vulnerabilità generate dall’AI ricevono una revisione umana e una gestione coordinata prima della pubblicazione.
Un flusso costante di risultati riproducibili e ad alto impatto sosterrebbe l’argomento secondo cui Mythos modifica l’economia della ricerca. Un’ondata di segnalazioni di basso valore graverebbe invece sui manutentori open source e indebolirebbe la fiducia nel processo.
Questa è la conseguenza più ampia della vulnerabilità Anthropic Mythos HFS. Una scoperta migliore genera valore difensivo solo quando i manutentori possono assorbire le segnalazioni e gli utenti distribuiscono le correzioni risultanti.
I team di sicurezza dovrebbero aggiornare ora i server HFS interessati, verificare la versione distribuita, limitare l’esposizione non necessaria e indagare sulle attività sospette dopo il 30 settembre. Poi dovrebbero porsi una domanda più difficile: se il prossimo exploit assistito dall’AI arrivasse con la stessa timeline compressa, il loro inventario delle risorse potrebbe fornire una risposta prima degli aggressori?
