Shiba Inu Dev emite uma nova atualização de segurança na ponte Shibarium

O desenvolvedor principal da Shiba Inu, Kaal Dhairya, emitiu uma atualização de segurança detalhada após o incidente de 12 de setembro que explorou o poder de assinatura do validador na ponte Shibarium POS para empurrar um estado/saída malicioso e retirar vários ativos. O post, publicado em 21 de setembro de 2025, descreve o que aconteceu, o que foi feito até agora e o que governará uma restauração em fases assim que as revisões independentes concluem.

Shiba Inu Core Dev compartilha outra atualização

Em um prefácio pessoal que enquadrou as dimensões técnicas e humanas do episódio, Dhairya abriu -se distanciando -se de qualquer manto de liderança singular e reiterou o ethos original que dirigia seu trabalho. “Quero esclarecer primeiro: não sou ‘a liderança’. Eu nunca fui e nunca quero ser.

O Shiba Inu Core Dev alertou que, dada “a sofisticação desse ataque”, ele não podia atestar atualmente a segurança de nenhuma chave existente, e sinalizou fadiga com as expectativas de que os colaboradores individuais poderiam “manter tudo juntos” sem apoio estrutural mais amplo.

O relato do incidente descreve como, às 18:44 UTC em 12 de setembro, “O poder de assinatura do validador não autorizado foi usado para empurrar um estado/saída malicioso pela ponte POS”. O método, de acordo com a atualização, combinou amplificação de participação de curta duração com o ponto de verificação malicioso/provas de saída para autorizar saques. Diz-se que a atividade pós-incidente na cadeia ligada ao invasor inclui as vendas de partes da ETH, Shib e Roar, embora a equipe esteja retendo o “gráfico de carteira em evolução”, enquanto a contenção e a coordenação com as autoridades continuam. “Vamos liberar a narrativa técnica completa depois de fazer, portanto, não aumenta mais o risco”, afirma o Post.

As medidas imediatas incluem restringir as operações de pontes específicas para evitar novas saídas não autorizadas, atualização e bloqueio de contratos, cobrindo depósitos, retiradas, reivindicações e recompensas e aplicação de “controles defensivos direcionados contra o uso indevido de participação delegada”. A equipe diz que se recuperou e garantiu os ossos em risco no nível do gerente da estaca e observa que qualquer participação óssea de curto prazo sob o invasor permanece “efetivamente imobilizada” por intervenções e mecânicos de protocolo.

As etapas de higiene-chave e de custódia envolveram os signatários do validador rotativos e o controle do contrato de migração para a custódia de hardware de várias partes, enquanto o monitoramento ao vivo e os alertas automatizados continuam em coordenação com trocas, pesquisadores de segurança externos, empresas de resposta a incidentes e autoridades relevantes.

A atualização também envolve perguntas frequentes sobre comprometimento do validador e responsabilidade operacional. Ele diz que as chaves de assinatura do validador foram “armazenadas principalmente no AWS KMS, com raro uso em máquinas de desenvolvedores”, e essa responsabilidade final pelo gerenciamento -chave está na liderança operacional. Embora um único vetor de intrusão não tenha sido confirmado, as possibilidades preliminares incluem um comprometimento da máquina de desenvolvedor, um compromisso de KMS em nuvem, exposição durante uma migração AWS para GCP ou um ataque da cadeia de suprimentos, como via NPM.

O Post reconhece que as deficiências de descentralização são sublinhadas pelo fato de que “10 dos 12 validadores” assinaram o estado malicioso e se compromete a uma maior descentralização do validador, política de rotação de chaves mais forte, custódia mais rígida, divulgações aprimoradas e limites de due diligência mais rígidos para acesso sensitivo.

Uma visualização de roteiro estabelece quatro fases fechadas. “Contenção” permanece em andamento com a funcionalidade de ponte restrita e o monitoramento ao vivo; “Hardening”, em colaboração com Hexens, inclui higiene do signatário/validador, controles em nível de política, como limites de taxa, janelas de desafio e caia-canecas e extensões de nega na lista, quando tecnicamente apropriado.

Em seguida, “Restauração segura” não começará até que as revisões independentes assinem mitigações, verificações de integridade pós-incidente e exercícios em ambientes de teste tenham sucesso, com a restauração executada em fases e com alavancas de reversão; Finalmente, um post-mortem técnico abrangente precederá um caminho de remediação revisado pela comunidade para usuários e liquidez afetados, com a atualização observando que “abordagens específicas para token podem diferir”.

Os cronogramas permanecem intencionalmente não especificados: “Não publicaremos datas que possam ser dadas por um adversário”, escreve a equipe, reiterando que as atualizações serão publicadas em canais oficiais.

Para os titulares e vítimas de shiba inu, a mensagem é franca: cuidado com os golpes, ignore os “portais de recuperação/reclamação” não verificados e espere que as restrições da ponte persistam “até confirmarmos que é seguro restaurar”. Perguntas sobre a ponte de volta ao Ethereum, o momento da retomada da ponte, a rotação do validador e a auditoria completa recebem a mesma resposta – segurança primeiro, detalhes a seguir quando a segurança permitir. Na recuperação de fundos e potencial compensação, a equipe diz que as opções estão sendo avaliadas e qualquer proposta será publicada para revisão da comunidade “uma vez viável e segura”.

O desenvolvedor Shiba Inu fecha reafirmando as prioridades e situando a comunicação dentro de uma cadência disciplinada. “Nossas prioridades permanecem inalteradas: proteja os usuários, proteja a rede, contenha o invasor e restaure os serviços com segurança.” A próxima grande comunicação, ele escreve, será a post -mortem técnica e uma proposta de remediação “quando o ambiente estiver seguro para a divulgação completa”.

No momento, a Shiba Inu foi negociada a US $ 0,00001207.

Imagem em destaque criada com Dall.e, gráfico de Tradingview.com