Polygon rivela vulnerabilità di sicurezza risolte tramite gli hard fork Austin e Kyoto
Punti chiave
- •Polygon ha divulgato le vulnerabilità nei suoi client Bor e Heimdall solo dopo aver distribuito le correzioni tramite gli hard fork Austin e Kyoto, seguendo un approccio di divulgazione coordinata.
- •La falla più grave riguardava Heimdall, dove una transazione appositamente costruita avrebbe potuto costringere i validatori a un'elaborazione eccessiva e interrompere le operazioni di rete.
- •L'hard fork Austin ha risolto due distinti rischi di denial-of-service in Bor che avrebbero potuto rallentare l'elaborazione dei blocchi o causare il crash dei nodi.
- •Polygon ha dichiarato che non ci sono prove che le vulnerabilità siano state sfruttate sulla mainnet.
- •I nodi con client obsoleti devono aggiornare a Bor v2.10.0 e Heimdall v0.11.0, poiché le versioni più vecchie sono uscite dal consenso.

Polygon ha divulgato pubblicamente un insieme di vulnerabilità di sicurezza precedentemente riservate che avrebbero potuto compromettere la sua rete proof-of-stake. L'azienda ha rivelato le falle solo dopo aver distribuito le correzioni tramite gli hard fork Austin e Kyoto.
Le vulnerabilità interessavano i client Bor e Heimdall di Polygon e includevano rischi di attacchi denial-of-service, esaurimento delle risorse dei validatori e debolezze nell'elaborazione di checkpoint e milestone. Polygon ha dichiarato di non aver trovato prove che le falle siano state sfruttate sulla mainnet. Bor funge da client di esecuzione per la produzione di blocchi di Polygon PoS, mentre Heimdall gestisce il checkpointing e il coordinamento dei validatori, quindi le falle in ciascun componente influiscono direttamente sul modo in cui la chain raggiunge e registra il consenso.
Correzioni distribuite prima della divulgazione
Polygon ha risolto le vulnerabilità prima di renderne pubblici i dettagli tecnici. Questo approccio ha consentito agli sviluppatori di testare le correzioni e attivarle senza dare preavviso a potenziali attaccanti. Si tratta del modello di divulgazione coordinata ampiamente utilizzato nel settore software e dai principali progetti blockchain, in cui i dettagli tecnici vengono trattenuti finché le patch non sono ampiamente distribuite, così che le scoperte dei ricercatori non diventino blueprint per attacchi.
Il problema più grave riguardava Heimdall, dove una transazione appositamente costruita avrebbe potuto costringere i validatori a eseguire un lavoro di elaborazione eccessivo. Un'attività del genere avrebbe potuto esercitare una pressione significativa sui validatori e potenzialmente interrompere le operazioni di rete.
L'hard fork Austin ha risolto due distinti rischi di denial-of-service in Bor. Queste falle avrebbero potuto rallentare l'elaborazione dei blocchi o causare il crash dei nodi interessati.
Polygon ha dichiarato che gli aggiornamenti sono stati testati prima dell'attivazione sulla mainnet e che la divulgazione è avvenuta solo dopo la distribuzione riuscita delle correzioni, riducendo il rischio che i dettagli pubblici delle vulnerabilità potessero essere usati contro nodi non patchati. Non è la prima volta che Polygon gestisce in silenzio falle critiche prima di rivelarle: il progetto aveva in passato divulgato un bug critico già corretto in Bor solo dopo che la correzione era attiva sulla mainnet, consolidando uno schema di sicurezza basato sul principio «prima la patch, poi la divulgazione».
I gestori di nodi devono effettuare un aggiornamento obbligatorio
Gli hard fork hanno inoltre creato un requisito immediato per i gestori di nodi. I nodi che eseguono versioni client più vecchie oltre le relative altezze di attivazione sono usciti dal consenso e devono aggiornarsi per ricollegarsi alla rete canonica di Polygon.
Polygon richiede Bor v2.10.0 per i nodi Polygon PoS, mentre validatori e full node devono eseguire anche Heimdall v0.11.0. Entrambe le versioni sono già attive sulla mainnet.
La divulgazione sottolinea l'importanza di risposte di sicurezza coordinate per le reti blockchain. Sebbene in questo caso Polygon abbia evitato uno sfruttamento confermato sulla mainnet, le vulnerabilità avrebbero potuto minacciare la disponibilità della rete se gli attaccanti le avessero scoperte e sfruttate per primi.
Gli aggiornamenti Austin e Kyoto hanno quindi svolto una doppia funzione: come patch di sicurezza e come passaggi di manutenzione critica per l'infrastruttura dei validatori di Polygon. Per i gestori di nodi e i fornitori di infrastrutture, casi come questo ricordano di monitorare attentamente le note di rilascio dei client e le altezze di attivazione, poiché mancare un hard fork obbligatorio comporta la disconnessione immediata dal consenso anziché un nodo degradato ma funzionante.