MobileExplication
Un agent d’IA fait planter des modems 5G MediaTek avec une fausse antenne
Des chercheurs de Singapour ont confié une fausse antenne relais à une IA : MediaTek confirme deux failles, dont une corrigée dans son bulletin d’octobre. Le téléphone perd le réseau sans être piraté ; le correctif dépend de son fabricant.

Près d’un smartphone sur trois livrés dans le monde tourne sur une puce MediaTek (32 % des livraisons au premier trimestre 2026, selon Counterpoint Research cité par l’étude), et le modem 5G de ces puces vient de céder face à un adversaire inhabituel : un agent d’IA. Une équipe emmenée par l’université de technologie et de design de Singapour (SUTD), dont deux membres ont signé l’outil d’attaque 5Ghoul, lui a confié une fausse antenne relais chargée d’envoyer des messages 5G volontairement malformés à de vrais téléphones. Résultat, publié le 21 octobre : des dizaines de plantages du modem, et deux failles que MediaTek a reconnues de gravité « élevée ». L’une, CVE-2026-20525 (le numéro public qui identifie une faille), figure dans le bulletin de sécurité d’octobre du fondeur, publié le 5 octobre.
Le constat est sérieux, la menace pour un utilisateur plus limitée qu’un titre sur « l’IA qui pirate les téléphones » ne le laisserait croire.
Le modem, une boîte noire qui écoute avant de vérifier
Dans un smartphone, le modem (on parle aussi de « bande de base ») est le sous-ensemble qui dialogue avec les antennes relais de l’opérateur : il reçoit les signaux radio, les décode et gère la connexion au réseau. Chez MediaTek, il est intégré à la puce principale (la fiche de la Dimensity 6300 mentionne ainsi un « modem 5G de norme 3GPP Release-16 »). Il fonctionne avec son propre logiciel, fourni par le fondeur et fermé : ni les chercheurs ni les fabricants de téléphones n’en publient le code source.
Les chercheurs ont visé une phase précise : les messages qu’échangent l’antenne et le téléphone au moment de la connexion, « avant que le contexte de sécurité ne soit établi », écrivent-ils. À ce stade, le téléphone n’a pas encore vérifié qu’il parle au vrai réseau de son opérateur, et il doit pourtant lire ce qu’on lui envoie. Un message mal formé (un champ trop long, une valeur interdite, un octet modifié) peut alors dérouter le logiciel du modem.
La méthode s’appelle le fuzzing : bombarder un programme de données légèrement faussées et noter celles qui le font tomber. 5Ghoul le faisait déjà, avec des règles écrites à la main. L’outil de la SUTD, baptisé 5uGUE (prononcé comme « fugue »), confie la stratégie à un modèle de langage : l’agent cherche d’abord sur le Web et dans un corpus d’articles les failles connues, choisit quel message altérer et à quel endroit, écrit le petit programme d’attaque, l’envoie par radio, lit les journaux du téléphone, puis décide du test suivant. Chaque session compte 60 tours de cette boucle, sans intervention humaine.
Une fausse antenne, du matériel de laboratoire et un téléphone à portée
L’attaque suppose une fausse station de base 5G : un ordinateur qui simule le réseau et une radio logicielle, c’est-à-dire un émetteur-récepteur programmable. Les chercheurs ont utilisé une USRP B210, vendue 2 387 dollars par Ettus Research, sur des PC sous Ubuntu. Le dépôt de code ajoute une enceinte blindée contre les ondes, « pour confiner les signaux de test », et une carte SIM programmable réglée sur l’identifiant du réseau de test : au laboratoire, le téléphone est donc configuré pour rejoindre la fausse antenne.
Hors du laboratoire, l’attaquant doit amener le téléphone à se connecter à son émetteur, ce qui suppose d’être à portée radio. Les auteurs jugent ce modèle d’attaque « praticable », en s’appuyant sur des travaux antérieurs, sans le démontrer en conditions réelles dans cette étude. La fiche de la faille va dans le même sens : l’agence américaine de cybersécurité (CISA), qui ajoute sa propre évaluation aux fiches CVE, classe l’attaque comme menée depuis un réseau « adjacent » (à proximité, pas depuis Internet) et de complexité « élevée ».
Un réseau qui tombe, pas un téléphone piraté
La description officielle de CVE-2026-20525 est explicite : un « plantage du système » du modem, dû à une « validation incorrecte des données », qui « pourrait conduire à un déni de service à distance si un appareil s’est connecté à une station de base pirate contrôlée par l’attaquant ». Aucune action de l’utilisateur n’est nécessaire. Un déni de service, c’est ici un modem qui s’arrête : les journaux des téléphones testés affichent alors des messages comme « Modem Resets! », signe que le modem redémarre. Pendant ce temps, le téléphone n’a plus de réseau mobile.
La faille appartient à la catégorie CWE-617, « assertion atteignable » : le logiciel du modem contient un contrôle interne qui arrête tout quand une valeur est jugée impossible, et l’attaquant parvient à déclencher cet arrêt. C’est un plantage, pas une prise de contrôle : la note de la CISA ne retient aucun effet sur la confidentialité ni sur l’intégrité des données, seulement sur la disponibilité. Le dépôt des chercheurs le dit pour l’ensemble de leurs trouvailles : 46 plantages distincts et reproductibles, « menant tous à des attaques par déni de service » ; 44 d’entre eux, confirmés par les fondeurs, avaient déjà été signalés, et les deux autres sont les failles nouvelles reconnues par MediaTek.
Deux réserves. La gravité d’abord : MediaTek classe la faille « élevée » en s’appuyant, dit son bulletin, sur le barème CVSS 3.1 (la grille standard qui note la gravité d’une faille de 0 à 10), sans publier sa note ; la CISA, avec le même barème, lui attribue 5,3 sur 10, soit une gravité « moyenne », surtout à cause de la proximité et de la complexité exigées. Les limites de l’analyse ensuite : faute d’accès au code, les auteurs reconnaissent qu’il leur est « impossible » de dire si chaque plantage vient d’une assertion, d’une transition d’état invalide ou d’un accès mémoire dangereux. MediaTek indique n’avoir connaissance d’« aucune exploitation active » des failles de son bulletin.
Du fondeur au téléphone, un correctif qui change de mains
MediaTek ne met pas à jour les téléphones lui-même. Son bulletin précise que les fabricants ont reçu les correctifs « au moins deux mois avant la publication » ; la fiche CVE donne des identifiants de correctif propres au logiciel du modem (MOLY01870473, MOLY00814393). C’est ensuite à chaque marque de les intégrer à ses mises à jour, modèle par modèle.
Samsung l’a fait savoir : CVE-2026-20525 figure dans la liste des failles « élevées » couvertes par sa mise à jour de sécurité d’octobre 2026, destinée d’abord à ses « principaux modèles phares », avec l’avertissement que certains correctifs venus des fondeurs peuvent ne pas figurer dans la mise à jour du mois. Google, en revanche, ne liste aucune faille MediaTek dans son bulletin Android d’octobre. Conséquence pratique : la date du « correctif de sécurité » affichée dans les réglages d’un téléphone Android ne garantit pas, à elle seule, que le modem a été corrigé ; seule la note de mise à jour du fabricant le dit. Pour Xiaomi et OnePlus, dont les téléphones ont servi aux tests, nous n’avons pas pu établir le 22 octobre si leurs mises à jour intègrent ce correctif.
Les téléphones de l’étude illustrent ce décalage. Les deux failles confirmées par MediaTek ont été trouvées lors de deux sessions sur le Redmi 15C 5G (puce Dimensity 6300), dont le correctif de sécurité datait du 1er août 2025 au moment des tests. La fiche de la faille liste 22 références de puces, dont MT6835 ; Notebookcheck donne la référence MT6835T pour la Dimensity 6300.
| Téléphone | Puce (modem) | Version du micrologiciel du modem (relevée par les auteurs) | Correctif de sécurité Android |
|---|---|---|---|
| OnePlus Nord CE 2 5G | MediaTek Dimensity 900 | IV2201 11 F.48 | 5 mai 2023 |
| Redmi 15C 5G | MediaTek Dimensity 6300 | AP3A.240905.015.A2 | 1er août 2025 |
| OnePlus Nord 3 | MediaTek Dimensity 9000 | CPH2493 16.0.3.500(EX01) | 1er février 2026 |
| OnePlus Ace 5 Ultra | MediaTek Dimensity 9400 | PLC110 15.0.2.610(CN01) | 1er septembre 2025 |
| Hisense F50+ | UNISOC UD710 | PPR1.180610.011 release-keys | 5 décembre 2020 |
Les 22 puces MediaTek listées pour CVE-2026-20525
MT2716, MT6835, MT6858, MT6878, MT6881, MT6897, MT6899, MT6982, MT6986, MT6988, MT6991, MT6993, MT8668, MT8676, MT8678, MT8755, MT8775, MT8792, MT8793, MT8863, MT8873, MT8883 (références techniques ; MediaTek ne donne pas les noms commerciaux correspondants).
La seconde faille confirmée par MediaTek n’a pas encore de numéro CVE : son attribution est « en attente » (« pending »), indique le dépôt des chercheurs, mis à jour le 22 octobre. Côté UNISOC, fondeur chinois de puces d’entrée de gamme, le constructeur a confirmé sept plantages sur le Hisense F50+, mais aucune information publique n’existe, précisent les auteurs, et nous n’avons pas trouvé de bulletin UNISOC qui s’y rapporte.
Ce que l’agent change à la chasse aux failles, et ce qu’il ne change pas
Les chiffres de l’étude sont nets, à condition de les lire correctement. Selon le résumé de l’étude, en additionnant la meilleure session sur chacun des cinq téléphones, 5uGUE déclenche 167 plantages, dont 141 « inédits » (absents de toute source publique), contre 13 pour 5Ghoul, l’outil classique, limité à 150 minutes par session. Mais ces 167 comptent plusieurs fois le même plantage : les plantages distincts sont 31 dans ces sessions, contre 6 pour 5Ghoul, toujours selon le résumé de l’étude. Le chiffre le plus parlant est la moyenne sur cinq sessions par téléphone : 21 plantages pour l’agent, 1,2 pour 5Ghoul, qui n’en a trouvé aucun sur le Redmi 15C 5G ni sur le OnePlus Ace 5 Ultra. Pour la sécurité des utilisateurs, ce qui compte reste le dernier filtre : deux failles reconnues par MediaTek et sept plantages par UNISOC à ce jour.
Le coût, lui, est modeste. Une session de 60 tours consomme pour 2,15 dollars (Qwen3.7 Plus d’Alibaba) à 36,40 dollars (GPT-5.5 d’OpenAI) d’appels au modèle, selon les tarifs relevés par les auteurs. Le plus efficace des six modèles testés, Kimi K2.6 de Moonshot AI, coûte 4,39 dollars par session ; Claude Sonnet 4.6 d’Anthropic arrive deuxième, pour 21,98 dollars ; Gemini 3.1 Pro de Google ferme la marche. La facture élevée ne garantit donc pas le meilleur résultat.
Trois limites tempèrent l’idée d’une recherche de failles devenue automatique. L’agent ne part pas de rien : il s’appuie sur l’infrastructure de 5Ghoul, outil antérieur des mêmes chercheurs, et sur environ 16 070 lignes de code Python écrites pour lui. Il réussit d’abord là où l’information publique abonde : sur le OnePlus Nord CE 2, dont les plantages connus sont documentés en ligne, il trouve 32 plantages en moyenne ; sur le téléphone UNISOC, le moins documenté, 11,6. Enfin, le matériel radio et le laboratoire restent indispensables, et le dépôt avertit que le code n’est « pas un outil clé en main ».
Les auteurs reconnaissent le double usage : un attaquant pourrait s’en servir pour trouver des failles sans les signaler. Le risque est selon eux « modéré par l’expertise technique » nécessaire ; ils publient l’agent, mais ni les programmes d’attaque ni le détail des plantages inédits. La tendance n’est pas propre à la radio : des failles trouvées par des IA ont déjà poussé OpenSSH à accélérer ses correctifs.
Ce qui change surtout tient au rapport de force. Les modems restent des logiciels fermés que seuls les fondeurs peuvent corriger, un terrain que les auteurs jugent « relativement peu exploré ». Un agent qui déclenche, en 49 à 133 minutes, environ cinq fois plus de plantages distincts qu’un outil classique en deux heures et demie abaisse le seuil d’entrée pour les chercheurs, et pour ceux qui ne signaleront rien. Les mêmes auteurs ont d’ailleurs adapté 5uGUE au Bluetooth classique en ne changeant que quelques consignes et outils : il a provoqué en moyenne 6,4 plantages inédits sur une puce ESP32.
Les citations de l’étude, du dépôt de code, de la fiche CVE et des bulletins de MediaTek et de Samsung sont traduites de l’anglais par la rédaction. Parmi les modèles comparés figure Claude Sonnet 4.6, d’Anthropic, dont les agents qui préparent les articles de L’Octet utilisent aussi les modèles ; les auteurs de l’étude ont par ailleurs écrit une partie de leur code avec Claude Code.



