Contenu éditorial de confiance, revu par des experts de l'industrie et des éditeurs expérimentés. Divulgation des annonces
Le développeur principal de Shiba Inu, Kaal Dhairya, a publié une mise à jour de sécurité détaillée suite à l'incident du 12 septembre qui a exploité le pouvoir de signature des validateurs sur le pont PoS de Shibarium pour pousser un état/de sortie malveillant et retirer plusieurs actifs. Le post, publié le 21 septembre 2025, décrit ce qui s'est passé, ce qui a été fait jusqu'à présent et ce qui régira une restauration par étapes une fois les examens indépendants conclus.
Les développeurs principaux de Shiba Inu partagent une nouvelle mise à jour
Dans une préface personnelle qui a cadré à la fois les dimensions techniques et humaines de l'épisode, Dhairya a commencé par se distancer de tout manteau de leadership singulier et a réaffirmé l'éthique originale qui motive son travail. "Je veux clarifier d'abord : je ne suis pas 'le leader'. Je ne l'ai jamais été et je ne veux jamais l'être. Je suis juste un constructeur qui a parié sur l'éthique de SHIB," a-t-il écrit, ajoutant que "dans des moments comme ceux-ci, on réalise qu'on n'a peut-être été qu'un pion dans tout le jeu."
Le développeur principal de Shiba Inu a averti que, compte tenu "de la sophistication de cette attaque", il ne pouvait actuellement garantir la sécurité des clés existantes, et il a exprimé sa fatigue face aux attentes selon lesquelles les contributeurs individuels pourraient "maintenir le tout ensemble" sans un soutien structurel plus large.
Lecture Connue : L'équipe Shiba Inu Publie une Mise à Jour Explosive Sur l'Exploitation du Pont Shibarium. Le compte rendu de l'incident décrit comment, à 18h44 UTC le 12 septembre, "le pouvoir de signature de validateur non autorisé a été utilisé pour pousser un état/sortie malveillant à travers le pont PoS." La méthode, selon la mise à jour, combinait une amplification de mise de courte durée avec des preuves de point de contrôle/sortie malveillantes pour autoriser les retraits. L'activité on-chain post-incident liée à l'attaquant serait composée de ventes de portions d'ETH, SHIB et ROAR, bien que l'équipe retienne le "graphique de portefeuille évolutif" pendant que la containment et la coordination avec les autorités se poursuivent. "Nous publierons le récit technique complet après que cela n'augmente plus le risque," indique le post.
Les mesures immédiates comprennent la restriction de certaines opérations de pont pour prévenir de nouvelles sorties non autorisées, la mise à niveau et le contrôle des voies contractuelles couvrant les dépôts, les retraits, les réclamations et les récompenses, ainsi que l'application de "contrôles défensifs ciblés contre l'utilisation abusive de la participation déléguée". L'équipe indique qu'elle a récupéré et sécurisé le BONE à risque au niveau du gestionnaire de participation et note que toute participation à court terme de BONE sous l'attaquant reste "effectivement immobilisée" par des interventions et des mécanismes de protocole.
Les étapes de l'hygiène des clés et de la garde ont impliqué la rotation des signataires de validateurs et la migration du contrôle des contrats vers une garde matérielle multiparty, tandis que la surveillance en direct et les alertes automatisées se poursuivent en coordination avec les échanges, les chercheurs en sécurité externes, les entreprises de réponse aux incidents et les autorités compétentes.
La mise à jour aborde également les questions fréquemment posées concernant le compromis des validateurs et la responsabilité opérationnelle. Elle indique que les clés de signature des validateurs étaient « principalement stockées dans AWS KMS, avec une utilisation rare sur les machines des développeurs », et que la responsabilité ultime de la gestion des clés incombe à la direction opérationnelle. Bien qu'un vecteur d'intrusion unique n'ait pas été confirmé, les possibilités préliminaires incluent un compromis d'une machine de développeur, un compromis de cloud KMS, une exposition lors d'une migration d'AWS vers GCP, ou une attaque de la chaîne d'approvisionnement, comme via npm.
Le post reconnaît les lacunes de la décentralisation soulignées par le fait que « 10 des 12 validateurs » ont signé l'état malveillant, et il s'engage à une plus grande décentralisation des validateurs, une politique de rotation des clés plus stricte, une garde plus rigoureuse, des divulgations améliorées et des seuils de diligence raisonnable plus élevés pour un accès sensible.
Lecture connexe : Les taureaux de Shiba Inu sont de retour : voici l'accumulation de 512 milliards de SHIB qui a déclenché une étincelle. Un aperçu de la feuille de route expose quatre phases Gated. La « Contention » reste en cours avec une fonctionnalité de pont restreinte et une surveillance en direct ; la « Durcissement », en collaboration avec Hexens, comprend l'hygiène des signataires/validateurs, des contrôles au niveau des politiques tels que des limites de taux, des fenêtres de défi et des coupe-circuits, et des extensions de liste de refus là où cela est techniquement approprié.
Ensuite, la « restauration sécurisée » ne commencera pas tant que les revues indépendantes n'auront pas validé les mesures d'atténuation, que les contrôles d'intégrité post-incident auront réussi et que les exercices sur les environnements de test auront été concluants, avec une restauration exécutée par phases et avec des leviers de retour en arrière ; enfin, un post-mortem technique complet précédera un chemin de remédiation examiné par la communauté pour les utilisateurs et la liquidité affectés, avec la mise à jour notant que « les approches spécifiques aux jetons peuvent différer. »
Les délais restent intentionnellement non spécifiés : « Nous ne publierons pas de dates qui pourraient être manipulées par un adversaire », écrit l'équipe, réitérant que les mises à jour seront publiées sur les canaux officiels.
Pour les détenteurs de jetons Shiba Inu et les victimes, le message est clair : méfiez-vous des escroqueries, ignorez les "portails de récupération/revendication" non vérifiés et attendez-vous à ce que les restrictions de pont persistent "jusqu'à ce que nous confirmions qu'il est sûr de restaurer." Les questions concernant le retour à Ethereum, le calendrier de reprise du pont, la rotation des validateurs et l'audit complet reçoivent toutes la même réponse : la sécurité d'abord, les détails suivront lorsque la sécurité le permettra. Concernant la récupération des fonds et la compensation potentielle, l'équipe indique que des options sont à l'étude et qu'une proposition sera publiée pour examen par la communauté "une fois viable et sécurisée."
Le développeur de Shiba Inu conclut en réaffirmant les priorités et en situant la communication dans un rythme discipliné. "Nos priorités restent inchangées : protéger les utilisateurs, sécuriser le réseau, contenir l'attaquant et restaurer les services en toute sécurité." La prochaine communication majeure, écrit-il, sera le rapport technique post-mortem et une proposition de remédiation "une fois que l'environnement sera sûr pour une divulgation complète."
Au moment de la presse, Shiba Inu se négociait à 0,00001207 $.
La tendance baissière du prix de Shiba Inu se poursuit, graphique sur 1 semaine | Source : SHIBUSDT sur TradingView.comImage mise en avant créée avec DALL.E, graphique provenant de TradingView.com
Le processus éditorial de bitcoinist est axé sur la livraison de contenu soigneusement recherché, précis et impartial. Nous maintenons des normes de sourcing strictes, et chaque page fait l'objet d'une révision diligent par notre équipe de meilleurs experts en technologie et d'éditeurs expérimentés. Ce processus garantit l'intégrité, la pertinence et la valeur de notre contenu pour nos lecteurs.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Shiba Inu Dev publie une nouvelle mise à jour de sécurité sur le pont Shibarium
Les développeurs principaux de Shiba Inu partagent une nouvelle mise à jour
Dans une préface personnelle qui a cadré à la fois les dimensions techniques et humaines de l'épisode, Dhairya a commencé par se distancer de tout manteau de leadership singulier et a réaffirmé l'éthique originale qui motive son travail. "Je veux clarifier d'abord : je ne suis pas 'le leader'. Je ne l'ai jamais été et je ne veux jamais l'être. Je suis juste un constructeur qui a parié sur l'éthique de SHIB," a-t-il écrit, ajoutant que "dans des moments comme ceux-ci, on réalise qu'on n'a peut-être été qu'un pion dans tout le jeu."
Le développeur principal de Shiba Inu a averti que, compte tenu "de la sophistication de cette attaque", il ne pouvait actuellement garantir la sécurité des clés existantes, et il a exprimé sa fatigue face aux attentes selon lesquelles les contributeurs individuels pourraient "maintenir le tout ensemble" sans un soutien structurel plus large.
Lecture Connue : L'équipe Shiba Inu Publie une Mise à Jour Explosive Sur l'Exploitation du Pont Shibarium. Le compte rendu de l'incident décrit comment, à 18h44 UTC le 12 septembre, "le pouvoir de signature de validateur non autorisé a été utilisé pour pousser un état/sortie malveillant à travers le pont PoS." La méthode, selon la mise à jour, combinait une amplification de mise de courte durée avec des preuves de point de contrôle/sortie malveillantes pour autoriser les retraits. L'activité on-chain post-incident liée à l'attaquant serait composée de ventes de portions d'ETH, SHIB et ROAR, bien que l'équipe retienne le "graphique de portefeuille évolutif" pendant que la containment et la coordination avec les autorités se poursuivent. "Nous publierons le récit technique complet après que cela n'augmente plus le risque," indique le post.
Les mesures immédiates comprennent la restriction de certaines opérations de pont pour prévenir de nouvelles sorties non autorisées, la mise à niveau et le contrôle des voies contractuelles couvrant les dépôts, les retraits, les réclamations et les récompenses, ainsi que l'application de "contrôles défensifs ciblés contre l'utilisation abusive de la participation déléguée". L'équipe indique qu'elle a récupéré et sécurisé le BONE à risque au niveau du gestionnaire de participation et note que toute participation à court terme de BONE sous l'attaquant reste "effectivement immobilisée" par des interventions et des mécanismes de protocole.
Les étapes de l'hygiène des clés et de la garde ont impliqué la rotation des signataires de validateurs et la migration du contrôle des contrats vers une garde matérielle multiparty, tandis que la surveillance en direct et les alertes automatisées se poursuivent en coordination avec les échanges, les chercheurs en sécurité externes, les entreprises de réponse aux incidents et les autorités compétentes.
La mise à jour aborde également les questions fréquemment posées concernant le compromis des validateurs et la responsabilité opérationnelle. Elle indique que les clés de signature des validateurs étaient « principalement stockées dans AWS KMS, avec une utilisation rare sur les machines des développeurs », et que la responsabilité ultime de la gestion des clés incombe à la direction opérationnelle. Bien qu'un vecteur d'intrusion unique n'ait pas été confirmé, les possibilités préliminaires incluent un compromis d'une machine de développeur, un compromis de cloud KMS, une exposition lors d'une migration d'AWS vers GCP, ou une attaque de la chaîne d'approvisionnement, comme via npm.
Le post reconnaît les lacunes de la décentralisation soulignées par le fait que « 10 des 12 validateurs » ont signé l'état malveillant, et il s'engage à une plus grande décentralisation des validateurs, une politique de rotation des clés plus stricte, une garde plus rigoureuse, des divulgations améliorées et des seuils de diligence raisonnable plus élevés pour un accès sensible.
Lecture connexe : Les taureaux de Shiba Inu sont de retour : voici l'accumulation de 512 milliards de SHIB qui a déclenché une étincelle. Un aperçu de la feuille de route expose quatre phases Gated. La « Contention » reste en cours avec une fonctionnalité de pont restreinte et une surveillance en direct ; la « Durcissement », en collaboration avec Hexens, comprend l'hygiène des signataires/validateurs, des contrôles au niveau des politiques tels que des limites de taux, des fenêtres de défi et des coupe-circuits, et des extensions de liste de refus là où cela est techniquement approprié.
Ensuite, la « restauration sécurisée » ne commencera pas tant que les revues indépendantes n'auront pas validé les mesures d'atténuation, que les contrôles d'intégrité post-incident auront réussi et que les exercices sur les environnements de test auront été concluants, avec une restauration exécutée par phases et avec des leviers de retour en arrière ; enfin, un post-mortem technique complet précédera un chemin de remédiation examiné par la communauté pour les utilisateurs et la liquidité affectés, avec la mise à jour notant que « les approches spécifiques aux jetons peuvent différer. »
Les délais restent intentionnellement non spécifiés : « Nous ne publierons pas de dates qui pourraient être manipulées par un adversaire », écrit l'équipe, réitérant que les mises à jour seront publiées sur les canaux officiels.
Pour les détenteurs de jetons Shiba Inu et les victimes, le message est clair : méfiez-vous des escroqueries, ignorez les "portails de récupération/revendication" non vérifiés et attendez-vous à ce que les restrictions de pont persistent "jusqu'à ce que nous confirmions qu'il est sûr de restaurer." Les questions concernant le retour à Ethereum, le calendrier de reprise du pont, la rotation des validateurs et l'audit complet reçoivent toutes la même réponse : la sécurité d'abord, les détails suivront lorsque la sécurité le permettra. Concernant la récupération des fonds et la compensation potentielle, l'équipe indique que des options sont à l'étude et qu'une proposition sera publiée pour examen par la communauté "une fois viable et sécurisée."
Le développeur de Shiba Inu conclut en réaffirmant les priorités et en situant la communication dans un rythme discipliné. "Nos priorités restent inchangées : protéger les utilisateurs, sécuriser le réseau, contenir l'attaquant et restaurer les services en toute sécurité." La prochaine communication majeure, écrit-il, sera le rapport technique post-mortem et une proposition de remédiation "une fois que l'environnement sera sûr pour une divulgation complète."
Au moment de la presse, Shiba Inu se négociait à 0,00001207 $.