Polygon ha divulgato una serie di vulnerabilità di sicurezza già corrette tramite i recenti aggiornamenti di rete, presentando la mossa come un passo verso la trasparenza, pur riconoscendo che i bug sottostanti rappresentavano un rischio reale prima del deployment delle correzioni. La divulgazione evidenzia una tensione ricorrente intorno ai problemi di sicurezza di Polygon: da un lato la rapida correzione, dall'altro il ritardo nei dettagli resi pubblici. Questa tensione non è esclusiva di Polygon — il coordinated disclosure, in cui le patch vengono rilasciate prima che i dettagli diventino pubblici affinché gli aggressori non possano sfruttare bug noti contro reti non aggiornate, è una prassi standard nel settore blockchain, ma lascia sempre una finestra in cui gli utenti non possono valutare il rischio che stanno sostenendo.

Secondo il resoconto ufficiale di Polygon sul recente aggiornamento di rete, le vulnerabilità sono state affrontate a livello di protocollo anziché tramite azioni lato utente. Il percorso di aggiornamento ha riguardato il client Bor che produce i blocchi sulla rete, il che significa che la correzione è stata implementata nel software dei nodi principali anziché nei singoli smart contract. Bor è il componente responsabile della produzione dei blocchi di Polygon PoS, una delle reti di scaling di Ethereum più utilizzate, quindi una vulnerabilità a quel livello coinvolge la catena stessa e non una singola applicazione costruita sopra di essa.

Il problema più grave mai divulgato da Polygon è stata una vulnerabilità a livello genesi che, secondo quanto riportato, metteva a rischio circa 9 miliardi di dollari in MATIC prima di essere corretta. Questa inquadratura sottolinea la gravità del caso: l'esposizione riguardava i saldi a livello di rete, non semplicemente la disponibilità del servizio o una singola applicazione. Hacker white-hat avevano infatti sfruttato una vulnerabilità correlata su Polygon PoS nel dicembre 2021, sottraendo oltre 800.000 MATIC prima che la patch entrasse in funzione — un episodio che ha contribuito a consolidare la pratica della divulgazione finanziata da bounty sulla rete.

Cosa hanno effettivamente cambiato gli hard fork

La correzione è stata distribuita come aggiornamento coordinato del client Bor anziché come migrazione di contract, come descritto nel thread dell'aggiornamento mainnet v0.2.12 di Polygon. Poiché la modifica si attivava a un'altezza di blocco specifica, validatori e operatori di nodi hanno dovuto aggiornare il proprio software affinché la correzione avesse effetto.

Questa dipendenza dall'azione degli operatori è il punto critico pratico. Un hard fork chiude la vulnerabilità solo quando una supermaggioranza di validatori esegue il client corretto, il che rende l'aggiornamento tanto una prova del coordinamento di Polygon quanto del suo codice.

Anche ricercatori indipendenti hanno fatto parte del processo. Il ricercatore di sicurezza Nathan Worsley ha pubblicamente menzionato lavori legati alla vulnerabilità sul suo account X, uno dei segnali esterni che il difetto era abbastanza serio da giustificare una risposta di emergenza anziché un rilascio ordinario.

Il bounty e cosa segnala

La divulgazione di Polygon si accompagna a uno dei pagamenti più consistenti nella storia dell'ecosistema. Una recensione del bug fix documenta un bounty di 2,2 milioni di dollari legato a una verifica del saldo mancante, una classe di bug che può consentire di muovere valore senza che i fondi corrispondenti esistano realmente. Il pagamento è stato gestito tramite Immunefi, la piattaforma di bug bounty che molti dei principali progetti crypto utilizzano per instradare le segnalazioni di vulnerabilità ai team prima che i dettagli diventino pubblici.

Lo scenario ottimista è semplice: un bounty pagato, un client corretto e un resoconto pubblico sono i meccanismi di un processo di divulgazione funzionante che opera come previsto. Lo scenario critico è che i dettagli sono arrivati a posteriori, e la divulgazione ritardata resta rilevante perché gli utenti che hanno effettuato transazioni durante la finestra di esposizione non hanno potuto valutare un rischio di cui non conoscevano l'esistenza.

Cosa devono monitorare utenti e sviluppatori

Per gli utenti ordinari non è richiesta alcuna azione una volta che i validatori hanno adottato il software corretto, poiché la modifica risiede nel livello dei nodi e non nei wallet o nelle approvazioni. Gli exchange tendono a seguire direttamente questi aggiornamenti, come nel caso in cui Bybit ha supportato un successivo aggiornamento di rete di Polygon, spesso il segnale più chiaro che un aggiornamento è stato completato a livello operativo. Gli sviluppatori che distribuiscono su Polygon affrontano una dinamica simile: i propri contract richiedono comunque audit indipendenti, poiché le patch a livello di client non sostituiscono la sicurezza a livello applicativo.

Le questioni aperte riguardano la completezza. Il materiale pubblico di Polygon conferma che le correzioni sono state rilasciate, ma il documento a supporto di questo resoconto non stabilisce una cronologia completa di quando ciascuna vulnerabilità è stata individuata rispetto a quando è stata divulgata, e tale lacuna resta l'elemento che i lettori fanno bene a continuare a monitorare.

Disclaimer: questo articolo ha finalità puramente informative e non costituisce consulenza finanziaria o di investimento. I mercati delle criptovalute e degli asset digitali comportano rischi significativi. Fai sempre le tue ricerche prima di prendere decisioni.