La faille du bot Polycule expose des lacunes critiques : pourquoi les bots de trading Telegram restent des cibles à haut risque

La perte de 230 000 $ qui a secoué les marchés de prédiction

Le 13 janvier 2026, le bot de trading Polycule a subi une compromission majeure — des attaquants ont réussi à extraire environ 230 000 $ des utilisateurs sur le réseau Polygon. L’incident n’était pas qu’un simple bug mineur ; il représentait précisément le type de vulnérabilité systémique dont les chercheurs en sécurité alertent depuis longtemps dans l’écosystème des bots Telegram. En quelques heures, Polycule a mis le bot hors ligne et mobilisé son équipe pour développer un correctif, bien que le dommage à la confiance des utilisateurs ait déjà été fait. Cet événement a cristallisé une vérité difficile : la commodité dans le trading a un coût de sécurité élevé.

Comment Polycule a rendu le trading accessible (Et où il a créé des vulnérabilités)

Polycule s’est positionné comme le pont entre l’interface de chat sans friction de Telegram et le trading de prédiction de Polymarket. Son attrait était simple — les utilisateurs pouvaient gérer leurs positions, vérifier leurs soldes et exécuter des trades sans quitter leur application de messagerie. L’architecture du bot comprenait :

• Génération de portefeuille à la première utilisation - Lorsqu’un utilisateur lançait /start, le système créait automatiquement un portefeuille Polygon et stockait sa clé privée côté serveur
• Interaction directe avec le marché - Des commandes comme /trending et /search récupéraient des données en direct de Polymarket ; coller des URLs déclenchait une analyse instantanée du marché
• Gestion des fonds - La fonction /wallet permettait aux utilisateurs de voir leurs actifs, d’effectuer des retraits, et surtout, d’exporter directement leurs clés privées
• Intégration de ponts cross-chain - Le partenariat avec deBridge permettait des transferts Solana-vers-Polygon avec une conversion automatique de 2 % en SOL pour les frais de Gas
• Mécanismes de copy trading - Les utilisateurs pouvaient cloner des trades à partir de portefeuilles cibles par pourcentage, montant fixe ou déclencheurs personnalisés

Chaque fonctionnalité apportait de la commodité mais élargissait aussi la surface d’attaque. Le rôle du bot signifiait qu’il détenait constamment des clés, analysait des entrées externes, signait des transactions en arrière-plan, et écoutait les événements on-chain — le tout sans étapes de confirmation locale de l’utilisateur.

Les trois vulnérabilités structurelles derrière cette attaque

1. Clés privées stockées et gérées côté serveur

C’est toujours la faiblesse fondamentale. Les applications de portefeuille traditionnelles conservent les clés privées sur les appareils des utilisateurs ; Polycule (comme la plupart des bots Telegram) les stockait de manière centralisée. La logique : permettre un trading sans mot de passe, fluide, basé sur Telegram. Le compromis : un serveur compromis expose tout le portefeuille.

L’incident Polycule suggère fortement que les attaquants ont exploité cette architecture. S’ils ont obtenu un accès backend via injection SQL, mauvaises configurations ou exploits d’API, ils pouvaient appeler la même fonction /wallet export sur le backend que les utilisateurs légitimes — mais cette fois pour extraire en masse toutes les clés stockées.

2. Authentification entièrement liée au contrôle du compte Telegram

Les utilisateurs s’authentifient via Telegram lui-même — pas de phrases de récupération, pas de confirmations matérielles. Cela crée un risque subtil mais sérieux : si un attaquant effectue un échange de SIM ou accède à l’appareil, il peut prendre le contrôle du compte du bot sans jamais avoir besoin de la phrase mnémotechnique. Le bot devient alors une machine à voler en libre-service pour l’attaquant.

3. Exécution silencieuse sans confirmation de l’utilisateur

Les portefeuilles traditionnels (MetaMask, Ledger) exigent une approbation explicite pour chaque transaction. Les bots Telegram, par conception, sautent cette étape — le bot décide et exécute. Cela signifie qu’une faille dans la logique backend, une interaction avec un contrat malveillant ou une usurpation d’événements pourrait vider les fonds sans que l’utilisateur ne voie jamais une boîte de dialogue de confirmation. Le copy trading devient particulièrement risqué : si le mécanisme d’écoute est empoisonné ou si le portefeuille cible forge des événements, les followers pourraient être entraînés dans des rug pulls ou des exploits.

