Step Finance : 40 M$ volés et fermeture après une faille OpSec

Le 31 janvier 2026, Step Finance perd 40 M$ via la compromission des devices de son équipe. Le protocole annonce sa fermeture le 24 février 2026.

BlockInfos

09/05/2026

11 Minutes

Logo officiel de la blockchain Solana

Table des matières

L’essentiel : le 31 janvier 2026, Step Finance, plateforme analytique majeure de l’écosystème Solana, est exploitée pour environ 40 M$. La cause : les devices personnels de plusieurs membres de l’équipe exécutive ont été compromis, donnant aux attaquants un accès direct aux wallets de trésorerie et de frais. 261 854 SOL (entre 27 et 30 M$ selon le cours du jour) ont été désynchronisés du staking puis transférés. Solana Token22 et la coopération avec les exchanges ont permis de récupérer environ 4,7 M$, insuffisant pour couvrir les pertes. Le 24 février 2026, Step Finance annonce la fermeture définitive du protocole, ainsi que de ses deux produits associés SolanaFloor et Remora Markets. Le smart contract n’a jamais été en cause : c’est un cas d’école d’OpSec ratée qui rappelle que la sécurité d’un protocole DeFi est aussi celle de son équipe humaine.

Que s’est-il passé le 31 janvier 2026 ?

Step Finance était l’un des dashboards Solana les plus utilisés depuis 2021. La plateforme agrégeait portefeuilles, positions DeFi, NFTs et farming rewards en une interface unique. Pour fonctionner, elle gardait en propre une trésorerie en SOL et stablecoins ainsi qu’un wallet de fees opérationnel.

Le 31 janvier 2026 dans la nuit, des attaquants exécutent une série de transactions depuis ces wallets. Selon crypto.news et l’analyse Halborn, le scénario reconstitué est le suivant :

  • Compromission préalable des devices personnels de plusieurs membres de l’équipe exécutive. Vecteur précis non encore confirmé publiquement (phishing, malware, exfiltration de browser session…).
  • Récupération des clés ou des sessions actives qui contrôlaient les wallets de trésorerie et de fees Solana.
  • Désynchronisation (unstaking) de 261 854 SOL détenus par le protocole.
  • Transferts vers des adresses contrôlées par les attaquants.
  • Réception d’autres tokens et stablecoins de la trésorerie.

Le total au cours du jour : environ 40 M$, dont 27-30 M$ rien que pour les SOL. Le smart contract de Step Finance lui-même n’est jamais touché. Les utilisateurs qui interagissaient avec la plateforme via leurs propres wallets ne perdent rien sur ces wallets : c’est uniquement la trésorerie du projet qui est siphonnée.

La cause : endpoint security, pas smart contract

C’est le point qui distingue Step Finance du hack Truebit du même mois (cf. notre article du 8 janvier sur l’integer overflow). Truebit était un bug de code Solidity. Step Finance est une faille humaine et opérationnelle.

Concrètement, trois types de compromission peuvent expliquer l’accès :

Phishing ciblé. Un mail ou message malveillant fait télécharger un binaire à un dev, qui exfiltre les credentials, sessions browser, et clés stockées localement. Les groupes Lazarus (Corée du Nord) sont connus pour des campagnes d’ingénierie sociale très ciblées sur des équipes crypto, notamment via faux entretiens d’embauche ou faux partenariats.

Compromission de chaîne logicielle. Un dev installe une dépendance npm ou pip malicieuse qui exfiltre les variables d’environnement, ou utilise une extension VSCode/navigateur trojanée. Plusieurs incidents 2024-2025 ont suivi ce schéma.

Phishing de session ou cookie. Le device n’est pas pwned au sens classique, mais un session cookie d’un wallet web ou d’un service cloud (AWS, GitHub) est volé, ce qui permet de bypasser la 2FA pendant la durée de validité de la session.

Dans tous les cas, le smart contract n’est pas le maillon faible. Un audit code-only n’aurait pas détecté la faille. Le problème est en amont : la procédure de signature des transactions de trésorerie, l’isolation des devices, la mise en place ou non d’un multisig avec quorum.

La défense qui aurait pu fonctionner : multisig

Une seule mesure aurait significativement réduit l’impact du hack : un multisig 3-sur-5 ou 4-sur-7 sur la trésorerie. Avec un multisig, compromettre une seule clé ne suffit pas. L’attaquant doit obtenir un quorum d’autorisations, ce qui implique de compromettre simultanément plusieurs membres du staff.

