Le ver Zero-Click de WeChat a pris le contrôle des téléphones en appelant

La vulnérabilité WeChat zero-click montrée par Calif Research en septembre 2026 était une démonstration de recherche, et non une attaque confirmée dans la nature. Elle utilisait un appel WeChat entrant provenant d’un contact pour déclencher une exécution de code à distance dans la pile VoIP de l’application, sans toucher l’écran, cliquer, ouvrir un message ou répondre à l’appel. Tencent affirme avoir déployé un correctif côté serveur, et Calif indique que les versions corrigées de l’application l’ont atténuée.

Ce que la vulnérabilité WeChat zero-click faisait réellement

Calif Research a publié son article « WeWorm » le 8 septembre 2026, décrivant une faille capable de se propager comme un ver dans le code de gestion des appels de WeChat. La cible n’avait pas besoin de répondre. L’appel entrant à lui seul suffisait pour que le composant vulnérable de l’application traite des données et, dans la démo, exécute du code contrôlé par l’attaquant au sein de WeChat.

Cette distinction est importante. Une attaque normale de phishing ou par lien malveillant vous demande de faire quelque chose : cliquer, approuver, installer, ouvrir, scanner ou vous connecter. Un exploit zero-click abuse du traitement automatique, ce travail discret en arrière-plan qu’une application effectue lorsqu’elle reçoit un appel, un message, un aperçu, un fichier ou une notification.

Le problème signalé était une vulnérabilité de corruption de mémoire dans la pile VoIP de WeChat. En termes simples, la fonction d’appel gérait mal les données d’une manière qui pouvait permettre à un attaquant de sortir du fonctionnement prévu de l’application et d’exécuter des commandes contre WeChat lui-même. Calif a déclaré que Tencent avait confirmé le 4 septembre 2026 que la faille pouvait être exploitée pour une exécution de commandes à distance.

Il ne faut toutefois pas l’exagérer. Plusieurs rapports ont indiqué que la démo donnait le contrôle du compte WeChat : lecture et envoi de messages, appels, et actions au nom de l’utilisateur. Elle ne prouvait pas, à elle seule, une prise de contrôle complète du téléphone. Calif a indiqué qu’une prise de contrôle de l’appareil nécessiterait d’enchaîner la faille de l’application avec d’autres vulnérabilités Android ou iOS.

Pourquoi un ver basé sur les appels est plus dangereux qu’un mauvais lien

Une faille exploitable dans une application de communication est redoutable parce qu’elle peut utiliser la confiance comme carburant. Si votre compte est compromis, l’attaquant n’a pas besoin d’appeler à froid des inconnus. Il peut appeler vos contacts WeChat en se faisant passer pour vous, depuis un compte qu’ils connaissent déjà.

La démo de Calif utilisait trois téléphones de test et montrait une propagation d’un Android Pixel 10a vers un iPhone 17e, puis de nouveau vers un Android Pixel 10a. Le compte compromis appelait le compte de la victime suivante. Petite chaîne de laboratoire. Grande implication.

Le hic, selon les rapports, était que l’appelant devait figurer dans la liste d’amis ou de contacts WeChat de la victime. Cela semble rassurant jusqu’à ce que l’on fasse le calcul du graphe social. Si un compte compromis a 80 contacts joignables, et que seulement 10 pour cent sont joignables et vulnérables lors d’une vague donnée, cela fait huit nouveaux comptes ; répétez cela deux fois et vous obtenez 64 comptes potentiels pour l’étape suivante, avant même de tenir compte du filtrage anti-spam, des limites de débit ou de la détection côté serveur.

LIRE  WebAuthn Mobile : connexion biométrique sans mot de passe

Les systèmes réels sont plus désordonnés. Les gens sont hors ligne, les applications diffèrent selon les versions, et les plateformes isolent les applications différemment. Pourtant, ce calcul approximatif explique pourquoi les équipes de sécurité réagissent fortement au terme « capable de se propager comme un ver », même lorsqu’aucune exploitation publique n’a été confirmée.

La chronologie de 2026 : signalement, correctifs, correctif côté serveur

Le dossier public est inhabituellement précis à certains endroits et mince à d’autres. Calif a déclaré que son équipe d’ingénierie a eu connaissance de la faille dans la pile VoIP de WeChat le 23 juillet 2026 et l’a signalée à Tencent le 24 juillet. Il a également indiqué que ses comptes WeChat ont été bannis du 25 au 28 juillet et rétablis le 29 juillet.

Selon Calif, le premier exploit d’exécution de code à distance sur Android a été achevé le 30 juillet 2026, suivi d’un exploit iOS le 2 août. La démonstration soignée du ver multiplateforme a été terminée le 11 août. The Hacker News a rapporté que Calif avait testé sur WeChat 8.0.76 pour Android et 8.0.75 pour iOS, sur iOS 26.6 et sur certaines anciennes versions d’Android.

