Quand un simple SMS peut interrompre un appel : comprendre la faille Android CVE-2026-58882

01

Comment un SMS atteint-il réellement un smartphone ?

Pour comprendre l’attaque, il faut quitter un instant l’écran de l’application Messages. Un SMS n’est pas simplement une ligne de texte qui apparaît dans une boîte de réception : c’est d’abord un message transporté par une infrastructure de télécommunications, remis à l’équipement, puis interprété par plusieurs composants logiciels.

Dans une représentation volontairement simplifiée, le message transite par les fonctions de service SMS de l’opérateur, dont le SMSC (Short Message Service Centre), puis par les mécanismes de cœur de réseau et d’accès radio. Les détails diffèrent selon la génération et l’architecture du réseau — 2G, 3G, LTE, 5G, transport SMS sur IMS ou autre mécanisme pris en charge. Le point commun est que le message finit par être remis au terminal.

Côté smartphone, le modem cellulaire, aussi appelé baseband, participe aux communications avec le réseau. Les informations pertinentes sont ensuite transmises aux couches logicielles du système, via les interfaces qui relient la partie radio au Telephony Framework d’Android. C’est là qu’un message peut être réassemblé, identifié et aiguillé selon son type.

Une distinction est essentielle : le processus qui interprète le contenu du SMS n’est pas nécessairement l’application qui l’affiche. Certains messages sont destinés à des composants du système. Ils peuvent donc être traités sans jamais apparaître à l’écran. Cette capacité est légitime ; elle crée aussi une surface d’attaque.

02

SMS classique, SMS de données et WAP Push : trois notions à distinguer

Le SMS classique transporte un contenu que l’utilisateur a vocation à lire. Un SMS de données peut, lui, porter des informations structurées dirigées vers un service ou un port applicatif du terminal. WAP Push désigne un mécanisme historique permettant d’acheminer des notifications ou des contenus structurés vers un logiciel récepteur, notamment dans des usages liés à la messagerie multimédia ou à certains services de configuration.

WAP signifie Wireless Application Protocol. Les architectures mobiles ont beaucoup évolué depuis sa période de popularité, mais la présence de composants compatibles avec des protocoles anciens reste parfois nécessaire pour assurer l’interopérabilité. Une technologie ancienne ne disparaît pas automatiquement du code d’un système récent.

La différence devient importante du point de vue de la sécurité : un message destiné à un traitement interne n’attend pas forcément que quelqu’un le lise. Il peut être analysé dès sa réception par un service logiciel. C’est précisément ce qui permet de parler ici de vulnérabilité zero-click.

Il serait toutefois inexact d’en conclure que tous les SMS WAP Push sont malveillants ou que toute réception WAP Push entraîne un risque. La vulnérabilité concerne une structure malformée particulière et un traitement logiciel insuffisamment robuste. Le type de message n’est que le vecteur d’entrée.

03

Au cœur de la faille : comment un entier devient une taille impossible

Le composant analysé par le chercheur se trouve dans le code de téléphonie d’Android, notamment dans la classe WapPushOverSms et sa méthode decodeWapPdu(). Le rôle de cette méthode est de décoder les données d’un message WAP Push, y compris des champs qui indiquent la longueur de certaines parties du message.

L’un de ces champs indique la longueur de l’en-tête (header length). La valeur est décodée puis utilisée pour réserver un tableau d’octets en mémoire. Ce fonctionnement est banal : pour lire un en-tête, un programme doit connaître la taille de la zone à traiter. Le problème apparaît quand une valeur fournie par une entrée extérieure est considérée comme fiable sans vérification suffisante.

Étape 1 — Une longueur provient d’un contenu non fiable

Le format WSP permet d’encoder certains entiers sous une forme dite uintvar (unsigned variable-length integer). Le décodeur fournit ici une valeur numérique dans un type Java long, capable de représenter des entiers plus grands qu’un int signé de 32 bits.

Étape 2 — La valeur est convertie sans validation de plage

Dans le chemin vulnérable, le code effectuait une conversion de ce type :

int headerLength = (int) pduDecoder.getValue32();

Le type int de Java est signé sur 32 bits. Sa valeur maximale est 2 147 483 647. Une valeur de 2 147 483 648 — soit 2³¹ — peut exister dans le long d’origine, mais ne peut pas être représentée comme entier positif dans un int. La conversion conserve les 32 bits de poids faible ; leur interprétation signée devient −2 147 483 648.

Autrement dit, la longueur déclarée par un message peut être transformée en nombre négatif. Il ne s’agit pas ici d’un SMS qui consommerait réellement deux gigaoctets de mémoire : l’échec survient au moment où le programme essaie de préparer le tableau avec une taille invalide.

Étape 3 — Le programme essaie de créer un tableau de taille négative