En pratique, beaucoup de protocoles Solana 2021-2024 utilisaient des wallets simples (un seul signataire) pour leur trésorerie, par paresse opérationnelle ou parce que les frameworks multisig sur Solana étaient moins matures qu’Ethereum (Squads Protocol a normalisé le multisig Solana en 2024). Step Finance, lancé en 2021, fait partie de ces protocoles qui n’ont jamais migré.

Pour les bases sur les clés privées et leur compromission, voyez nos guides Comprendre les clés privées et publiques et Protéger vos cryptomonnaies contre les pirates.

Comment 261 854 SOL ont quitté la trésorerie

L’élément le plus visible côté on-chain est le déplacement de 261 854 SOL, qui étaient stakés sur plusieurs validateurs au moment de l’attaque. Le séquencement post-mortem reconstitué :

D’abord, l’attaquant déclenche les transactions de deactivate stake. Les SOL stakés ne sont pas immédiatement disponibles : Solana impose une période de cooldown de quelques jours avant que le SOL puisse être retiré du validateur. Mais en lançant le deactivate dès le 31 janvier, les attaquants positionnent les fonds pour exfiltration dès la fin du cooldown.

Ensuite, les fonds débloqués sont transférés via des intermédiaires (wallets de mixage, swaps inter-DEX, ponts cross-chain comme Wormhole ou DeBridge) pour rendre la traçabilité difficile. Une partie atteint des exchanges centralisés.

C’est à ce stade que Solana Token22 protections entrent en jeu. Token22 est un standard Solana 2024 qui permet à certains tokens (et indirectement aux validateurs et exchanges) d’imposer des contrôles plus stricts sur les transferts. Coordonnée avec les exchanges majeurs, l’équipe Step Finance parvient à geler environ 4,7 M$ sur certains receveurs avant que les fonds ne soient retirés. Le reste, autour de 35 M$, est définitivement perdu.

Pour comprendre les bases du staking sur Solana, voyez Staking : gagner des intérêts en cryptos.

La fermeture du 24 février : Step + SolanaFloor + Remora Markets

Le 24 février 2026, Step Finance publie sur X l’annonce de la fermeture définitive du protocole. La déclaration est nette : les pertes sont trop importantes pour permettre la continuité opérationnelle, malgré les 4,7 M$ récupérés.

Trois produits ferment simultanément :

  • Step Finance : le dashboard analytique principal.
  • SolanaFloor : un agrégateur de données NFT Solana, propriété de Step Finance.
  • Remora Markets : un protocole de trading de NFTs développé par la même équipe.

L’équipe annonce un buyback des tokens STEP encore en circulation et un programme de redemptions progressives sur les wallets utilisateurs encore associés au protocole. Le tout est financé par les actifs résiduels et les 4,7 M$ récupérés.

C’est rare dans la DeFi qu’un projet ferme proprement après un hack : la norme est plutôt l’arrêt brutal sans plan de sortie. Step Finance préserve ce qui peut l’être, mais ne survit pas.

Hack Truebit vs Step Finance : deux pédagogies

Janvier 2026 offre un comparatif quasi parfait entre deux types d’incidents DeFi.

Truebit (8 janvier, 26,4 M$) : faille de code, integer overflow Solidity 0.6.10, contrat non audité. La défense : audit récent, version Solidity moderne, SafeMath, bug bounty, surveillance Slither/Mythril.

Step Finance (31 janvier, 40 M$) : faille humaine, devices compromis, wallet single-sig sur la trésorerie. La défense : multisig, hardware wallets pour les clés sensibles, isolation des devices de signature (machine dédiée air-gapped), procédure de signature multi-personnes.

Pour un utilisateur DeFi, le double exemple est utile. L’audit du code ne suffit pas. La sécurité du protocole dépend aussi de la gouvernance opérationnelle de son équipe : un volet beaucoup moins visible et beaucoup moins audité publiquement.

Que retenir comme utilisateur DeFi

Quatre signaux à vérifier avant de déposer dans un protocole DeFi en 2026.

Multisig sur la trésorerie. Vérifier sur Etherscan, Solscan ou la page « Treasury » du projet que les fonds sont dans un multisig 3-sur-5 ou plus. Un wallet single-sig avec plusieurs millions est un drapeau rouge. Pour Solana, Squads Protocol affiche les multisigs publics.

Composition de l’équipe. Une équipe identifiable, avec des LinkedIns, des contributions GitHub publiques et un historique vérifiable, est plus difficile à compromettre par phishing ciblé qu’une équipe anonyme. Les équipes anonymes ne sont pas automatiquement à fuir, mais elles imposent une vigilance accrue.