Tencent a publié WeChat Android 8.0.77 et iOS 8.0.76 le 21 août 2026. Calif a indiqué que ces versions atténuaient la faille. Calif a ensuite déclaré avoir confirmé le 28 août que Tencent avait atténué l’exploit côté serveur pour tous les utilisateurs.

Date en 2026 Événement Contexte source
23 juillet L’équipe de Calif a eu connaissance de la faille VoIP de WeChat Compte Calif
24 juillet Faille soumise à Tencent Compte Calif
2 août exploit iOS RCE terminé après l'exploit Android du 30 juillet Compte Calif
21 août WeChat Android 8.0.77 et iOS 8.0.76 publiés Calif a déclaré que ceux-ci atténuaient le problème
28 août Atténuation côté serveur confirmée par Calif Compte Calif
8 septembre Recherche et démo de WeWorm publiées Calif ; également couvert par The Hacker News et Help Net Security
9 septembre Tencent a déclaré que le correctif côté serveur avait été déployé et qu'aucune exploitation dans la nature n'avait été trouvée Rapport du South China Morning Post

Un détail gênant subsiste : The Hacker News a indiqué que, au 8 septembre 2026, il n'avait trouvé ni identifiant CVE ni avis de réponse de sécurité de Tencent. Il a également rapporté que la fiche iOS App Store de Tencent décrivait la mise à jour uniquement comme des corrections de bugs. Pour une vulnérabilité avec un tel rayon d'impact, ce manque d'étiquetage public n'est pas idéal.

S'agissait-il vraiment d'une « prise de contrôle du téléphone » ?

Cette formule abrégée est tentante, mais elle a besoin de limites. La vulnérabilité zero-click de WeChat a permis à la démo de prendre le contrôle du compte WeChat, d'après les rapports publics. Cela signifie les messages, les appels et l'identité au niveau de l'application. Pour de nombreux utilisateurs, c'est déjà grave.

Le contrôle complet de l'appareil est une affirmation différente. Android et iOS modernes isolent les applications grâce au sandboxing, aux autorisations, aux règles de signature de code et aux mesures d'atténuation des exploits au niveau de la plateforme. Pour contrôler l'ensemble du téléphone à partir d'une faille applicative, un attaquant a généralement besoin d'une autre vulnérabilité qui permette de sortir du bac à sable de l'application ou d'abuser d'un service privilégié.

LIRE  Tendances du marketing mobile : captiver la génération des smartphones

Calif a également fait cette distinction, en disant que la prise de contrôle de l'appareil n'était possible que si elle était chaînée avec des bugs Android ou iOS supplémentaires. Si vous suivez les mises à jour mensuelles des plateformes, c'est pourquoi la cadence de correction du système d'exploitation reste importante ; notre couverture du Android Drop de septembre 2026 rappelle utilement que les bugs applicatifs et le durcissement du système d'exploitation sont liés, sans pour autant être interchangeables.

Voici l’écueil que beaucoup de résumés rapides oublient : supprimer d’anciens chats ou éviter les liens suspects n’aurait pas empêché le déclencheur démontré. Le composant vulnérable se trouvait dans le chemin de gestion des appels de l’application. Si l’appel atteignait un client WeChat vulnérable depuis un contact accepté, le traitement dangereux se produisait avant que l’utilisateur ne prenne une décision.

Ce que les utilisateurs peuvent faire lorsque la partie vulnérable est une application

Lorsque le bug se trouve dans une application, une mise à jour du système d’exploitation seule peut ne pas suffire à le corriger. Elle peut limiter les dégâts, notamment grâce au sandboxing et aux protections mémoire, mais l’analyseur vulnérable ou le composant VoIP vulnérable nécessite toujours un correctif côté application ou côté serveur. Dans ce cas, Tencent a indiqué qu’aucune action de l’utilisateur n’était requise parce qu’un correctif côté serveur avait été déployé, tandis que Calif a également mentionné des versions corrigées de WeChat.

Si vous utilisez WeChat pour le travail, la famille, les paiements ou les voyages, je considérerais quand même les mises à jour comme le choix le plus raisonnable par défaut. Tencent a indiqué 1.439 billion d’utilisateurs actifs mensuels combinés pour Weixin et WeChat au 30 juin 2026. À cette échelle, même une faille applicative à faible probabilité peut avoir de l’importance.

  • Mettez à jour WeChat au minimum vers Android 8.0.77 ou iOS 8.0.76 si votre boutique d’applications affiche ces versions de 2026 ou des versions plus récentes.
  • Activez les mises à jour automatiques des applications, car les bugs VoIP et d’analyse au niveau de l’application peuvent être corrigés en dehors des versions du système d’exploitation.
  • Vérifiez vos contacts WeChat et supprimez, lorsque cela est possible, les comptes anciens ou non fiables.
  • Désactivez ou supprimez WeChat sur les appareils où vous n’en avez pas besoin, en particulier les téléphones partagés ou rarement surveillés.
  • Surveillez les avis de Tencent, les notes de version des boutiques d’applications et les rapports de sécurité crédibles plutôt que les captures d’écran virales.