Quelques lignes plus loin, cette longueur est utilisée ainsi :

byte[] header = new byte[headerLength];

En Java, on ne peut pas créer de tableau de longueur négative. Le moteur d’exécution lève donc une NegativeArraySizeException. Une exception n’est pas, en soi, une catastrophe : un logiciel robuste peut la gérer, rejeter le message erroné et poursuivre son activité.

Étape 4 — L’exception non maîtrisée atteint un processus essentiel

Dans le chemin vulnérable décrit par le chercheur, cette exception n’était pas interceptée de manière appropriée. Elle pouvait remonter jusqu’au processus com.android.phone, qui héberge des fonctions critiques de téléphonie, et provoquer son arrêt. Les services de communication dépendant de ce processus peuvent alors être momentanément interrompus. [3][4]

Le mécanisme est instructif : le message n’a pas besoin de contenir un logiciel malveillant exécutable. Une valeur numérique choisie pour déclencher un chemin d’erreur suffit à perturber le fonctionnement du programme. Cela relève de la validation des entrées, de la sûreté du traitement des données et de la maîtrise des exceptions.

04

Pourquoi un défaut dans le logiciel peut-il couper un appel mobile ?

Un smartphone moderne n’est pas un seul logiciel. Il fait cohabiter des composants matériels, plusieurs micrologiciels (firmwares), un système d’exploitation et des applications. Dans un schéma simplifié, on peut distinguer quatre ensembles :

• Le modem / baseband, qui participe à la gestion des communications cellulaires et exécute son propre logiciel ;
• Les interfaces radio côté système — selon les générations, la couche HAL radio et les mécanismes d’interface avec le modem ;
• Le Telephony Framework et les services Android, qui coordonnent de nombreuses fonctions liées aux appels, aux SMS et à l’état du réseau ;
• Les applications visibles, comme l’interface de numérotation ou l’application Messages.

Le composant vulnérable se situe du côté du traitement logiciel Android, pas dans un défaut de décodage radio démontré au sein du modem. Pourtant, le processus touché contribue au pilotage et à la disponibilité des fonctions téléphoniques. Son arrêt peut entraîner la perte d’une communication en cours, y compris, selon les essais publiés, un appel vers un service d’urgence.

Cette différence mérite d’être soulignée : provoquer un dysfonctionnement de la téléphonie Android n’équivaut ni à compromettre le modem, ni à faire tomber le réseau de l’opérateur. De même, zero-click signifie absence d’action nécessaire de l’utilisateur ; cela ne signifie pas automatiquement exécution de code arbitraire, espionnage ou extraction de données.

05

Quelles conséquences ont réellement été observées ?

Le chercheur à l’origine de la divulgation, Mark B, indique avoir reproduit le problème sur plusieurs appareils et versions Android, jusqu’à Android 16. Il décrit des interruptions d’appels, une perte temporaire des fonctions cellulaires pendant le redémarrage du processus, et, dans certaines configurations de test, des effets persistants dus à la répétition du traitement de messages problématiques. [4]

Un appel interrompu, parfois sans signe avant-coureur

Lorsqu’un composant logiciel nécessaire à la téléphonie redémarre, une communication en cours peut être interrompue. Le chercheur rapporte ce comportement y compris pour des appels d’urgence. Ce constat est issu des essais publiés ; il ne faut pas en déduire que chaque modèle Android, chaque réseau ou chaque appel d’urgence réagit exactement de la même façon.

Une perte de service qui peut se répéter

Un message qui n’a pas été correctement traité ou acquitté peut, selon les mécanismes impliqués, être représenté au composant de réception. Si le même défaut se reproduit, le processus peut de nouveau s’arrêter. Le chercheur évoque notamment la possibilité de messages conservés en attente et de nouvelles tentatives de livraison.

Il rapporte également que l’accumulation de messages malformés a provoqué des redémarrages répétés sur certains équipements testés. Ce sont des observations expérimentales importantes, mais pas une garantie de résultat reproductible sur tous les téléphones. Le comportement dépend notamment de la version du code, du constructeur, de l’état du terminal et des mécanismes de reprise.

Une atteinte à la disponibilité, pas une prise de contrôle établie

Il faut distinguer les conséquences :

C’est déjà suffisamment sérieux : la disponibilité est une propriété de sécurité à part entière. Lorsqu’une fonction de communication peut être nécessaire pour appeler de l’aide, la perte de service ne se réduit pas à un simple désagrément.

06

Ce que Google a réellement corrigé : deux protections complémentaires

Le correctif disponible dans le dépôt AOSP porte notamment sur deux fichiers du composant de téléphonie : WapPushOverSms.java et InboundSmsHandler.java. Son message de modification est explicite : il vise à empêcher qu’un message WAP Push malformé conduise à un déni de service distant et à des boucles de plantage persistantes. [3]