Bug bounty actif. Un bug bounty rémunéré sur Immunefi (typiquement 100 k$ à 1 M$+ pour les blue chips) signale une équipe qui prend la sécurité au sérieux. L’absence de bug bounty est un signal négatif.

Procédure de gouvernance affichée. Les meilleurs protocoles publient leur process de signature de transactions, leurs SLOs en cas d’incident, leur plan de remediation. C’est rare mais ça progresse : Aave, Lido, Optimism le font.

Pour les bases de la sécurité crypto utilisateur, voyez nos guides Utiliser son hardware wallet en toute sécurité, Se protéger des différents types de hack et 6 conseils pour sécuriser vos actifs.

Step Finance peut-elle revenir après la fermeture ?

Très improbable. L’équipe a explicitement annoncé une fermeture définitive le 24 février 2026 et lance des buybacks pour solder le projet. Une renaissance demanderait une recapitalisation extérieure (peu probable après un hack à 40 M$) et un re-audit complet. Les utilisateurs doivent considérer que les positions Step Finance sont closes.

Mes propres SOL stockés dans mon wallet sont-ils touchés ?

Non, sauf si vous aviez délégué vos SOL à un validateur lié à Step Finance. Le hack a ciblé les wallets de trésorerie du protocole, pas les wallets utilisateurs. Pour vérifier, connectez votre Phantom ou Solflare à des explorateurs comme Solscan et identifiez vos délégations actives. Si tout pointe vers des validateurs autres que Step, vous êtes safe.

Comment Solana Token22 a-t-il aidé à récupérer 4,7 M$ ?

Token22 est un standard Solana 2024 qui permet d’imposer des règles avancées sur les transferts (gel, blacklist, KYC). Couplé à la coopération des exchanges centralisés (Binance, Coinbase, Kraken) qui ont gelé les adresses identifiées, l’équipe Step Finance a pu bloquer une partie des fonds avant qu’ils ne sortent en fiat. Le mécanisme rappelle ce qui s’est fait pour le hack Ronin Bridge en 2022.

Quelle différence entre cette attaque et un exploit smart contract classique ?

Un exploit smart contract (comme Truebit le 8 janvier) cible une faille dans le code on-chain : reentrancy, integer overflow, oracle manipulation, etc. Un audit code-only peut le détecter. Le hack Step Finance cible l’OpSec humaine de l’équipe (devices compromis, accès aux clés). Aucun audit code n’aurait pu prévenir ce vecteur. La défense passe par multisig, hardware wallets, isolation des devices de signature, procédures de gouvernance multi-personnes.

Y a-t-il eu attribution de l’attaque ?

À la date de cet article, aucune attribution claire n’a été établie publiquement. Le mode opératoire (compromission ciblée de devices d’équipe crypto, exfiltration via mixers et exchanges) ressemble à plusieurs campagnes attribuées à Lazarus (DPRK), mais ce n’est pas confirmé. Le rapport Chainalysis annuel de janvier 2027 pourra apporter plus d’éléments si une attribution se précise.

Comment se prémunir personnellement contre ce type d’attaque ?

Pour un utilisateur retail, l’analogue du hack Step Finance est la compromission de votre device personnel. Quatre réflexes : utiliser un hardware wallet (Ledger, Trezor, NGRAVE) pour signer les transactions importantes, isoler le device de signature (idéalement une machine dédiée), ne jamais cliquer sur des liens reçus en DM, et activer 2FA hardware (YubiKey) sur les comptes exchanges et email associés.

Ce que ce double choc janvier nous apprend sur 2026

Truebit (8 janvier, smart contract bug) puis Step Finance (31 janvier, OpSec failure) ouvrent l’année avec deux messages distincts mais convergents : la sécurité DeFi en 2026 ne dépend plus seulement du code.

Pour les développeurs, les leçons sont claires : audit récent + Solidity moderne + multisig + hardware wallets pour la trésorerie + procédures de signature multi-personnes + bug bounty + isolation des devices. Aucune de ces mesures ne suffit isolément ; toutes en cumulé réduisent significativement la surface d’attaque.

Pour les utilisateurs, la conclusion est plus directe : diversifier son exposition plutôt que de tout concentrer sur un protocole. Les blue chips comme Aave, Lido, Uniswap, Compound ont survécu aux cycles 2018, 2020, 2022 grâce à des équipes paranoïaques et des trésoreries en multisigs ultra-redondants. C’est cette robustesse qui justifie leur prime de risque par rapport aux nouveaux entrants.

Pour aller plus loin, voyez aussi notre article sur le DeFi reboot Ethereum/Solana qui détaille la maturation des écosystèmes en 2026.