Cette étape de révision des contacts paraît mineure. Elle ne l’est pas. Un ver qui dépend de relations sociales acceptées a moins de marge pour se propager lorsque votre liste de contacts n’est pas un grenier vieux de dix ans rempli de comptes abandonnés, d’anciens fournisseurs et de personnes que vous ne reconnaissez même plus.

Pour les entreprises, la gestion des appareils mobiles devrait suivre les versions des applications, et pas seulement les versions d’iOS et d’Android. La connexion sans mot de passe peut réduire les dommages après la compromission d’un compte dans certains systèmes, mais elle ne neutralise pas un bug d’exécution de code à distance dans une application ; pour le contexte, consultez notre guide sur WebAuthn mobile passkeys. Couche différente, défense différente.

Bugs trouvés par l’IA, lacunes de divulgation et l’entre-deux inconfortable

Calif a déclaré que son IA avait trouvé le bug en juillet 2026 et que le premier exploit RCE avait pris environ deux jours. Il a également déclaré que la création de la démonstration de ver aboutie avait demandé une semaine supplémentaire. Ces affirmations proviennent d’une seule source, et les détails techniques sont retenus en attendant une future présentation en conférence.

LIRE  meilleures applications bancaires mobiles à considérer en mai 2025

Même avec cette réserve, la vulnérabilité zero-click de WeChat s’inscrit dans une tendance plus large de 2026 : les systèmes automatisés deviennent meilleurs pour trouver des failles exploitables, tandis que les fournisseurs gardent toujours le contrôle sur ce que les utilisateurs apprennent et à quel moment. Si vous suivez la recherche sur les vulnérabilités assistée par l’IA, notre article sur AI systems finding and exploiting zero-days couvre le débat plus large sur la sécurité.

Il existe un contre-argument qui mérite d’être entendu. Publier une démonstration de ver peut pousser les fournisseurs à corriger des bugs discrètement dangereux, mais cela peut aussi donner aux attaquants une feuille de route si des détails fuitent trop tôt. Dans ce cas, les rapports publics indiquent qu’aucune attaque en conditions réelles n’a été observée, Tencent a remercié les chercheurs selon le SCMP, et les détails de l’exploit n’ont pas été entièrement publiés.

Les attaques de la chaîne d’approvisionnement et du chemin de mise à jour suscitent une inquiétude connexe : même lorsqu’un correctif existe, les utilisateurs doivent recevoir le bon code depuis la bonne source. C’est pourquoi des incidents tels que Détournements BGP affectant les mises à jour logicielles restent pertinents pour la sécurité mobile. L’application de correctifs est un conseil simple ; fournir des correctifs de manière fiable est plus difficile.

FAQ

Qu’est-ce que la vulnérabilité zero-click de WeChat ?

Il s’agissait d’une vulnérabilité de 2026 démontrée par Calif Research dans la pile VoIP/de gestion des appels de WeChat. La démonstration se déclenchait via un appel WeChat entrant provenant d’un contact, sans que la victime ait besoin de répondre, d’appuyer ou d’ouvrir quoi que ce soit.

La vulnérabilité WeChat zero-click a-t-elle été exploitée dans la nature ?

Des rapports publics de septembre 2026 indiquaient qu’aucune exploitation confirmée dans le monde réel n’avait été constatée. Le South China Morning Post a rapporté que Tencent avait déclaré qu’un correctif côté serveur avait été déployé et qu’il n’y avait aucune preuve d’exploitation active à grande échelle.

Quelles versions de WeChat ont corrigé le bug WeWorm ?

Calif a déclaré que WeChat Android 8.0.77 et iOS 8.0.76, publiés le 21 août 2026, ont atténué le bug. Calif a également déclaré que Tencent avait mis en place une atténuation côté serveur pour tous les utilisateurs d’ici au 28 août 2026.

WeWorm pourrait-il prendre le contrôle d’un iPhone ou d’un téléphone Android entier ?

Pas à lui seul, d’après les informations publiques disponibles. La démonstration a montré le contrôle d’un compte WeChat, tandis qu’une prise de contrôle complète de l’appareil nécessiterait de chaîner le bug de l’application avec des vulnérabilités supplémentaires d’Android ou d’iOS.

Les mises à jour du système d’exploitation protègent-elles contre les bugs d’applications en zéro clic ?

Ils peuvent réduire l’impact grâce au sandboxing et aux protections de la plateforme, mais ils peuvent ne pas corriger un composant d’application vulnérable. Pour une faille VoIP au niveau de l’application, vous avez toujours besoin d’une mise à jour de l’application, d’un correctif côté serveur du fournisseur, ou des deux.

fr_FRFR