Première protection : intercepter plus largement les exceptions pendant le décodage. Là où le code ne capturait auparavant qu’une ArrayIndexOutOfBoundsException, le correctif traite désormais les RuntimeException sur le chemin concerné. La NegativeArraySizeException entre dans cette famille. Au lieu de laisser l’exception remonter et interrompre le processus, le code peut journaliser l’erreur et signaler l’échec du décodage.

Deuxième protection : ne pas laisser le message problématique déclencher une boucle. Le correctif renforce également InboundSmsHandler : lorsqu’une erreur survient à certaines étapes de traitement, le suivi du message concerné peut être marqué pour suppression dans la base des SMS entrants en attente, ce qui limite son retraitement automatique.

Un détail de conception mérite l’attention : ce correctif ne consiste pas simplement à ajouter une vérification de taille avant chaque conversion. Google a choisi ici de renforcer la gestion des exceptions et le traitement des messages défectueux. Une validation explicite des longueurs demeure une bonne pratique générale ; dans ce cas précis, le correctif publié privilégie aussi la robustesse du parcours de traitement et la prévention des plantages répétés.

Le dépôt contient par ailleurs des tests de non-régression pour vérifier qu’une longueur d’en-tête invalide entraîne une erreur maîtrisée et que certaines exceptions n’abattent plus le traitement de téléphonie. [3]

Leçon d’ingénierie. Rejeter correctement une entrée malformée est essentiel. Mais un système robuste doit aussi définir ce qu’il advient de cette entrée ensuite : est-elle ignorée, conservée, rejouée, acquittée ou supprimée ? Une mauvaise politique de reprise peut transformer un incident ponctuel en déni de service persistant.

07

Quels smartphones sont concernés ? Et quel correctif faut-il vérifier ?

La vulnérabilité a été signalée le 5 mai 2026 et son analyse a été rendue publique le 29 octobre 2026, selon la chronologie donnée par le chercheur. Le 2 novembre 2026, Google a publié le bulletin Android qui répertorie officiellement CVE-2026-58882 comme un DoS critique, avec des versions AOSP corrigées Android 14, 15, 16, 16 QPR2 et 17. Le niveau de correctif de sécurité associé dans le bulletin et la base OSV est 2026-11-01. [1][2][4]

Le chercheur indique qu’un correctif avait commencé à être diffusé dans certaines branches ou mises à jour dès octobre 2026. Ce point ne doit pas être confondu avec la référence officielle du bulletin : pour vérifier la couverture de cette CVE à partir des publications Google, la référence sûre est le niveau de sécurité Android du 1er novembre 2026 ou une correction constructeur explicitement confirmée. [1][2][4]

Et Android 12 ou 13 ? Les essais du chercheur y identifient également le problème, mais ces versions ne figurent pas dans la liste des branches AOSP corrigées du bulletin de novembre 2026. Il serait donc imprudent de supposer qu’un appareil Android 12/13 est protégé. Il faut consulter l’état réel du support et les avis du constructeur : certains fournisseurs peuvent, selon leurs engagements, maintenir des correctifs spécifiques, sans que cela puisse être déduit du seul numéro de version.

Pour un utilisateur, la démarche est simple : consulter Paramètres → À propos du téléphone → Version d’Android → Mise à jour de sécurité Android (le chemin exact dépend du constructeur), puis installer les mises à jour proposées. La version « Android 14 » ou « Android 15 » ne suffit pas : c’est le niveau effectif des correctifs installés qui compte.

Il faut aussi distinguer 2026-11-01, qui couvre cette CVE dans le bulletin, de 2026-11-05, niveau comprenant les correctifs additionnels de novembre pour d’autres composants, dont certains éléments du noyau et des fournisseurs de puces. Sur un appareil compatible, installer le niveau le plus complet disponible reste préférable. [1]

08

Que peuvent faire utilisateurs, organisations et opérateurs ?

Pour les utilisateurs, la priorité est d’installer une mise à jour de sécurité documentée pour leur modèle. Si le fabricant ne fournit plus de correctifs, la question du remplacement de l’équipement devient une décision de sécurité et de continuité de service. En cas d’interruptions inhabituelles, il faut également éviter d’attribuer automatiquement le problème à cette seule CVE : une panne réseau, un défaut matériel ou de nombreuses autres causes peuvent produire des symptômes voisins.

Pour les organisations, l’enjeu est l’inventaire : quels smartphones professionnels exécutent des versions anciennes ? Quels appareils ont un niveau de correctif inférieur au minimum attendu ? Quels équipements sont utilisés pour l’astreinte, la gestion de crise, les interventions de terrain ou les communications d’urgence ? Une politique MDM/UEM peut contribuer à vérifier les niveaux de sécurité, à identifier les terminaux hors support et à organiser leur renouvellement.

