Una "autodestrucción" cuidadosamente diseñada: Análisis del ataque a PGNLZ

Introducción

El 27 de enero de 2026, detectamos un ataque en BNB Smart Chain contra el proyecto PGNLZ:

https://bscscan.com/tx/0xa7488ff4d6a85bf19994748837713c710650378383530ae709aec628023cd7cc

Tras un análisis detallado, el atacante llevó a cabo un ataque continuo contra el proyecto PGNLZ el 27 de enero de 2026, causando pérdidas de aproximadamente 100.000 USD.

Análisis del ataque y eventos

El atacante primero tomó un préstamo flash de 1.059 BTCB del Protocolo Moolah,

Posteriormente, depositó como garantía 1.059 BTCB en Venus Protocol, para tomar prestados 30.000.000 USDT.

A continuación, el atacante llamó a la función swapTokensForExactTokens en PancakeSwap, utilizando 23.337.952 USDT para cambiar por 982.506 PGNLZ, pero luego destruyó estos PGNLZ (los envió a 0xdead).

Antes del intercambio, el Pool de PancakeSwap tenía 100.901 USDT y 982.506 PGNLZ, momento en el que el precio de PGNLZ era de 1 PGNLZ = 0,1 USDT. Después del intercambio, el Pool de PancakeSwap quedó con 23.438.853 USDT y 4.240 PGNLZ, momento en el que el precio de PGNLZ era de 1 PGNLZ = 5.528 USDT.

Posteriormente, el atacante llamó a la función swapExactTokensForTokensSupportingFeeOnTransferTokens, una función diseñada principalmente para admitir tokens con tarifas en las transferencias (Fee-On Transfer Token). PGNLZ utiliza _update para manejar las tarifas de las transacciones, y la cadena de llamadas es: transferFrom -> _spendAllowance -> _transfer -> _update

Como esta operación era una venta (sell), se llamó a _handleSellTax.

Veamos cómo se implementa _executeBurnFromLP,

Se puede observar que _executeBurnFromLP utiliza _update para quemar (burn) la cantidad de PGNLZ especificada en pendingBurnFromLP. En el bloque anterior, se consultó que pendingBurnFromLP era 4.240.113.074.578.781.194.669.

Después de la quema, el LP Pool solo quedó con 0,00000001 PGNLZ, momento en el que 1 PGNLZ = 234.385.300.000.000 USDT, un aumento de 40 mil millones de veces.

Finalmente, el atacante vació el LP Pool, pagó el préstamo flash y obtuvo una ganancia de 100.000 USDT.

Conclusión

La causa de esta vulnerabilidad fue el modelo económico deflacionario, que no realizaba las verificaciones adecuadas al deducir tarifas o quemar el LP Pool. Esto permitió al atacante manipular el precio del Token aprovechando la característica deflacionaria. Se recomienda a los proyectos validar exhaustivamente el diseño del modelo económico y la lógica de ejecución del código, y optar por auditorías cruzadas de múltiples empresas de auditoría antes de lanzar el contrato.