Le 28 mars 2023, la memecoin promue par Jake Paul SafeMoon a perdu environ 8,9 millions de dollars de son pool de liquidité WBNB lorsqu'un attaquant a exploité une fonction burn() publique accidentellement exposée dans une récente mise à niveau de contrat. La fonction permettait à tout utilisateur de brûler des jetons depuis toute autre adresse — y compris le pool de liquidité WBNB SafeMoon lui-même. Après négociation, l'attaquant a restitué 7 M$ (80%).
Ce qui s'est passé
Une mise à niveau du contrat SafeMoon a introduit une fonction burn() avec des permissions d'accès publiques — presque certainement une conséquence non intentionnelle d'un refactor qui était censé laisser la fonction comme une opération admin interne. La fonction permettait à tout appelant de spécifier toute adresse et de brûler les jetons SFM depuis le solde de cette adresse, sans vérification d'autorisation.
L'analyse de PeckShield a noté le schéma de mise à niveau et a caractérisé le bug comme probablement lié à une fuite de clé admin — quelqu'un avec l'autorité de mise à niveau semble avoir poussé la version public-burn du contrat, soit par compromission, soit par une erreur de développeur qui n'a pas été détectée dans la revue.
L'attaque :
- Identification de la fonction
burn()publique dans le nouveau contrat. - Brûlage de la majorité des jetons SFM détenus par le pool de liquidité WBNB/SFM — réduisant drastiquement l'offre de SFM dans le pool tout en laissant le WBNB inchangé.
- Le mécanisme de découverte automatique des prix du pool a interprété la réduction de l'offre comme une énorme flambée de prix dans SFM — parce que le même WBNB devait maintenant être tarifé contre une minuscule offre de SFM.
- Vente d'une petite quantité de SFM dans le pool au prix artificiellement gonflé, drainant la majorité du WBNB du pool en échange.
- Départ avec environ 8,9 M$ en WBNB.
Conséquences
- L'équipe SafeMoon a alerté la communauté en quelques heures et engagé l'attaquant via des messages on-chain.
- L'attaquant a restitué 7 M$ (80% des fonds volés) après négociation, gardant 2 M$ comme « prime » effective.
- SafeMoon a mis en pause les contrats affectés et livré un jeton redessiné avec des contrôles d'accès appropriés.
- L'épisode a contribué au dénouement plus large du projet SafeMoon, qui avait déjà fait face à des actions d'application de la SEC pour des allégations de fraude contre ses fondateurs.
Pourquoi c'est important
SafeMoon est un cas frappant pour comment une seule fonction publique par erreur peut compromettre tout le modèle économique d'un contrat. La fonction burn() en question était, dans sa forme prévue, une opération administrative routinière. L'exposer sans contrôle d'accès l'a transformée en un vidangeur universel de pool pour tout pool de liquidité détenant SFM.
Les leçons structurelles :
- Les modificateurs d'accès sur chaque fonction externe doivent être revus ligne par ligne, en particulier pendant les mises à niveau. Par défaut, toute opération privilégiée devrait être
onlyOwnerou équivalent ; la charge de la preuve incombe au développeur pour justifier toute fonction qui estpublicouexternalsans restrictions. - Les permissions de fonction devraient être testées explicitement — chaque audit devrait inclure un test « n'importe qui peut appeler ceci » pour chaque chemin privilégié, pas seulement des tests fonctionnels du flux utilisateur prévu.
- Les mises à niveau récentes sont à haut risque pendant les 48-72 premières heures après le déploiement. De nombreux protocoles planifient maintenant des audits post-mise à niveau indépendants ou des primes de bug communautaires avec des paiements élevés pendant la fenêtre post-mise à niveau immédiate.
Le dénouement plus large de SafeMoon — combinant le piratage avec l'application de la SEC et la tokenomique sous-jacente étant largement considérée comme prédatrice — est également un schéma memecoin récurrent : les échecs de sécurité technique, la pression réglementaire et le scepticisme au niveau conception convergent souvent sur les mêmes projets en quelques mois les uns des autres.
Sources & preuves on-chain
- [01]halborn.comhttps://www.halborn.com/blog/post/explained-the-safe-moon-hack-march-2023
- [02]theblock.cohttps://www.theblock.co/post/223547/safemoon-liquidity-pair-compromised-in-8-9-million-hack
- [03]zellic.iohttps://www.zellic.io/blog/safemoon-exploit-explained/