Polygon publicou detalhes de múltiplas vulnerabilidades de segurança anteriormente não divulgadas que poderiam ter afetado sua infraestrutura de proof-of-stake (PoS), incluindo problemas que abrangem risco de negação de serviço entre nodes e gargalos no processamento de validadores. Polygon disse que os problemas foram resolvidos antes da divulgação pública por meio de dois forks recentes e atualizações correspondentes dos clientes.
Em uma postagem de quinta-feira no fórum da Polygon, a Equipe de Suporte a Validadores da Polygon Labs detalhou como falhas nos clientes Bor e Heimdall foram corrigidas por meio das forks Austin e Kyoto. A divulgação também observa que nenhuma das vulnerabilidades foi observada sendo explorada no mainnet da Polygon.
Principais conclusões
- Polygon revelou vulnerabilidades afetando ambos os clientes Bor e Heimdall, com potencial para negação de serviço e interrupção no processamento de validadores.
- Os problemas foram resolvidos por meio das forks de Austin (Bor) e Kyoto (Heimdall), que foram testadas antes da ativação.
- Polygon afirmou que nenhuma exploração foi observada no mainnet, e as atualizações foram implantadas proativamente antes que os detalhes se tornassem públicos.
- Executar versões desatualizadas do cliente após as alturas de ativação do fork significa que os nodes perderão o consenso e deverão ser atualizados para retornar.
- Polygon exige Bor v2.10.0 para nós PoS e Heimdall v0.11.0 para validadores e nós completos.
O que a Polygon revelou sobre o cliente Bor
De acordo com a divulgação da Polygon, o fork Austin resolveu dois riscos relacionados a negação de serviço associados ao cliente Bor. Falhas de negação de serviço em clientes de blockchain são particularmente preocupantes porque podem degradar o desempenho aumentando o consumo de recursos durante o processamento de blocos e, em casos graves, podem contribuir para a instabilidade dos nós.
A Polygon afirmou que esses problemas do Bor poderiam ter impactado o processamento de blocos ou causado falhas nos nodes, dependendo de como um atacante pudesse ter ativado o comportamento problemático. A Polygon não afirmou que as vulnerabilidades foram exploradas no ambiente real, mas enfatizou que as correções foram implementadas antes do lançamento público dos detalhes técnicos.
A vulnerabilidade Heimdall que poderia sobrecarregar o processamento de validadores
A divulgação destacou um problema mais grave que afeta o cliente Heimdall. A Polygon afirmou que uma transação especialmente criada poderia forçar validadores a realizar um trabalho de processamento excessivo. Em um ambiente PoS, qualquer coisa que cause carga de trabalho desproporcional aos validadores pode se tornar um problema de confiabilidade da rede, pois os validadores devem processar dados relacionados ao consenso dentro de limites de desempenho práticos.
A Polygon descreveu a falha do Heimdall como uma que poderia potencialmente interromper a operação da rede, empurrando validadores para um caminho de processamento ineficiente ou excessivamente oneroso. O problema foi resolvido por meio do hard fork Kyoto, com atualizações correspondentes implementadas antes da divulgação pública da informação.
Mecânica do fork e por que as atualizações são importantes
A divulgação da Polygon é explícita quanto às consequências operacionais para os participantes que não atualizarem. Nodes que executam versões mais antigas do Bor ou Heimdall após as alturas de ativação do hard fork relevante são descritos como fora de consenso e precisam ser atualizados para retornar à rede canônica.
Polygon afirmou que o Bor v2.10.0 é necessário para todos os nós Polygon PoS, e o Heimdall v0.11.0 é necessário para validadores e nós completos. Ambas as atualizações já estão ativas no mainnet.
Para operadores de infraestrutura, isso significa que a preparação de segurança também é um requisito de disponibilidade: mesmo que um node não seja diretamente afetado por um cenário de ataque, software desatualizado ainda pode tornar-se incapaz de participar do consenso após alterações no protocolo. Na prática, a lição operacional é confirmar que as versões dos clientes estão alinhadas com os requisitos pós-fork e que há monitoramento em vigor para detectar atualizações perdidas.
Nenhuma evidência de exploração do mainnet, mas um lembrete sobre a aplicação proativa de patches
A Polygon afirmou que nenhuma das vulnerabilidades descritas na divulgação foi observada sendo explorada no mainnet. A empresa também caracterizou as correções como proativas—implementadas por meio de hard forks e atualizações de clientes antes do lançamento das informações detalhadas sobre as vulnerabilidades.
Essa abordagem é importante porque reduz a janela na qual atacantes do mundo real poderiam tentar explorar vulnerabilidades conhecidas. No entanto, também eleva o nível exigido para manutenção contínua: mesmo quando a superfície de ataque é corrigida por meio de atualizações, os participantes ainda precisam acompanhar as mudanças nas versões do protocolo e do cliente para manter a conectividade e a participação no consenso.
No momento da escrita, o token nativo da Polygon (POL)—anteriormente conhecido como MATIC—estava negociado em torno de US$ 0,10. Os dados da CoinGecko mostram que estava 4% abaixo na semana anterior, 44% acima no último mês e 2,3% acima no ano até a data, segundo as estatísticas de preço da CoinGecko.
Os leitores devem ficar atentos às confirmações operacionais dos validadores e operadores de node de que suas atualizações Heimdall e Bor permanecem estáveis pós-fork. A próxima pergunta prática é se a Polygon publicará detalhes adicionais ou orientações sobre práticas de mitigação além das atualizações de versão obrigatórias — especialmente considerando que vulnerabilidades de negação de serviço e carga de trabalho de validador podem ser sensíveis a mudanças na implementação e limiares de monitoramento.
Este artigo foi originalmente publicado como Polygon Reports Security Flaws Patched in Latest Hard Forks em Crypto Breaking News – sua fonte confiável para notícias de criptomoedas, notícias de Bitcoin e atualizações de blockchain.