#两地址约12.8亿枚USDT遭冻结
Vérifiez vite vos adresses. Comme sur l’image 1, si vous transférez des BNB depuis le portefeuille web d’OKX et que vous voyez « EIP‑7702 », « set code » ou « delegation », n’allez pas plus loin : transférez les actifs de valeur vers un nouveau portefeuille. Les portefeuilles chauds restent dangereux, même sans autorisation ni fuite de clé privée ou de phrase de récupération. Le principe, c’est qu’après une transaction effectuée depuis un portefeuille chaud, vous pouvez autoriser sans vous en rendre compte un contrat de délégation 7702. Après tout, Xu, le patron d’OKX, est issu du milieu technique.
Ne mettez pas à niveau votre portefeuille chaud à la légère. Des escrocs se font passer pour des services de « mise à niveau du portefeuille », de « Gas gratuit », d’« activation de compte » ou de « portefeuille IA » et vous font signer une délégation EIP‑7702. Une fois la signature obtenue, le portefeuille est lié à un contrat de vidage préparé par les pirates. Dès que des fonds arrivent sur le portefeuille, ils sont automatiquement transférés. Aucune autre signature de votre part n’est nécessaire : les fonds sont dérobés en silence, sans même que vous vous rendiez compte de ce qui s’est passé.
Si le paramètre chain_id est défini sur 0 lors de la signature d’une transaction, cette signature de délégation prend effet sur toutes les chaînes EVM.
Si une chaîne est compromise, les actifs associés à cette adresse sur toutes les chaînes — BSC, Polygon, ETH, etc. — sont également en danger. Si la logique d’initialisation est mal conçue, quelqu’un peut soumettre votre signature d’autorisation avant vous, détourner votre délégation et prendre le contrôle de votre compte.
De nombreux portefeuilles affichent de très mauvaises fenêtres de confirmation. Les utilisateurs ordinaires ne comprennent pas qu’il ne s’agit pas d’une transaction ordinaire et ne voient pas qu’il s’agit d’une autorisation de délégation au niveau du compte : ils risquent donc facilement de signer par erreur.
Les utilisateurs ordinaires ne font pas la différence entre une « signature ordinaire » et un « tuple d’autorisation EIP‑7702 » et pensent qu’il suffit de confirmer la fenêtre pour se faire piéger. Même si vous avez la clé privée, le risque persiste tant que la délégation n’a pas été supprimée.
Vous pouvez toujours signer des transactions avec votre clé privée, mais la logique du contrat de délégation est prioritaire. Si les pirates ont programmé un mécanisme de vidage automatique, ils peuvent vider votre compte automatiquement. Le risque ne disparaît que si vous signez une nouvelle délégation dont la cible est l’adresse zéro, afin de supprimer la délégation et de la révoquer.
Même dans le cas d’un projet légitime, un bug dans le code du contrat de délégation peut permettre à un attaquant d’exploiter une faille et de prendre le contrôle du compte, entraînant tout autant la perte des fonds.
Vérifiez vite vos adresses. Comme sur l’image 1, si vous transférez des BNB depuis le portefeuille web d’OKX et que vous voyez « EIP‑7702 », « set code » ou « delegation », n’allez pas plus loin : transférez les actifs de valeur vers un nouveau portefeuille. Les portefeuilles chauds restent dangereux, même sans autorisation ni fuite de clé privée ou de phrase de récupération. Le principe, c’est qu’après une transaction effectuée depuis un portefeuille chaud, vous pouvez autoriser sans vous en rendre compte un contrat de délégation 7702. Après tout, Xu, le patron d’OKX, est issu du milieu technique.
Ne mettez pas à niveau votre portefeuille chaud à la légère. Des escrocs se font passer pour des services de « mise à niveau du portefeuille », de « Gas gratuit », d’« activation de compte » ou de « portefeuille IA » et vous font signer une délégation EIP‑7702. Une fois la signature obtenue, le portefeuille est lié à un contrat de vidage préparé par les pirates. Dès que des fonds arrivent sur le portefeuille, ils sont automatiquement transférés. Aucune autre signature de votre part n’est nécessaire : les fonds sont dérobés en silence, sans même que vous vous rendiez compte de ce qui s’est passé.
Si le paramètre chain_id est défini sur 0 lors de la signature d’une transaction, cette signature de délégation prend effet sur toutes les chaînes EVM.
Si une chaîne est compromise, les actifs associés à cette adresse sur toutes les chaînes — BSC, Polygon, ETH, etc. — sont également en danger. Si la logique d’initialisation est mal conçue, quelqu’un peut soumettre votre signature d’autorisation avant vous, détourner votre délégation et prendre le contrôle de votre compte.
De nombreux portefeuilles affichent de très mauvaises fenêtres de confirmation. Les utilisateurs ordinaires ne comprennent pas qu’il ne s’agit pas d’une transaction ordinaire et ne voient pas qu’il s’agit d’une autorisation de délégation au niveau du compte : ils risquent donc facilement de signer par erreur.
Les utilisateurs ordinaires ne font pas la différence entre une « signature ordinaire » et un « tuple d’autorisation EIP‑7702 » et pensent qu’il suffit de confirmer la fenêtre pour se faire piéger. Même si vous avez la clé privée, le risque persiste tant que la délégation n’a pas été supprimée.
Vous pouvez toujours signer des transactions avec votre clé privée, mais la logique du contrat de délégation est prioritaire. Si les pirates ont programmé un mécanisme de vidage automatique, ils peuvent vider votre compte automatiquement. Le risque ne disparaît que si vous signez une nouvelle délégation dont la cible est l’adresse zéro, afin de supprimer la délégation et de la révoquer.
Même dans le cas d’un projet légitime, un bug dans le code du contrat de délégation peut permettre à un attaquant d’exploiter une faille et de prendre le contrôle du compte, entraînant tout autant la perte des fonds.
