Durante a semana passada (25 de jan–1º de fev de 2026), a BlockSec detectou e analisou seis incidentes de ataque, com perdas totais estimadas de ~$18,05M. A tabela abaixo resume esses incidentes, e análises detalhadas de cada caso são fornecidas nas subseções a seguir.
| Data | Incidente | Tipo | Perda Estimada |
|---|---|---|---|
| 2026/01/25 | Incidente SwapNet | Validação inadequada de entrada | ~$13,41M |
| 2026/01/25 | Incidente Aperture Finance | Validação inadequada de entrada | ~$3,67M |
| 2026/01/27 | Incidente PGNLZ | Falha no design do token | ~$100K |
| 2026/01/28 | Incidente XPlayer | Falha no design do token | ~$717K |
| 2026/01/28 | Incidente Holdstation | Comprometimento de chave | ~$100K |
| 2026/01/30 | Incidente Revert Finance | Falha na lógica de negócio | ~$50K |
1. Incidente SwapNet
Resumo Breve
Em 25 de janeiro de 2026, o protocolo SwapNet nas redes Base, BSC e Arbitrum foi explorado, resultando em aproximadamente $13,41 milhões em perdas. O incidente teve origem na validação insuficiente de entradas fornecidas pelo usuário, o que permitiu a um atacante criar chamadas que invocavam transferFrom() com parâmetros controlados pelo atacante. Ao abusar das aprovações de tokens existentes, o atacante executou efetivamente transferências na forma de token.transferFrom(vítima, atacante, valor), permitindo drenar os ativos aprovados das vítimas.
Contexto
O protocolo SwapNet é um agregador DEX projetado para encontrar rotas de swap ideais, agregando liquidez de múltiplas fontes on-chain, incluindo AMMs e formadores de mercado privados. O protocolo também permite que os usuários especifiquem roteadores ou pools personalizados ao executar swaps, oferecendo flexibilidade adicional.
Análise de Vulnerabilidade
Este incidente tem origem na validação insuficiente de entradas fornecidas pelo usuário, o que permite a um atacante acionar chamadas transferFrom() com parâmetros arbitrários. Como resultado, ativos que haviam sido previamente aprovados para os contratos da vítima (ex.: 0x616000e384Ef1C2B52f5f3A88D57a3B64F23757e) podiam ser transferidos para o atacante.
Com base no bytecode descompilado, a função 0x87395540() aparentemente não possui validação adequada nas entradas críticas. Ao substituir o endereço esperado do roteador ou pool por um endereço de token (ex.: USDC), o contrato trata incorretamente o token como um alvo de execução válido. Isso leva à execução de uma chamada de baixo nível com calldata controlado pelo atacante.
Consequentemente, o contrato da vítima executa chamadas na forma: approvedAsset.transferFrom(vítima, atacante, valor), permitindo ao atacante drenar todos os ativos aprovados.
Análise do Ataque
Múltiplos ataques foram observados contra o SwapNet. Aqui utilizamos a transação Base 0xc15df1d131e98d24aa0f107a67e33e66cf2ea27903338cc437a3665b6404dd57 como exemplo. O atacante simplesmente invocou a função 0x87395540() do contrato da vítima com entradas maliciosas. Essa invocação consiste em duas etapas principais.
- Uma variável interna chave (ex.:
v51) foi definida comoUSDC, contornando a lógica de roteamento pretendida.
- Uma chamada de baixo nível foi executada usando calldata controlado pelo atacante, resultando na invocação de
USDC.transferFrom()e na drenagem de todos osUSDCaprovados.
Conclusão
O incidente é causado pela validação insuficiente de entradas fornecidas pelo usuário, e adicionar verificações adequadas nos parâmetros de entrada à função ajudaria a mitigar esse problema.
2. Incidente Aperture Finance
Resumo Breve
Em 25 de janeiro de 2026, o protocolo Aperture nas redes Ethereum, Base e Arbitrum foi explorado, resultando em aproximadamente $3,67 milhões em perdas. A causa raiz foi a validação insuficiente de entradas fornecidas pelo usuário, o que permitiu a um atacante acionar chamadas transferFrom() com parâmetros arbitrários por meio da função interna 0x1d33(). Como resultado, o atacante foi capaz de executar chamadas como approvedToken.transferFrom(vítima, atacante, valor), permitindo drenar todos os ativos aprovados.
Contexto
A Aperture Finance é um protocolo DeFi que gerencia posições de liquidez concentrada, como LPs do Uniswap V3, em nome dos usuários. Seus contratos de código fechado (ex.: 0xD83d960deBEC397fB149b51F8F37DD3B5CFA8913) permitem que os usuários criem e gerenciem posições no Uniswap V3 usando tokens nativos.
Fluxo de Trabalho Pretendido para Criação de Posições no Uniswap V3
Ao criar posições no Uniswap V3 por meio da função 0x67b34120(), o contrato segue um fluxo de trabalho de três etapas:
-
Converter tokens nativos em wrapped tokens
-
Trocar os wrapped tokens por meio da função interna
0x1d33() -
Criar posições no UniswapV3
O problema surge na Etapa 2: A função interna 0x1d33() realiza um swap personalizado por meio de uma chamada de baixo nível, onde parâmetros críticos (ex.: o alvo da chamada e o calldata) parecem ser controlados pelo usuário e insuficientemente validados, possibilitando chamadas externas não intencionais. Mais detalhes são fornecidos nas seções a seguir.
Análise de Vulnerabilidade
O incidente é causado pela validação insuficiente de entradas em chamadas de baixo nível. Quando a função 0x67b34120() é invocada, a função interna 0x1d33() executa uma chamada de baixo nível usando calldata fornecido pelo usuário, sem impor restrições rígidas ao alvo da chamada ou ao seletor de função.
Como mostrado na figura abaixo, o calldata usado para acionar a chamada de baixo nível é baseado puramente nas entradas do atacante.
Isso permite que atacantes construam calldata malicioso que resulta em: approvedToken.transferFrom(vítima, atacante, valor) executado no contexto do contrato da vítima. Como resultado, não apenas tokens ERC20, mas também NFTs de posições aprovados no Uniswap V3 podem ser drenados.
Análise do Ataque
Múltiplos ataques foram observados contra a Aperture Finance. Nesta seção, utilizamos a transação Ethereum 0x8f28a7f604f1b3890c2275eec54cd7deb40935183a856074c0a06e4b5f72f25a como exemplo representativo.
-
O atacante criou um contrato de ataque
0x5c92884dFE0795db5ee095E68414d6aaBf398130. -
O contrato de ataque invocou a função
0x67b34120()com entradas maliciosas e 100 wei ETH (ou seja, msg.value == 100).
- a. Os ETH nativos foram convertidos em WETH por meio da função
WETH.deposit().
- b. A função interna
0x1d33()foi invocada para realizar uma chamada de baixo nível. Nesta etapa, uma chamada deWBTC.transferFrom(vítima, atacante, valor)é invocada no contexto do contrato da vítima, permitindo ao atacante drenar os tokens aprovados. Vale notar que uma verificação de saldo foi aprovada ao final da função0x1d33(). Especificamente, a função0x1d33()comparou as variações de saldo com um valor de saída de swap (ou seja,varg2.word2) também especificado pelo atacante. Como resultado, foram executadas com sucesso sem receber nada.
- c. Por fim, a função
NonfungiblePositionManager.mint()foi invocada para criar uma posição para o atacante usando 100 wei WETH.
Descobertas Interessantes
Ao comparar transações de criação normais e anormais, observamos que ambas as transações aprovaram tokens para o mesmo gastador (ex.: OKX DEX: TokenApprove), mas especificaram endereços de roteador diferentes (ou seja, DexRouter e WBTC). Isso sugere que o contrato pode impor validação no gastador da aprovação, mas falha em validar o alvo de execução real, deixando uma lacuna crítica explorável por meio de chamadas arbitrárias.
Transação normal: link da tx1
Transação anormal: link da tx2
Conclusão
O incidente é causado pela validação insuficiente de entradas fornecidas pelo usuário. Adicionar validações adequadas nas entradas ajudaria a mitigar esse problema.
3. Incidente PGNLZ
Resumo Breve
Em 27 de janeiro de 2026, o pool USDT–PGNLZ V2 da PancakeSwap na BNB Smart Chain foi explorado, causando aproximadamente $100K em perdas. A causa raiz foi um mecanismo de queima falho no token PGNLZ que permitia ao atacante queimar PGNLZ diretamente do saldo do pool. Isso reduziu artificialmente as reservas de PGNLZ do pool, criando um desequilíbrio acentuado nas reservas e distorcendo o preço on-chain. O atacante então aproveitou o preço manipulado para executar swaps que drenaram USDT do pool.
Contexto
O token PGNLZ introduz um mecanismo de queima direcionado a um pool PancakeSwap V2. O mecanismo de queima pode ser acionado sob certas condições. Especificamente, para cada compra no pool, o token verifica se o saldo de USDT do pool atingiu um limite predefinido. Quando o limite é atingido, ele queima uma certa quantidade de PGNLZ do pool e define tradingEnabled = true, permitindo que usuários regulares interajam com o pool a partir de então. Quando o modo de negociação está habilitado e um usuário vende PGNLZ no pool, o token primeiro queima uma quantidade de PGNLZ mantida pelo pool com base na quantidade de PGNLZ vendida pelo usuário anterior.
Análise de Vulnerabilidade
O problema central foi o mecanismo de queima falho introduzido pelo token PGNLZ, que é vulnerável a um ataque de manipulação de preços. Especificamente, um atacante pode contornar a limitação do modo de negociação para manipular as reservas do pool (ou seja, comprando PGNLZ) ao definir o destinatário como o endereço isExcludedFromFee (ou seja, 0xdEaD). Em seguida, o atacante aproveita o mecanismo de queima (ou seja, por meio da função _executeBurnFromLP()) para queimar diretamente PGNLZ do pool, manipulando ainda mais as reservas do pool. Como resultado, o atacante pode obter lucros realizando um swap reverso (ou seja, vendendo PGNLZ) no pool manipulado.
Análise do Ataque
A análise a seguir é baseada na transação: 0xc7270212846136f3d103d1802a30cdaa6f8f280c4bce02240e99806101e08121
-
O atacante tomou emprestado
1.059e18 BTCBvia flash loan na Moolah e tomou emprestado30.000.000e18 USDTfornecendo1.059e18 BTCBna Venus. -
O atacante trocou
23.337.952e18 USDTpor978.266e18 PGNLZno pool PancakeSwap V2 quando o modo de negociação estava desabilitado. O atacante tornou o swap possível ao definir o destinatário como0xdEaD, o que contornou as validações correspondentes. -
O atacante trocou
17e18 PGNLZque possuía previamente porUSDTno pool PancakeSwap V2. Durante esse swap, a função_executeBurnFromLP()foi acionada, queimando4.240e18 PGNLZdo pool (ou seja, com base na quantidade de venda anterior dePGNLZ). Esse processo de queima deixou as reservas do pool com apenas0,00000001e18 PGNLZ, manipulando ainda mais a reserva dePGNLZdo pool. Com a reserva dePGNLZesgotada, o atacante conseguiu drenar23.438.853e18 USDTdo pool com apenas17e18 PGNLZ. -
O atacante reembolsou a posição na Venus e obteve um lucro de
100.901e18 USDT.
Conclusão
A causa raiz deste incidente decorre do mecanismo de queima falho do PGNLZ, que permitiu aos atacantes drenar USDT do pool por meio de um ataque de manipulação de preços. Como resultado, o incidente causou perdas totais de aproximadamente $100K. Para mitigar esses problemas, o projeto deve implementar controles de acesso adequados dentro do sistema e realizar testes abrangentes de seu mecanismo de queima para evitar possíveis ataques de manipulação de preços.
4. Incidente XPlayer
Resumo Breve
Em 28 de janeiro de 2026, o pool XPL/USDT V2 da PancakeSwap na BNB Smart Chain foi explorado, resultando em aproximadamente $717K em perdas. O incidente foi causado por um mecanismo de queima falho no token XPL que permitia a um atacante queimar XPL diretamente do saldo do pool. Ao reduzir artificialmente as reservas de XPL do pool, o atacante criou um grave desequilíbrio nas reservas e distorceu o preço de swap, e então explorou o preço manipulado para drenar USDT do pool.
Contexto
O token XPL introduz um mecanismo de queima, que queima tokens XPL do pool correspondente e depois chama a função sync() para atualizar as reservas do pool. Especificamente, no contrato NodeDistributePlus, a função DynamicBurnPool() pode ser chamada para executar uma tarefa de queima diária dentro de uma janela de execução. O valor queimado não deve exceder o limite diário de queima restante.
Análise de Vulnerabilidade
A causa raiz deste incidente decorre do mecanismo de queima falho do contrato XPL. Em particular, a função DynamicBurnPool() no contrato XPL permite que certos endereços privilegiados queimem XPL diretamente do par de liquidez.
Um desses endereços privilegiados é o contrato NodeDistributePlus (ou seja, nodeShareAddress), que implementa um cronograma de queima diária. Após uma conta privilegiada definir a meta de queima diária, qualquer chamador pode invocar NodeDistributePlus.DynamicBurnPool() dentro de uma janela de 2 dias até que o limite diário de queima seja atingido.
Como resultado, esse design permite que qualquer pessoa queime XPL do pool correspondente e force uma atualização das reservas. Um atacante pode aproveitar esse design para manipular as reservas do pool e executar um swap reverso para drenar USDT do pool.
Análise do Ataque
A análise a seguir é baseada na transação: 0x9779341b2b80ba679c83423c93ecfc2ebcec82f9f94c02624f83d8a647ee2e49
- O atacante tomou emprestado aproximadamente
239.523.169e18 USDTvia flash loans.
- O atacante trocou
100e18 USDTpor69e18 XPL. Esta etapa sincronizou as reservas do pool com os saldos atuais.
- O atacante trocou
217.118.801e18USDTpor aproximadamente691.022e18XPL. Esta etapa foi cuidadosamente dimensionada para configurar o estado do pool para a manipulação de reservas subsequente.
- O atacante invocou a função
DynamicBurnPool()para queimar3.078e18 XPLdo pool. Esse processo de queima manipulou ainda mais a reserva deXPLdo pool para um valor extremamente pequeno (ex.: 1 wei).
- O atacante trocou
69e18 XPLpor218.083.490e18 USDTcom as reservas manipuladas.
- O atacante reembolsou o flash loan e obteve um lucro de
718.844e18 USDT.
Conclusão
Este incidente é causado por um mecanismo de queima falho, que permite que qualquer pessoa queime XPL diretamente do pool para manipular suas reservas. Como resultado, esse design falho permite que atacantes realizem um ataque de manipulação de preços para drenar ativos valiosos do pool. Para mitigar problemas semelhantes, os projetos devem impedir a queima arbitrária de ativos do pool.
5. Incidente Holdstation
Resumo Breve
Em 28 de janeiro de 2026, a Holdstation relatou um comprometimento envolvendo a tomada de controle de uma carteira controlada pelo projeto, com perdas totais estimadas de ~$100K. O atacante drenou múltiplos ativos no valor de ~$66K, incluindo WLD, USD1, BNB e BERA, nas redes World Chain, BSC, Berachain e zkSync, e depois consolidou os ganhos no Ethereum em aproximadamente 22,41 ETH antes de fazer a ponte para Bitcoin em cerca de 0,755 BTC. O incidente foi rastreado ao comprometimento do dispositivo de um membro da equipe, supostamente por meio de uma IDE maliciosa ou extensão de navegador, o que possibilitou a tomada de controle da carteira.
Análise de Vulnerabilidade
A violação originou-se de uma extensão de codificação ou de navegador maliciosa instalada por um desenvolvedor principal, representando um erro humano em nível operacional. Especificamente, o desenvolvedor instalou uma extensão de IDE/navegador maliciosa e não confiável, o que resultou em comprometimento de conta e perdas financeiras.
Análise do Ataque
Os endereços relacionados e as transações de ponte são listados abaixo:
Endereços do Atacante
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d0x9d3a398cc667b97841a2a92ba808ee8dd368a1f2bc1qykmc6mllm3s4zpldww764v6vcgtqwshyw02k9c
Endereços das Vítimas
- (World Chain)
0xa92e09e0a52b7EdEaD75d3125e21bDFB9752C69e - (World Chain)
0xD768da05e0E6771Ea81b441026CE9355421eF7c9 - (World Chain)
0xA581ED1dEB42E8496E5275468C79D250b91d6a75 - (World Chain)
0x9BD647B2C8Fed689ADd2e7AA8b428d3eD12f75cb - (BSC)
0x2Edf158DDCe35733d6f7D9D7227610ca0531f0AD - (BSC)
0xA581ED1dEB42E8496E5275468C79D250b91d6a75 - (Bera Chain)
0xA581ED1dEB42E8496E5275468C79D250b91d6a75 - (Bera Chain)
0x628cEf732301aDF6d62bB2bcDFeBB291750C4D9a - (zkSync)
0xA581ED1dEB42E8496E5275468C79D250b91d6a75 - (zkSync)
0x8C826F795466E39acbfF1BB4eEeB759609377ba1 - (zkSync)
0x4Cf7baB01b8D3572b3dC08642ebbE2AD1aCF3B99 - (zkSync)
0x2Edf158DDCe35733d6f7D9D7227610ca0531f0AD - (zkSync)
0x2D2D047c50d7828Aedb6A151bA1717766606Bf33
Transações de Ponte
-
World Chain → Ethereum
- Valor:
114.308 WLD → 15,317 ETH - Remetente:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - Destinatário:
0x54e127b8DBF3BEBf64bB1d62A195A6f60113130d - TXs:
- Valor:
-
BSC → Ethereum
- Valor:
10,09 BNB → 2,992 ETH - Remetente:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - Destinatário:
0x54e127b8DBF3BEBf64bB1d62A195A6f60113130d - TXs:
- Valor:
-
BSC → Ethereum
- Valor:
6.101,6 USD1 → 2,027 ETH - Remetente:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - Destinatário:
0x54e127b8DBF3BEBf64bB1d62A195A6f60113130d - TXs:
- Valor:
-
Berachain → Ethereum
- Valor:
7.185 BERA → 1,45 ETH - Remetente:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - Destinatário:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - TXs:
- Valor:
-
Ethereum → Ethereum
- Valor:
22,41 ETH → 22,41 ETH - Remetente:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - Destinatário:
0x9D3A398cC667B97841a2A92ba808ee8dD368a1f2 - TXs:
- Valor:
-
Ethereum → Bitcoin
- Valor:
22,41 ETH → 0,755 BTC - Remetente:
0x9d3a398cc667b97841a2a92ba808ee8dd368a1f2 - Destinatário:
bc1qykmc6mllm3s4zpldww764v6vcgtqwshyw02k9c - TXs:
- Valor:
Conclusão
A causa raiz deste incidente decorre de um comprometimento de chave. Chaves de administrador, particularmente aquelas associadas a funções chave (ex.: proprietário) em contratos principais, devem ser gerenciadas com cuidado. Recomenda-se o uso de carteiras multisig para evitar pontos únicos de falha e aumentar a robustez sistêmica.
6. Incidente Revert Finance
Resumo Breve
Em 30 de janeiro de 2026, a Revert Finance na rede Base foi explorada, resultando em aproximadamente $50K em perdas. A causa raiz foi uma falha na lógica de negócio no contrato GaugeManager que permitia a um atacante retirar garantias sem reembolsar a dívida correspondente. Ao abusar de executeV3UtilsWithOptionalCompound(), o atacante contornou o fluxo de reembolso de dívida pretendido e extraiu fundos.
Contexto
A Revert Finance é uma plataforma de ferramentas abrangente projetada para provedores de liquidez (LPs) de Automated Market Makers (AMMs). Ela oferece principalmente recursos de análise, gerenciamento, automação e empréstimo para ajudar os LPs a melhorar a eficiência do capital e o controle de risco.
No protocolo, os usuários podem depositar suas posições no Uniswap v3 como garantia para tomar ativos emprestados dos pools de empréstimo da Revert Finance. Além disso, o protocolo permite que os usuários façam staking de suas posições, que são usadas como garantia, para ganhar recompensas extras por meio da função stakePosition().
Análise de Vulnerabilidade
A causa raiz do incidente foi a ausência de uma verificação de solvência ao fazer unstaking de posições usadas como garantia. Especificamente, a função executeV3UtilsWithOptionalCompound() permite que os usuários façam unstaking de uma posição indicando uma instrução correspondente (ou seja, whatToDo= 1). No entanto, essa função não possui uma verificação de solvência ao fazer unstaking de posições com garantia. Como resultado, um atacante pode resgatar uma posição com garantia sem reembolsar as dívidas pendentes.
Análise do Ataque
A análise a seguir é baseada na transação: 0x10429eaeb479f9149854e4aeb978a35ac02d9688f6e22371712b3878c63a64ab
-
O atacante tomou emprestado
10e8 cbBTCe10.000.000e6 USDCvia flash loan para criar uma posição (ou seja, NFT). -
O atacante penhorou o NFT como garantia e tomou emprestado
49.000e6 USDC. -
O atacante fez staking do NFT com garantia por meio da função
stakePosition(). -
O atacante instantaneamente fez unstaking do NFT com garantia usando a função
executeV3UtilsWithOptionalCompound(). Especificamente, a posição com garantia foi queimada e os ativos subjacentes correspondentes foram coletados pelo atacante. Devido à ausência de verificações de solvência no processo de unstaking, a posição com garantia foi queimada sem liquidar suas dívidas correspondentes.
- O atacante reembolsou o flash loan e obteve um lucro de
49.000e6 USDC.
Conclusão
A causa raiz do incidente é a ausência de uma verificação de solvência ao fazer unstaking de posições com garantia. Este incidente ressalta a importância das verificações de solvência em protocolos semelhantes a empréstimos. Implementar medidas robustas de solvência para cada uso da posição é essencial para garantir estabilidade e confiabilidade.
Referências
[1] SwapNet & Aperture https://blocksec.com/blog/17m-closed-source-smart-contract-exploit-arbitrary-call-swapnet-aperture
[2] PGNLZ: https://x.com/Phalcon_xyz/status/2016154398817505595
[3] XPlayer: X Player Official https://x.com/XPlayer_Media/status/2016700861578403910
[4] XPlayer: X Blocksec Phalcon https://x.com/Phalcon_xyz/status/2016521384609067103
[5] Holdstation: https://x.com/Phalcon_xyz/status/2016823122373296583
[6] Revert Finance: https://paragraph.com/@revertfinance/post%E2%80%91mortem-aerodrome-lend-vault-incident-on-base?referrer=0x8cadb20A4811f363Dadb863A190708bEd26245F8
Sobre a BlockSec
A BlockSec é uma provedora completa de segurança blockchain e conformidade cripto. Desenvolvemos produtos e serviços que ajudam os clientes a realizar auditorias de código (incluindo contratos inteligentes, blockchain e carteiras), interceptar ataques em tempo real, analisar incidentes, rastrear fundos ilícitos e cumprir obrigações de AML/CFT, ao longo de todo o ciclo de vida de protocolos e plataformas.
A BlockSec publicou múltiplos artigos de segurança blockchain em conferências de prestígio, reportou vários ataques de dia zero em aplicações DeFi, bloqueou múltiplos hacks para resgatar mais de 20 milhões de dólares e protegeu bilhões em criptomoedas.
-
Site oficial: https://blocksec.com/
-
Conta oficial no Twitter: https://twitter.com/BlockSecTeam