Les vecteurs d’attaque spécifiques révélés par l’incident Polycule

Abus de l’interface d’exportation de clés privées - La commande /wallet capable d’exporter les clés à la demande indique que du matériel clé réversible existe dans la base de données. Une injection SQL, des bypass d’autorisation ou un vol d’identifiants ciblant les panneaux d’administration pourraient exposer cette interface.

Analyse d’URL menant à des exploits côté serveur - Polycule encourageait les utilisateurs à soumettre des liens Polymarket pour obtenir des détails de marché. Une insuffisance dans la sanitation des entrées pourrait permettre aux attaquants de créer des URLs pointant vers des IP internes, des endpoints de métadonnées cloud ou des payloads intégrés, menant à des fuites d’identifiants ou de clés API.

Signaux de copy-trading falsifiés - Si le bot écoute des événements on-chain sans vérification rigoureuse de la source, des attaquants pourraient diffuser de fausses activités de portefeuille, incitant les followers à exécuter des trades non intentionnels contre des contrats malveillants.

Logique de conversion de devises non sécurisée - La conversion automatique SOL en POL pour le pontage implique des slippages, des oracles et des autorisations. L’absence de validation des paramètres pourrait gonfler les pertes ou mal allouer les budgets Gas, aggravant ainsi le dommage financier.

Ce que cela signifie pour les utilisateurs dès maintenant

Actions immédiates :

• Ne pas faire confiance à un seul bot avec de gros fonds pendant sa période de récupération
• Considérer les bots de trading Telegram comme des outils de commodité pour de petites positions uniquement, pas comme des dépôts de richesse
• Activer l’authentification à deux facteurs de Telegram et utiliser un appareil dédié à votre compte
• Supposer que tout bot stockant votre clé privée côté serveur constitue un risque de sécurité, peu importe la réputation du projet
• Retirer fréquemment les profits plutôt que de laisser leur accumulation

Décisions à moyen terme :

• Attendre des audits techniques publics et des engagements de sécurité détaillés avant de redéposer le principal
• Vérifier que l’équipe du bot a mis en place des confirmations secondaires, des limites de retrait, et des contrôles d’accès par niveaux
• Vérifier si le projet a open-sourcé des composants clés ou invité des audits de sécurité indépendants

Ce que les équipes de projet doivent faire pour regagner la confiance

Au-delà des excuses et de la compensation des utilisateurs affectés, les développeurs doivent :

• Commander des audits techniques complets axés sur le stockage des clés, l’isolation des permissions, la validation des entrées et la logique cross-chain avant de relancer
• Mettre en œuvre des contrôles par niveaux — définir des limites de retrait quotidiennes, exiger des confirmations secondaires pour les transactions importantes, utiliser des portefeuilles matériels pour la signature côté serveur
• Reconcevoir l’authentification — s’éloigner d’une authentification purement Telegram ; introduire une authentification à deux facteurs optionnelle pour les opérations sensibles
• Isoler les interactions avec deBridge — ajouter une confirmation explicite de l’utilisateur pour les swaps cross-chain, afficher clairement les frais/slippages
• Publier les progrès en sécurité — partager ce qui a été corrigé, quels audits ont été réalisés, et quelles surveillances sont en place

Le schéma plus large : pourquoi les bots Telegram attirent les attaquants

Les bots Telegram sont devenus la porte d’entrée vers le trading crypto — ils abaissent considérablement la barrière à l’entrée. Mais ce sont aussi des cibles concentrées : une brèche affecte des milliers d’utilisateurs simultanément, et les attaquants savent que les clés privées sont probablement stockées de manière centralisée. Cela en fait une cible de plus en plus attractive pour des acteurs malveillants sophistiqués.

La faille Polycule ne sera probablement pas la dernière. Les projets entrant dans cet espace doivent traiter la sécurité non pas comme une réflexion après coup, mais comme une exigence essentielle du produit dès le départ. Les utilisateurs, quant à eux, doivent maintenir un scepticisme sain : la commodité et la sécurité sont en tension. Un trader basé sur un chat qui ne demande jamais de confirmation devient aussi un auto-payer basé sur le chat s’il est compromis.

Attendez-vous à ce que l’écosystème des marchés de prédiction et des bots Telegram mûrisse — mais attendez aussi que les attaquants évoluent en parallèle.