Vulnerabilidades da Polygon foram corrigidas antes de qualquer exploração

A Polygon divulgou nesta semana um conjunto de vulnerabilidades de segurança que havia mantido em sigilo até aplicar as correções na rede. As falhas foram fechadas por dois hard forks coordenados nos clientes do Polygon Proof of Stake, o Bor e o Heimdall.

A divulgação partiu do time de suporte a validadores da Polygon Labs e listou fraquezas que iam de queda de disponibilidade a consumo excessivo de recursos dos validadores, passando por erros em checkpoints e milestones. São os pontos em que a rede depende de que cada operador esteja rodando o mesmo software, e é justamente aí que uma política de correção se torna uma decisão de infraestrutura.

O caso mais severo ficou no Heimdall, cliente responsável pelo consenso da camada de staking da rede. Foi nele que a análise encontrou o caminho de ataque de maior alcance, justamente por concentrar o trabalho de validar e ancorar os checkpoints na Ethereum.

O que o hard fork Kyoto corrigiu no Heimdall

Uma transação desenhada de propósito podia forçar cada validador a despender muita decodificação de uma vez só, em um desequilíbrio barato de produzir e caro de processar para toda a rede.

A raiz da falha estava na forma como o Heimdall empacota as mensagens internas das transações, usando um tipo de dados que permite aninhamento sem limite de profundidade. O hard fork incorporou um exame em escala de byte que barra a transação quando o aninhamento ultrapassa um certo ponto, aplicado tanto na entrada da mempool quanto na execução do bloco.

O outro front estava no Bor, o software que roda as transações do Polygon PoS, e o hard fork Austin eliminou dois pontos que permitiam travar o processamento de blocos.

O que o hard fork Austin corrigiu no Bor

O primeiro ponto estava no gás dos eventos de state-sync, que rodam código de contrato e precompiles vindos dos depósitos da ponte, sem teto por bloco. Um bloco com eventos suficientes, ou um evento caro demais, podia atrasar o processamento a ponto de travar a cadeia.

O segundo problema estava no campo TxDependency, um aviso de execução paralela que o produtor de bloco anexava aos blocos sem teto de tamanho. Um produtor podia enfiar um blob excessivamente grande em um bloco válido, e qualquer nó que tentasse processá-lo cairia. O hard fork tirou o campo do formato de transmissão sem afetar a execução paralela, que não depende dessa pista externa para funcionar.

Os dois hard forks foram primeiro distribuídos de forma privada e validados na rede de testes Amoy antes de subirem na mainnet.

O Austin ativou no bloco 91.949.700 da mainnet e no 44.120.000 da Amoy. O Kyoto, que atualiza o Heimdall para a versão 0.11.0, foi ativado na altura 51.533.000 em 18 de agosto, às 10h10 UTC.

A Polygon afirmou que nenhuma das vulnerabilidades foi explorada na mainnet e que as correções foram aplicadas de forma proativa, antes de qualquer detalhe virar público. O sigilo das versões corrigidas é parte do método, já que uma falha que afeta o consenso exige atualização coordenada para não expor a brecha a quem ainda não tinha conhecimento dela.

O efeito prático para quem opera nós já apareceu. Nós rodando versões anteriores aos hard forks, além das alturas de ativação, saíram do consenso da rede e precisam atualizar para voltar a seguir a história canônica da chain.

Na prática, operadores que passaram do ponto de ativação em uma versão antiga precisam puxar a release aplicável, recuar a um marco anterior ao hard fork quando necessário e fazer nova sincronização seguindo as instruções da Polygon. Os dois hard forks são atualizações simples de binário, sem migração de estado nem mudança de gênese, e nós que não divergiram não exigem nova sincronização.

A versão 2.10.0 do Bor é obrigatória para todos os nós do Polygon PoS, enquanto a 0.11.0 do Heimdall vale para validadores e nós completos. O software corrigido já está ativo na mainnet.

O caso se junta a outros movimentos recentes de atualização coordenada em protocolos, em que redes preferem corrigir em silêncio e divulgar depois do que expor uma brecha com a rede ainda vulnerável. A decisão transfere o custo do risco para o processo, e o acerto depende de quanto cada operador responde ao chamado de atualização.

O token da rede, o POL, que antes atendia pelo ticker MATIC, negocia ao redor de US$ 0,10, com queda de 3,4% na semana, mas alta de 42,8% no mês.

Para o mercado, a lição vai além do código. Atualizações coordenadas que saem de forma silenciosa e depois são reveladas mostram que a segurança de uma rede de staking depende tanto de um patch correto quanto da prontidão da base instalada de operadores em subir a nova versão, e é esse segundo fator que define se a janela entre a correção e a divulgação vira um incidente ou apenas um comunicado técnico.