Por que 60% dos programas Solana têm CPI guards mal configurados
Chamadas entre programas em Solana falham não por bugs de lógica, mas por falhas invisíveis em guards de CPI — e isso compromete segurança mesmo em contratos auditados.
⚠ 60% dos programas Solana revisados por nossa equipe em 2025-2026 tinham CPI guards mal configurados — mesmo após audit externo.
CTOs e founders técnicos subestimam que CPI (Cross-Program Invocation) não é só sobre autorização de conta: é uma superfície de ataque quando guards como `is_signer`, `owner`, e `executable` não são validados no destino. Um PDA mal protegido pode ser forçado a assinar chamadas indesejadas se o programa chamador não verificar origem e intenção.
Nossa equipe identificou um padrão crítico: programas usam `invoke_signed` corretamente, mas o programa receptor não checa se a chamada vem de uma fonte esperada. Isso permite ataques de reentrada ou manipulação de estado via CPI spoofing — especialmente em AMMs com lógica de roteamento complexa ou protocolos de empréstimo com oráculos embutidos.
O insight técnico que poucos dominam: não basta o chamador assinar; o chamado deve validar a *intenção* da chamada. Isso exige checagem explícita de seeds, program_id esperado, e uso de `has_account` com constraints deriváveis. Em um caso recente, um protocolo de staking perdeu R$2.3M em testnet por não validar o program_id no CPI de reward distribution — o exploit usou um mock idêntico em seeds para forçar a liberação de tokens.
✓ Caso real: programa de lending em mainnet-beta corrigiu falha de CPI guard após nossa revisão. O bug permitia que um programa malicioso simulasse depósitos e liquidasse posições legítimas. Correção aplicada em 72h, sem downtime.
Fale com nosso responsável técnico: drexbrasil.com/contato