Operadores de nós do Ethereum Classic foram instados a evitar a disputada versão Core Geth v1.13.0 depois que vários nós de pools de mineração adotaram brevemente o software antes de retornar ao cliente Argos mantido.
Resumo
- Vários nós de pools de mineração do Ethereum Classic migraram brevemente para a disputada versão Core Geth v1.13.0 antes de retornar ao Argos v1.12.23.
- A Classix afirmou que 96 commits foram enviados em 56 horas sem revisão externa antes de a v1.13.0 ser lançada e promovida como uma atualização de segurança.
- O cliente disputado reativou o MESS e alterou a infraestrutura de descoberta de nós, enquanto a Classix disse que nenhum bloco, fundo ou serviço foi afetado pelo incidente.
- A Classix instou os operadores a evitar a v1.13.0 e pediu aos administradores do GitHub do Ethereum Classic que reforçassem os controles de repositório e revisão.
A Classix disse em um relatório de incidente de 16 de setembro que o repositório ethereumclassic/core-geth lançou a v1.13.0 em 14 de setembro antes que a conta @ETC_Network a promovesse como uma atualização de segurança do Ethereum Classic e instruísse os operadores de nós a migrar. Mensagens semelhantes apareceram no CoinMarketCap, enquanto pools de mineração receberam e-mails de um endereço ethereumclassic.com.
O relatório descreveu o lançamento como uma versão desonesta porque os mantenedores existentes do Core Geth não a revisaram e o repositório mantido etclabscore/core-geth não emitiu a atualização. A Classix recomendou que os operadores continuassem usando o Argos v1.12.23, a versão atual do repositório que mantém o Core Geth desde 2020.
Lançamento desonesto do Core Geth alcançou alguns nós de mineração do ETC
O desenvolvimento da versão disputada acelerou durante os dias anteriores ao seu lançamento. De acordo com a Classix, 96 commits contendo 13.422 linhas adicionadas e 3.977 linhas excluídas foram enviados em 56 horas diretamente para o branch principal do fork sem pull requests ou revisão externa.
O próprio repositório ethereumclassic/core-geth havia sido bifurcado do etclabscore/core-geth em dezembro de 2024. A atividade aumentou em 12 de setembro de 2026, quando a v1.13.0-rc1 foi marcada. Mais seis candidatos a lançamento se seguiram antes que a v1.13.0 fosse rotulada como estável às 15:06 UTC de 14 de setembro. A conta @ETC_Network publicou o pedido de migração na manhã seguinte.
O software alcançou parte da infraestrutura de mineração do Ethereum Classic antes que os operadores revertessem a migração. Quatro nós da 2Miners estavam executando o CoreGeth v1.13.0 às 12:09 UTC de 15 de setembro, de acordo com dados de status de nós citados pela Classix. Às 23:35 UTC, todos os quatro haviam retornado ao Argos v1.12.23. Outros pools de mineração listados permaneceram em versões da série 1.12.
Alguns nós individuais continuaram executando o software disputado. O Etcnodes.org mostrou 11 nós v1.13.0 às 07:33 UTC de 15 de setembro, com o número caindo para 10 em 16 de setembro. Três dos nós restantes correspondiam a endereços IP de bootnode codificados no novo cliente, de acordo com o relatório.
Nenhum bloco foi perdido, nenhuma reorganização de cadeia ocorreu, nenhum fundo foi afetado e nenhuma interrupção de serviço foi registrada durante o incidente, disse a Classix. O relatório classificou o evento como de alta gravidade, mas de baixo impacto, porque o software alterou o comportamento de consenso sem produzir perdas econômicas ou de transação registradas.
O Ethereum Classic já enfrentou reorganizações de cadeia antes. Como o crypto.news relatou anteriormente em sua cobertura de ataques de maioria no Ethereum Classic, o ETC sofreu três ataques de maioria em agosto de 2020, incluindo reorganizações envolvendo milhares de blocos.
Classix contesta alegações de segurança da v1.13.0
O lançamento da v1.13.0 informou aos operadores que todo nó executando v1.12.x deveria atualizar e alegou que cada lançamento dessa série continha problemas de segurança não corrigidos, incluindo uma vulnerabilidade supostamente usada contra bootnodes do Ethereum Classic em março.
A Classix contestou essa descrição após revisar sete problemas de segurança citados pelo lançamento. Cinco já haviam sido abordados em lançamentos mantidos do Core Geth entre março e agosto, enquanto os outros dois não afetavam o caminho peer-to-peer do Ethereum Classic, de acordo com o relatório.
CVE-2026-22862 e CVE-2026-26315 estavam entre as vulnerabilidades que a Classix disse terem sido corrigidas no Aegis v1.12.21. O Hermes v1.12.22 subsequentemente abordou outros problemas criptográficos, enquanto o Argos v1.12.23 incorporou a decodificação atrasada de mensagens peer-to-peer do go-ethereum para abordar o CVE-2026-26313.
Outro problema listado, CVE-2026-22868, dizia respeito à verificação de provas KZG. A Classix afirmou que não se aplicava ao Ethereum Classic porque as provas KZG estão associadas a transações blob introduzidas através da atualização Cancun do Ethereum, que a ETC não ativou. O relatório afirmou que um problema separado de profundidade de consulta GraphQL não fazia parte do caminho peer to peer ou de consenso e exigia que o GraphQL fosse ativado manualmente.
A Classix afirmou que o mantenedor do Core Geth, Diego López León, revisou as diferenças restantes e não encontrou nenhuma falha explorável no Argos que a v1.13.0 tivesse corrigido.
Mudanças no Core Geth incluíram MESS e novos bootnodes
Além das suas alegações de segurança, a v1.13.0 alterou a forma como os nós participantes podiam selecionar cadeias e descobrir pares.
Uma modificação reativou o Modified Exponential Subjective Scoring, ou MESS, ao remover a configuração que o desativava no bloco 19.250.000. O Ethereum Classic introduziu o MESS em 2020 como proteção contra reorganizações de cadeia antes de o desativar através do ECIP-1110 depois de o Ethereum ter passado de prova de trabalho para prova de participação.
A Classix alertou que diferentes clientes de consenso poderiam comportar-se de forma diferente se apenas os nós do Core Geth usassem o MESS. O Besu, o Nethermind e o Getc não implementam o mecanismo, segundo o relatório.
As reorganizações históricas continuam a ser uma questão particularmente relevante para a ETC. Uma análise da crypto.news sobre o histórico de reorganizações de blockchain descreveu como o consenso dos mineradores e históricos de cadeia concorrentes podem determinar o resultado de reorganizações em redes de prova de trabalho.
O cliente contestado também alterou a infraestrutura de descoberta de nós. Um commit substituiu uma chave de assinatura de árvore DNS mantida por contribuidores do etclabscore desde 2020 e codificou três novos endereços IP de bootnode. Duas árvores de descoberta mais antigas, blockd.info e etcdisco.net, foram subsequentemente removidas.
Três domínios de substituição foram alojados através da mesma conta Cloudflare, segundo o relatório, enquanto o repositório reconheceu que um problema que afetasse a única conta poderia remover os três caminhos. Os operadores que seguissem as instruções de migração não foram informados sobre quem controlava a nova chave de assinatura, afirmou a Classix.
O guia de migração instruiu separadamente os operadores a rodar as suas chaves de nó P2P, citando o CVE-2026-26315. A Classix afirmou que a Aegis já tinha corrigido o problema subjacente em março. Rodar uma chave altera a identidade de rede de um nó e força-o a reconstruir ligações de pares através da infraestrutura de descoberta.
Operadores do Ethereum Classic instados a regressar ao Argos
A Classix recomendou que os operadores evitassem o ethereumclassic/core-geth v1.13.0 e continuassem a executar o etclabscore/core-geth Argos v1.12.23. Os operadores que já tinham migrado foram instruídos a voltar atrás, restaurar a sua chave de nó anterior se esta tivesse sido rodada e verificar a sua configuração MESS.
O relatório afirmou que os operadores do Ethereum Classic deveriam considerar executar clientes diferentes em vez de concentrar o poder de hash da rede no Core Geth. O Nethermind, o Besu e o Getc continuam a ser alternativas disponíveis.
A diversidade de clientes tornou-se uma consideração de segurança recorrente em todas as redes blockchain. O desenvolvimento do Ethereum, por exemplo, continua a testar atualizações em múltiplas implementações de execução e consenso antes da implantação. Os recentes preparativos da testnet Glamsterdam incluíram outra devnet privada depois de os testes terem exposto bugs de implementação de consenso e execução antes da ativação planeada na Sepolia.
A Classix pediu aos administradores da organização ethereumclassic no GitHub que reforçassem os controlos dos repositórios, exigissem propostas e revisões antes de serem criados novos repositórios, protegessem os ramos predefinidos e identificassem mantenedores para repositórios que distribuem software. Solicitou separadamente que o ethereumclassic/core-geth fosse removido ou arquivado, ou que tivesse um aviso a explicar que não é um cliente oficial.
O próprio Ethereum Classic não designa um programador, mantenedor, site ou cliente oficial, de acordo com o aviso legal do site do projeto citado no relatório. A Classix afirmou que o repositório etclabscore mantido deriva a sua posição, em vez disso, do seu histórico público de seis anos, manutenção ativa e adoção entre nós da ETC.
O relatório destina-se a servir tanto como notificação inicial como relatório intercalar de incidente. A Classix afirmou que atualizaria o documento se os nós restantes forem verificados, se os mantenedores da organização responderem ou se surgirem outros desenvolvimentos materiais.
