O perímetro mudou de lugar

Toda a educação de segurança cripto, com razão, gira em torno de um objeto: a seed phrase. Guarde-a offline, nunca a digite num site, desconfie do suporte que pede suas doze palavras. É um bom conselho. Mas ele parte de uma suposição silenciosa — a de que o perigo mora na sua frente, numa mensagem de phishing, num link torto, num falso atendente. A última geração de ataques desloca o perigo para trás das suas costas.

Quando você assina uma transação, não é você quem lê o endereço de destino: é um programa. E esse programa quase nunca é uma peça única e artesanal. É uma montagem de centenas, às vezes milhares, de pequenos componentes — bibliotecas, no jargão — baixados de repositórios públicos e mantidos, de graça, por desenvolvedores que você nunca vai conhecer. Um aplicativo moderno de carteira pode arrastar consigo mais de mil dessas dependências. Cada uma é uma mão anônima que toca o código que, no fim da linha, lê o seu saldo e monta a sua transferência.

É aí que entra o ataque de cadeia de suprimentos (supply chain attack): em vez de atacar você, o criminoso envenena uma dessas peças lá em cima, na fonte. Quando o aplicativo se atualiza — algo que ele faz sozinho, todo dia, sem perguntar —, o veneno desce pela cadeia e chega até a sua máquina. Você não clicou em nada. Fez tudo certo. E mesmo assim o endereço para onde o dinheiro vai foi trocado no caminho.

Setembro de 2025: o maior ataque e os US$ 50

O exemplo mais didático é também o mais irônico. Em setembro de 2025, atacantes obtiveram as credenciais de um desenvolvedor por meio de um e-mail de phishing enviado de um domínio falso de “suporte” do npm — o maior repositório de código JavaScript do mundo. Com a conta na mão, publicaram versões maliciosas de bibliotecas tão básicas que quase ninguém sabe que as usa: chalk, debug, strip-ansi. São peças de infraestrutura invisível, somando mais de dois bilhões de downloads por semana.

O código injetado era um “clipper”: ele interceptava endereços de carteira que passassem pela rede e os substituía, no ar, por endereços do atacante. Cinco redes estavam na mira — Bitcoin, Ethereum, Solana, Tron e Litecoin. Qualquer aplicativo que tivesse incorporado as versões infectadas podia ter transações silenciosamente redirecionadas, sem que ninguém percebesse.

O desfecho desafia a intuição. Apesar de uma superfície de ataque praticamente planetária, o roubo somou cerca de cinquenta dólares. O motivo é instrutivo: a comunidade detectou e reverteu as versões maliciosas em questão de horas. Os mais expostos foram justamente os aplicativos que se atualizam no automático, incorporando o código novo em minutos. Quem fixava suas dependências em versões já verificadas — uma prática de disciplina, não de sorte — simplesmente não foi tocado. Como resumiu Charles Guillemet, diretor de tecnologia da Ledger: “o perigo imediato pode ter passado, mas a ameaça não”.

Julho de 2026: o caso Injective e a escalada

Se 2025 roubou credenciais, 2026 mostrou que nem isso é mais necessário. Em 8 de julho, dezoito pacotes da Injective — uma blockchain focada em finanças — foram publicados em uma versão contaminada, a 1.20.21. O alvo era o coração da coisa: um arquivo discretamente batizado de key-derivation-telemetry.ts, acionado toda vez que o programa derivava uma chave a partir da frase de recuperação. Ou seja, o código não roubava endereços na rede — roubava a própria seed phrase e as chaves privadas, no exato momento em que o usuário as carregava.

A sofisticação estava no método. O atacante não roubou um token de publicação nem invadiu servidor algum. Usou a identidade de um mantenedor legítimo para enviar três alterações diretamente ao repositório — e deixou que a própria esteira automática de publicação, projetada para ser prática e confiável, fizesse o trabalho sujo de distribuir o veneno. A confiança do sistema foi a arma. A janela de exposição durou menos de uma hora; a correção (versão 1.20.23) saiu cerca de quarenta e nove minutos depois. Mas, para quem compilou um aplicativo naquele intervalo, a frase de recuperação já deve ser considerada comprometida.

Por que o código aberto é um alvo

Há uma tentação de ler esses episódios como uma condenação do software livre. Seria um erro. O código aberto sustenta praticamente tudo o que funciona na internet — e no cripto em particular, onde a transparência é um valor fundador: você pode ler o que o programa faz, em vez de confiar na palavra de uma empresa. O problema não é a abertura. É uma suposição que herdamos dela, a dos “muitos olhos”: a crença de que, se o código está à vista de todos, alguém sempre estará olhando.

Na prática, os muitos olhos são poucos e cansados. Bibliotecas críticas de infraestrutura costumam ser mantidas por um punhado de voluntários, às vezes por uma pessoa só, sem remuneração e sob pressão. A economia da coisa é frágil: construímos castelos de valor — carteiras que guardam fortunas — sobre alicerces doados por estranhos nas horas vagas. É um dos arranjos mais generosos e mais negligenciados da tecnologia moderna. E é exatamente essa assimetria, entre o que depende do código e o que se investe em defendê-lo, que o atacante explora.

A defesa: assinar com os olhos abertos

A conclusão prática é libertadora, não paralisante. Se o endereço pode ser trocado em qualquer ponto entre o seu clique e a rede, então o único lugar seguro para conferi-lo é o último elo da corrente — a tela do seu dispositivo físico, que não compartilha o sistema operacional comprometido. É o princípio do “clear signing”, ou assinatura legível: a carteira de hardware mostra, em seu próprio visor, o endereço e o valor reais da transação. Se o que aparece ali diverge do que você pretendia enviar, você recusa — e o clipper mais sofisticado do mundo falha.

Disso derivam hábitos concretos. Prefira carteiras de hardware para quantias relevantes, e leia o que o visor diz, caractere a caractere, em vez de confiar na tela do computador. Para desenvolvedores e usuários avançados: fixe versões de dependências em vez de atualizar no automático, e desconfie de atualizações recém-publicadas. E, acima de tudo, internalize a inversão: a segurança cripto amadureceu do “não entregue sua senha” para o “não assine o que você não consegue verificar”.

Uma reflexão: a confiança como infraestrutura

Há algo quase filosófico nesses ataques. O cripto nasceu de uma promessa radical — trustless, “sem confiança” —, a ideia de que a matemática substituiria os intermediários e você não precisaria confiar em ninguém. É verdade no nível do protocolo: a blockchain não pede fé. Mas o protocolo não vive no vácuo. Entre você e a rede há uma espessa camada de software humano, e essa camada é feita, inteiramente, de confiança delegada a milhares de desconhecidos.

Talvez seja esse o amadurecimento necessário: entender que a autonomia que o cripto oferece é também uma responsabilidade que ele transfere. O velho sistema terceirizava a confiança a um banco, que respondia pelos erros. O novo devolve essa confiança a você — e, com ela, o dever de verificar. A liberdade de ser o seu próprio banco vem com a obrigação de ser o seu próprio departamento de segurança. Não é um defeito do modelo; é o preço coerente da soberania que ele promete. Quem não quer esse ônus tem alternativas legítimas, dos custodiantes regulados às corretoras. Mas quem escolhe a chave na própria mão aceita, junto, a regra mais antiga da engenharia de confiança: não confie — verifique.