Polygon revela vulnerabilidades de seguridad corregidas mediante los hard forks Austin y Kyoto
Puntos clave
- •Polygon divulgó las vulnerabilidades en sus clientes Bor y Heimdall solo después de implementar correcciones mediante los hard forks Austin y Kyoto, siguiendo un enfoque de divulgación coordinada.
- •La falla más grave afectaba a Heimdall, donde una transacción especialmente manipulada podría haber obligado a los validadores a un procesamiento excesivo y haber interrumpido las operaciones de la red.
- •El hard fork Austin resolvió dos riesgos de denegación de servicio distintos en Bor que podrían haber ralentizado el procesamiento de bloques o bloqueado nodos.
- •Polygon afirmó que no hay evidencia de que las vulnerabilidades hayan sido explotadas en mainnet.
- •Los nodos con clientes desactualizados deben actualizar a Bor v2.10.0 y Heimdall v0.11.0, ya que las versiones antiguas quedaron fuera de consenso.

Polygon reveló públicamente un conjunto de vulnerabilidades de seguridad que antes eran privadas y que podrían haber afectado su red de prueba de participación (proof-of-stake). La empresa dio a conocer las fallas solo después de implementar correcciones mediante los hard forks Austin y Kyoto.
Las vulnerabilidades afectaban a los clientes Bor y Heimdall de Polygon e incluían riesgos de denegación de servicio, agotamiento de recursos de los validadores y debilidades en el procesamiento de checkpoints y milestones. Polygon afirmó que no encontró evidencia de que las fallas hayan sido explotadas en mainnet. Bor es el cliente de ejecución encargado de producir bloques en Polygon PoS, mientras que Heimdall gestiona los checkpoints y la coordinación de validadores, por lo que fallas en cualquiera de estos componentes repercuten directamente en la forma en que la cadena alcanza y registra el consenso.
Correcciones implementadas antes de la divulgación
Polygon corrigió las vulnerabilidades antes de publicar sus detalles técnicos. Este enfoque permitió a los desarrolladores probar las correcciones y activarlas sin advertir de antemano a posibles atacantes. Sigue el modelo de divulgación coordinada ampliamente utilizado en la industria del software y por grandes proyectos de blockchain, en el que los detalles técnicos se retienen hasta que los parches estén ampliamente implementados, de modo que los hallazgos de los investigadores no se conviertan en planos de ataque.
El problema más grave afectaba a Heimdall, donde una transacción especialmente manipulada podía obligar a los validadores a realizar un trabajo de procesamiento excesivo. Esa actividad podría haber ejercido una presión significativa sobre los validadores y, potencialmente, haber interrumpido las operaciones de la red.
El hard fork Austin resolvió dos riesgos de denegación de servicio distintos en Bor. Estas fallas podrían haber ralentizado el procesamiento de bloques o provocado el bloqueo de los nodos afectados.
Polygon señaló que las actualizaciones fueron probadas antes de su activación en mainnet, y que la divulgación se realizó solo después de que las correcciones se implementaran con éxito, reduciendo el riesgo de que los detalles públicos de las vulnerabilidades se usaran contra nodos sin parchear. No es la primera vez que Polygon gestiona fallas críticas de forma discreta antes de revelarlas: el proyecto ya había divulgado un error crítico corregido en Bor solo después de que la corrección estuviera activa en mainnet, lo que establece un patrón de seguridad de "primero parchar, luego divulgar".
Los operadores de nodos enfrentan una actualización obligatoria
Los hard forks también generaron un requisito inmediato para los operadores de nodos. Los nodos que ejecutan versiones antiguas de los clientes después de las alturas de activación correspondientes quedaron fuera de consenso y deben actualizarse para reconectarse a la red canónica de Polygon.
Polygon exige Bor v2.10.0 para los nodos de Polygon PoS, mientras que los validadores y nodos completos también deben ejecutar Heimdall v0.11.0. Ambas versiones ya están activas en mainnet.
La divulgación subraya la importancia de las respuestas de seguridad coordinadas para las redes blockchain. Aunque en este caso Polygon evitó una explotación confirmada en mainnet, las vulnerabilidades podrían haber amenazado la disponibilidad de la red si los atacantes las hubieran descubierto y explotado primero.
Por lo tanto, las actualizaciones Austin y Kyoto cumplieron un doble propósito: como parches de seguridad y como pasos críticos de mantenimiento para la infraestructura de validadores de Polygon. Para los operadores de nodos y proveedores de infraestructura, casos como este son un recordatorio de seguir de cerca las notas de versión de los clientes y las alturas de activación, ya que perderse un hard fork obligatorio implica la desconexión inmediata del consenso y no un nodo degradado pero funcional.