I diff delle patch sono ormai mappe d'attacco, e il modello open-weight GLM 5.3 lo mostra

E se il documento più pericoloso dell'open source non fosse un rapporto su una vulnerabilità, ma la correzione che la risolve? È l'idea scomoda alla base di un nuovo esperimento: una patch pubblica, ferma in un repository, può ora essere letta e trasformata in un'arma da un modello che, secondo Epoch AI, costa circa 1.000 $ per exploit.

Un modello da 1.000 $ ha trasformato correzioni pubbliche in exploit

Secondo il rapporto di Epoch AI, GLM 5.3, un modello open-weight rilasciato da Z.ai in agosto, è in grado di individuare e sfruttare vulnerabilità nelle versioni recenti di Firefox usando correzioni di sicurezza pubblicate ma non ancora distribuite agli utenti. Questa finestra si chiama patch gap. I ricercatori dicono di aver progettato l'esperimento per imitare un hacker poco sofisticato e con risorse limitate, usando solo le informazioni disponibili al momento del rilascio di ciascuna versione.

I risultati riportati: catene di exploit contro sei versioni recenti di Firefox, a circa 1.000 $ ciascuna e senza alcun rifiuto da parte del modello, secondo coperture di seconda mano come explainx.ai. Nel frattempo Mozilla ha corretto una falla collegata. Va precisato che ci basiamo sul resoconto della stessa Epoch e su sintesi giornalistiche, e che non abbiamo visto repliche indipendenti.

La patch è il rapporto sulla vulnerabilità

L'open source funziona da tempo su un patto: correggere in pubblico, perché la trasparenza crea fiducia e permette a molti occhi di rivedere la modifica. Quel patto presupponeva che trasformare una patch in un exploit affidabile tramite reverse engineering richiedesse abilità, tempo e pazienza. Esperti in carne e ossa ci riuscivano, ma probabilmente non su larga scala.

Se un modello può farlo a 1.000 $ a botta, i conti si ribaltano. Un messaggio di commit come «fix out-of-bounds write» non è più un appunto per i colleghi: è un'indicazione di dove si nasconde il bug. A nostro avviso, la risorsa scarsa non è mai stata la vulnerabilità, ma l'attenzione dell'attaccante, ed è proprio ciò che i modelli linguistici rendono economico.

Questo penalizza anche i più diligenti. I progetti che committano le correzioni in fretta e in modo aperto creano lo scarto tra il fix visibile e il fix consegnato. Più si lavora in fretta alla luce del sole, più a lungo il bersaglio resta illuminato, a meno che la distribuzione non tenga il passo.

Dare la colpa ai pesi aperti significa mancare il vero problema

È facile trasformare tutto questo in una storia sui modelli open-weight. Pensiamo che sia il bersaglio sbagliato. Il dettaglio riportato, cioè che il modello non abbia mai rifiutato, merita attenzione, ma un modello chiuso con solide protezioni cambierebbe probabilmente solo chi ottiene per primo la capacità e con che facilità la si può aggirare. Il problema di fondo è la struttura della divulgazione, non la licenza del modello.

Vietare o limitare i pesi non chiuderebbe il patch gap. Che cosa lo farebbe? Finestre più brevi. Processi di rilascio in cui il commit pubblico e l'aggiornamento per l'utente arrivano insieme. Correzioni sotto embargo che restano in branch privati finché le build non sono pronte. Messaggi di commit meno descrittivi, anche se su questo punto siamo scettici: un modello che legge i diff del codice non ha bisogno del messaggio di commit per trovare la modifica.

Non tutti i progetti possono farlo. I grandi fornitori, con aggiornamenti automatici e cicli di rilascio serrati, possono ridurre la finestra. Una libreria gestita da volontari no. È in questa asimmetria che ci aspettiamo il danno vero: la lunga coda del software che corregge in pubblico e si aggiorna lentamente.

I maintainer dovrebbero distribuire prima e spiegare dopo

Per i maintainer la raccomandazione è netta: considerate il momento in cui una correzione diventa visibile come il momento in cui un exploit può esistere. Misurate la vostra finestra in ore, non in settimane, e valutate di trattenere i commit di sicurezza finché il rilascio non è pronto per la distribuzione. La trasparenza può arrivare subito dopo la consegna anziché prima.

Per tutti gli altri il consiglio è noioso e più urgente che mai: attiva gli aggiornamenti automatici e riavvia il browser quando te lo chiede. Il costo del ritardo è appena diventato misurabile in dollari.

Una precisazione. Si tratta di un singolo esperimento incentrato su Firefox, e una sintesi riferisce che Chrome ha retto, quindi non dobbiamo estrapolare a tutto il software. Ma la direzione sembra abbastanza chiara. I diff delle patch un tempo erano documentazione. Ora sembrano una mappa, e l'unica risposta sensata è smettere di lasciare la mappa in giro prima che la strada sia asfaltata.