MediaTek corrige deux failles critiques du modem exploitables par une fausse station de base
Le bulletin de sécurité d’octobre 2026 de MediaTek referme 31 failles, dont deux écritures hors limites critiques dans le modem (CVE-2026-20519 et CVE-2026-20520) qu’une fausse station de base peut déclencher pour élever ses privilèges, sans interaction utilisateur. Vérifiez le niveau de correctif de votre flotte Android et traitez le décalage entre le correctif MediaTek et sa distribution par les fabricants comme un risque à part entière.
Lundi 5 octobre 2026. MediaTek publie son bulletin de sécurité mensuel : 31 failles refermées, dont deux critiques — CVE-2026-20519 et CVE-2026-20520. Aucun clic, aucun téléchargement. Les deux critiques sont des écritures hors limites (out-of-bounds write, CWE-787) dans le modem, provoquées par un contrôle de bornes manquant. Le vecteur est radio. Une fausse station de base — une antenne contrôlée par l’attaquant à laquelle le téléphone se connecte — suffit à déclencher la corruption mémoire et à élever les privilèges sur l’appareil. Pour une flotte mobile, c’est le scénario d’attaque le plus discret qui soit : il ne passe ni par un e-mail, ni par une application, ni par un réseau Wi-Fi.
Ce que contient le bulletin d’octobre
Le bulletin, noté CVSS v3.1, se décompose en 2 failles critiques, 9 hautes et 20 moyennes. La répartition par sous-composant raconte l’étendue de la surface : les deux critiques vivent dans le modem, mais le reste touche le décodeur vidéo (vdec), l’encodeur (venc), la HAL vidéo, l’unité neuronale (neuropilot), l’APU, le secure world (mtee) et la couche meta.
Les deux critiques sont presque identiques : CVE-2026-20519 et CVE-2026-20520 décrivent toutes deux « une possible écriture hors limites due à un contrôle de bornes manquant », dans le sous-composant Modem, toutes deux classées CWE-787. Elles touchent un même ensemble d’environ 57 puces — des MT6739 d’entrée de gamme aux Dimensity récents (MT6980, MT6985, MT6989, MT6990, MT6991, MT6993), en passant par les plateformes IoT et automotive (MT8668, MT8676, MT8678). Concrètement, cela couvre des centaines de millions d’appareils Android, pas seulement des smartphones.
Côté hautes, CVE-2026-20526 et CVE-2026-20527 sont elles aussi des failles du modem — une écriture hors limites et une validation d’index défaillante (CWE-129) — tandis que CVE-2026-20586, CVE-2026-20589, CVE-2026-20521, CVE-2026-20522, CVE-2026-20523 et CVE-2026-20524 frappent les pipelines multimédia et IA du SoC. Ces dernières exigent généralement un accès local ou une application malveillante pour être exploitées : moins spectaculaires, mais elles rappellent que le correctif mensuel d’un SoC ne se limite jamais au modem.
Pourquoi le modem est la cible qui inquiète
Le modem (ou baseband) est la partie du téléphone qui parle au réseau cellulaire. Historiquement, c’est du code fermé, fourni par le fabricant de puces, que ni l’équipe sécurité de l’entreprise ni les chercheurs ne peuvent auditer comme le reste du système. Il traite en continu des données non fiables venues de l’extérieur — balises réseau, identifiants de cellule, messages de contrôle — sans intervention de l’utilisateur.
C’est exactement ce qui rend les deux critiques dangereuses. Une fausse station de base (ou rogue base station, parfois appelée IMSI catcher) émet un signal cellulaire que le téléphone accepte comme légitime. Dès que l’appareil s’y connecte, l’attaquant peut envoyer des messages de contrôle malformés qui déclenchent l’écriture hors limites dans le firmware du modem. MediaTek précise dans son bulletin qu’il n’a connaissance d’aucune exploitation active au 5 octobre 2026 — mais l’absence d’exploitation connue ne réduit pas le risque : ce type de faille se prête à des attaques ciblées et silencieuses, difficiles à détecter parce qu’elles ne laissent aucune trace côté utilisateur.
La portée dépasse l’espionnage. Une élévation de privilèges dans le modem peut exposer les communications, contourner l’isolation entre le baseband et le processeur applicatif, et servir de point d’appui pour des chaînes d’exploitation plus longues. Les fabricants de puces publient ces failles discrètement, sans l’écho d’une faille zero-day d’un navigateur, mais la surface est comparable.
Le vrai risque : le décalage de distribution du correctif
Le point le plus important du bulletin tient en une phrase : « les équipementiers ont été notifiés de tous les problèmes et des correctifs correspondants au moins deux mois avant la publication ». Le correctif existe donc depuis l’été. La question n’est pas de savoir si MediaTek a corrigé, mais quand le patch atteindra chaque appareil.
La chaîne est longue : MediaTek livre le correctif aux équipementiers (les marques de téléphones), qui doivent l’intégrer dans leur propre firmware, puis le distribuer — parfois via les opérateurs — sous forme de mise à jour OTA. À chaque maillon, le correctif peut être retardé, voire jamais distribué pour les modèles en fin de vie. Le bulletin de sécurité Android mensuel de Google n’est qu’un maillon de cette chaîne : il porte les correctifs de Google et d’une partie des partenaires, mais un patch MediaTek sur un appareil d’un équipementier tiers dépend d’abord de cet équipementier.
Pour un RSSI, la conséquence est directe : le niveau de correctif d’une flotte mobile ne se vérifie pas en regardant la version d’Android, mais en croisant le niveau de correctif de sécurité affiché par chaque appareil avec les bulletins des fournisseurs de puces. Un téléphone affichant un patch de septembre 2026 n’est pas nécessairement couvert contre les failles MediaTek d’octobre — il peut les avoir reçues tôt, ou pas du tout.
Vérifier le niveau de correctif de votre parc
Le correctif MediaTek ne se devine pas, il se mesure. Sur Android, le niveau de correctif de sécurité s’affiche dans les réglages, mais ce niveau est une déclaration du fabricant, pas une preuve que les correctifs MediaTek d’octobre sont réellement intégrés. Deux commandes permettent de vérifier côté poste.
# Niveau de correctif Android déclaré par l'appareil
adb shell getprop ro.build.version.security_patch
# Version du firmware radio (baseband), à croiser avec les bulletins du fabricant
adb shell getprop gsm.version.basebandLa première commande renvoie la date du correctif (par exemple 2026-09-05) ; la seconde donne la version du baseband. Croisez les deux avec le bulletin MediaTek d’octobre : un appareil dont le correctif remonte à août n’a presque certainement pas reçu les correctifs d’octobre, et un appareil dont le firmware radio n’a pas bougé depuis des mois mérite une alerte.
À l’échelle d’un parc, la vérification manuelle ne passe pas. Un MDM ou un EMM digne de ce nom remonte le niveau de correctif et la version du baseband par appareil ; exigez cette donnée dans vos tableaux de conformité, au même titre que la version du système. C’est la seule façon de transformer un bulletin MediaTek en action mesurable — et de détecter les appareils dont le fabricant a cessé de distribuer les correctifs.
Verdict
Si vous gérez une flotte Android d’entreprise, traitez ce bulletin comme un rappel de structure : exigez des équipementiers un engagement de délai de distribution des correctifs dans vos contrats d’achat, et ne validez aucun appareil dont le niveau de correctif de sécurité est en retard de plus de 30 jours. Si votre parc contient des appareils à base MediaTek, croisez le niveau de correctif de chaque appareil avec le bulletin MediaTek d’octobre — les deux failles critiques touchent des puces vendues sur plusieurs générations, y compris des modèles encore en circulation dans les parcs professionnels. Si vous n’avez pas de visibilité sur vos terminaux, commencez par un inventaire du niveau de correctif avant de parler d’atténuation : une fausse station de base ne peut pas être contrée par un antivirus, seulement par un firmware à jour. La leçon de fond vaut pour tout le monde : sur mobile, le maillon le plus faible n’est pas le téléphone, c’est l’intervalle entre le correctif du fabricant de puce et son arrivée effective sur l’appareil.