Pour les opérateurs mobiles, les questions portent sur la détection des messages SMS de données manifestement anormaux, la surveillance des comportements de remise répétés, le traitement des signalements et la coordination avec les fabricants. Un filtrage réseau peut parfois réduire l’exposition, mais il ne remplace pas le correctif sur le terminal : le réseau ne dispose pas nécessairement de toute la visibilité sur les particularités de chaque décodeur logiciel ni sur toutes les variantes de transport.

Enfin, pour les régulateurs et les responsables de la résilience numérique, cette CVE invite à examiner les exigences de maintien en condition de sécurité des terminaux, les durées de support annoncées, la transparence sur les correctifs et l’impact des défaillances logicielles sur les services essentiels. Il ne s’agit pas d’affirmer que tout incident individuel équivaut à une crise nationale, mais de reconnaître que la continuité des communications dépend aussi de la sécurité du logiciel embarqué.

Un enseignement particulier pour les marchés africains

Dans des environnements où les smartphones sont souvent conservés plusieurs années, où le marché de l’occasion est important et où les mises à jour dépendent fortement du modèle, du fabricant et parfois de la chaîne de distribution, la durée réelle du support de sécurité devient un critère de choix aussi important que les caractéristiques techniques de l’appareil.

Il serait excessif de prétendre, sans étude, que cette faille touche davantage l’Afrique que les autres régions. En revanche, la question est pertinente : comment garantir dans la durée la sécurité d’équipements de communication dont le service est attendu bien après leur commercialisation ? Cela concerne les consommateurs, les administrations, les entreprises, les opérateurs et les acteurs de l’homologation.

09

Ce que cette faille nous apprend sur la cybersécurité des équipements connectés

CVE-2026-58882 réunit plusieurs enseignements qu’il serait dommage de limiter à l’univers Android.

D’abord, une entrée réseau est une donnée non fiable, même lorsqu’elle arrive par une fonction du système considérée comme ordinaire et légitime. Le contrôle des types, des bornes et de la cohérence des longueurs doit s’appliquer avant d’utiliser cette donnée pour allouer de la mémoire ou commander un traitement sensible.

Ensuite, une exception n’est pas seulement une erreur de programmation. Si elle atteint un service partagé qui assure plusieurs fonctions essentielles, elle peut devenir un incident de disponibilité. La séparation des responsabilités, l’isolation des processus et la reprise maîtrisée sont donc des éléments concrets de la cybersécurité.

Enfin, la résilience ne se résume pas au redémarrage automatique. Un service qui redémarre pour retraiter immédiatement la même donnée défectueuse peut entrer dans une boucle d’échec. Il faut aussi décider comment isoler, journaliser et neutraliser une entrée malformée sans compromettre la disponibilité de l’ensemble.

Ces principes valent au-delà des smartphones : routeurs, équipements IoT, systèmes embarqués, passerelles industrielles, boîtiers de communication et appareils radio partagent cette exigence de robustesse aux données reçues.

CONCLUSION

Conclusion — Une petite donnée, une grande dépendance

« SMS of Death » est une appellation spectaculaire. Le mécanisme, lui, est presque banal du point de vue de l’ingénierie logicielle : une valeur numérique mal validée, une exception insuffisamment maîtrisée et un service critique qui en supporte les conséquences.

C’est précisément pour cette raison que le cas est intéressant. Il rappelle que la sécurité d’un smartphone ne dépend pas uniquement du chiffrement, des permissions applicatives ou de la protection de son modem. Elle dépend également de la capacité de chaque composant à traiter correctement une entrée inattendue, à contenir une erreur et à préserver la continuité des fonctions essentielles.

Un téléphone peut disposer d’une liaison radio parfaitement opérationnelle et devenir pourtant temporairement incapable de téléphoner : entre le signal reçu et le service rendu, le logiciel reste un maillon décisif de la chaîne de confiance et de disponibilité.

RÉFÉRENCES

Sources et références

[1] Android Open Source Project (Google), Android Security Bulletin — November 2026, publié le 2 novembre 2026.

[2] OSV / Android Security Bulletin, ASB-A-517376969 — CVE-2026-58882, statut de correction par branche AOSP.

[3] Android Open Source Project, Fix remote DoS in decodeWapPdu, modification du code de téléphonie et tests.

[4] Mark B, SMS of Death — Android Telephony Zero-Click Remote DoS, divulgation technique du 29 octobre 2026.

Note méthodologique : les propriétés, la sévérité et le périmètre des branches corrigées sont établis à partir de la documentation officielle Google et OSV ; les manifestations observées sur appareils, notamment les coupures d’appels et les boucles de redémarrage, sont attribuées aux essais du chercheur. Aucun essai offensif n’a été réalisé pour cet article. Les schémas présentent des architectures simplifiées à des fins pédagogiques.