Contexte
Le 27 janvier 2026, nous avons détecté une attaque sur le projet PGNLZ sur le BNB Smart Chain :
https://bscscan.com/tx/0xa7488ff4d6a85bf19994748837713c710650378383530ae709aec628023cd7cc
Après une analyse détaillée, l'attaquant a lancé une attaque soutenue contre le projet PGNLZ le 27 janvier 2026, causant une perte d'environ 100 000 USD.
Analyse de l'attaque et de l'événement
L'attaquant a d'abord emprunté 1 059 BTCB via un flash loan auprès de Moolah Protocol,
Puis, il a déposé ces 1 059 BTCB en collatéral sur Venus Protocol pour emprunter 30 000 000 USDT.
Ensuite, l'attaquant a appelé la fonction `swapTokensForExactTokens` sur PancakeSwap, utilisant 23 337 952 USDT pour échanger contre 982 506 PGNLZ, mais a ensuite brûlé ces PGNLZ (en les envoyant à l'adresse 0xdead).
Avant l'échange, le pool PancakeSwap contenait 100 901 USDT et 982 506 PGNLZ, le prix du PGNLZ était donc de 1 PGNLZ = 0,1 USDT. Après l'échange, le pool PancakeSwap contenait 23 438 853 USDT et 4 240 PGNLZ, le prix du PGNLZ est alors passé à 1 PGNLZ = 5 528 USDT.
Par la suite, l'attaquant a appelé la fonction `swapExactTokensForTokensSupportingFeeOnTransferTokens`, une fonction conçue pour prendre en charge les tokens avec frais de transfert (Fee-On Transfer Token). PGNLZ utilise `_update` pour gérer les frais de transaction, la chaîne d'appel spécifique étant : `transferFrom` -> `_spendAllowance` -> `_transfer` -> `_update`.
Comme il s'agissait d'une vente (sell), la fonction `_handleSellTax` a été appelée.
Examinons comment `_executeBurnFromLP` est implémentée,
On peut voir que `_executeBurnFromLP` utilise `_update` pour brûler la quantité de PGNLZ définie par `pendingBurnFromLP`. Le bloc précédent indiquait que `pendingBurnFromLP` était de 4 240 113 074 578 781 194 669.
Après le burn, il ne restait plus que 0,00000001 PGNLZ dans le pool de liquidité (LP Pool), le prix est alors passé à 1 PGNLZ = 234 385 300 000 000 USDT, soit une multiplication par 40 milliards.
Enfin, l'attaquant a vidé le LP Pool, a remboursé le flash loan, et a réalisé un profit de 100 000 USDT.
Conclusion
La cause de cette vulnérabilité réside dans le modèle économique déflationniste, qui ne valide pas les frais prélevés ou la combustion du pool de liquidité. Cela a permis à l'attaquant de manipuler le prix du token en exploitant ses caractéristiques déflationnistes. Il est recommandé aux projets de valider minutieusement la conception de leur modèle économique et la logique d'exécution du code, et de privilégier un audit croisé par plusieurs sociétés d'audit avant le déploiement du contrat.
