La faille « SMS of Death » d’Android peut interrompre les appels et provoquer des plantages en boucle

13 min de lecture
Android SMS of Death Flaw Can Drop Calls and Trap Phones in Repeated Crashes

Un message invisible peut interrompre un appel téléphonique

Un SMS spécialement conçu, d’à peine huit octets, peut faire planter le service d’appel sur les téléphones Android vulnérables, interrompre les appels en cours et, après plusieurs envois, empêcher un appareil de démarrer normalement. Le chercheur en sécurité Mark Blaszczyk a révélé la faille le 29 octobre 2026, après l’avoir signalée à Google le 5 mai.

Sommaire
  1. Un message invisible peut interrompre un appel téléphonique
  2. Pourquoi le message n’arrive jamais dans la boîte de réception
  3. Un grand nombre devient une longueur négative
  4. Comment une brève panne peut se transformer en défaillance répétée
  5. Pourquoi l’écran de récupération peut annoncer une perte de données
  6. Quelles versions d’Android sont concernées ?
  7. La correction a suivi une autre voie que le signalement
  8. Ce que la correction change
  9. Ce que les propriétaires peuvent faire dès maintenant
  10. Points clés

La vulnérabilité, baptisée « SMS of Death » et référencée dans les articles consacrés à la sécurité sous le numéro CVE-2026-58882, touche le logiciel qui traite certains messages entrants avant qu’ils n’atteignent une application de messagerie. Le destinataire n’a rien à ouvrir, aucune application à installer ni aucun lien sur lequel appuyer. Selon Blaszczyk, le message malveillant ne laisse aucune trace dans la boîte de réception et ne déclenche aucune notification.

Blaszczyk a reproduit le problème sur un Google Pixel 9 équipé du micrologiciel d’avril 2026 et sur plusieurs téléphones Samsung Galaxy, dont des modèles de la série Galaxy A. Il a réussi à reproduire le problème à chaque test sur ces appareils. Un seul message a interrompu le service cellulaire pendant environ une à deux secondes, le temps qu’Android redémarre son processus d’appel.

Blaszczyk, chercheur en sécurité indépendant, a décrit l’effet immédiat sur le processus Android responsable des fonctions téléphoniques :

Un seul SMS WAP Push malformé fait planter com.android.phone sur Android, interrompant les appels en cours, y compris les appels d’urgence, sans aucune intervention de la victime.

Aucune attaque en dehors des environnements de test n’a été signalée, et la mise en garde concernant les interférences avec les services d’urgence relève de l’évaluation du chercheur. Aucune liste complète des appareils, réseaux d’opérateurs et pays concernés n’a été publiée. Le risque concret est qu’une brève interruption du service mette fin à une conversation, tandis que des interruptions répétées peuvent empêcher quelqu’un de garder la ligne lorsqu’il a besoin d’aide.

Publicité

Pourquoi le message n’arrive jamais dans la boîte de réception

Android reçoit le contenu malveillant par WAP Push, un mécanisme ancien qui permet d’envoyer des données et des instructions sur les réseaux mobiles. Parmi ses usages légitimes, il peut inviter un téléphone à récupérer un message multimédia ou à appliquer des paramètres opérateur. Contrairement à un SMS ordinaire destiné à être lu par une personne, ce type de message est traité automatiquement par le logiciel système.

Le composant WapPushOverSms d’Android se charge de ce traitement. La faille se situe dans sa fonction de décodage, au moment où le téléphone lit une information indiquant la longueur d’une partie du message. Comme le service d’appel rencontre l’erreur avant la fin du traitement normal du message, le destinataire n’a aucun texte visible à examiner ou à supprimer.

L’attaque contourne donc le moment où l’on décide habituellement si un message paraît suspect. Ignorer les expéditeurs inconnus ou refuser d’ouvrir des liens ne sert guère contre une défaillance déclenchée pendant le traitement automatique. La protection dépend avant tout de la correction du composant du système d’exploitation qui traite le message.

Un grand nombre devient une longueur négative

Blaszczyk a remonté l’origine du plantage à une erreur de conversion numérique. Android lit la longueur d’un en-tête de message à l’aide d’un type de données capable de contenir de grands nombres, puis convertit cette valeur en entier signé de 32 bits sans vérifier au préalable qu’elle tient dans cette plage.

Dans le test décrit, la valeur 2 147 483 648 devient −2 147 483 648 lors de cette conversion. Un entier signé de cette taille ne peut représenter des nombres positifs que jusqu’à 2 147 483 647. La valeur conçue pour l’attaque dépasse cette limite d’une unité.

Android tente ensuite de réserver de l’espace pour un bloc de données en utilisant cette longueur négative. Une taille négative n’a aucun sens pour cette opération : le logiciel déclenche donc une erreur appelée NegativeArraySizeException. Comme cette erreur n’est pas correctement gérée, elle met fin au processus com.android.phone.

Le message de huit octets contient une séquence de cinq octets qui fournit l’information de longueur problématique. Sa petite taille contribue à la gravité de la faille : un minuscule message entrant peut provoquer une perturbation bien plus importante en faisant planter un processus système central pendant son analyse.

Publicité

Comment une brève panne peut se transformer en défaillance répétée

En temps normal, les opérateurs mobiles attendent d’un téléphone qu’il confirme la réception d’un message. Lorsqu’Android plante avant d’avoir terminé cet échange, l’opérateur peut tenter un nouvel envoi. Un mécanisme conçu pour fiabiliser l’envoi des SMS peut ainsi renvoyer le même contenu dangereux au téléphone.

Android conserve également les messages entrants dans une file d’attente pendant leur traitement. Selon Blaszczyk, un message malformé peut y rester et être traité de nouveau après un redémarrage, ce qui crée une nouvelle occasion de provoquer le même plantage.

Blaszczyk a expliqué pourquoi redémarrer l’appareil peut ne pas mettre fin à la perturbation :

Le message malformé reste dans la file d’attente et est traité de nouveau à chaque démarrage ; le téléphone peut donc planter au démarrage jusqu’à ce qu’il soit supprimé.

Blaszczyk a averti qu’une vingtaine de messages pouvait rendre un appareil inutilisable pendant une période prolongée. Les tests ont également décrit l’arrivée rapide d’environ 30 messages avant l’apparition de défaillances plus persistantes. Ces chiffres correspondent aux conditions de test et ne constituent pas un seuil précis que tous les téléphones atteindraient.

Le chercheur attribue certaines défaillances durables à la corruption de la base de données SQLite utilisée pour stocker les SMS entrants. SQLite est un système de base de données léger, utilisé par les applications et les systèmes d’exploitation pour conserver des données structurées. Si des enregistrements nécessaires au démarrage provoquent sans cesse une défaillance, le service d’appel peut planter à chaque tentative de récupération du téléphone.

Lors des tests, les nouveaux envois de l’opérateur ont provoqué des problèmes d’appel intermittents pendant une semaine au maximum, y compris une perturbation attribuée à un seul message malveillant. La combinaison des messages conservés par l’opérateur et des enregistrements stockés sur le téléphone aide à comprendre pourquoi les effets peuvent persister après l’envoi initial.

Pourquoi l’écran de récupération peut annoncer une perte de données

Android comprend un mécanisme de récupération automatique appelé RescueParty. Lorsqu’un composant critique plante de façon répétée, il tente de rétablir la situation et peut faire passer le téléphone en mode récupération au bout d’environ 90 secondes. L’utilisateur peut alors voir s’afficher une option d’effacement des données.

Une réinitialisation aux paramètres d’usine efface les données et les réglages locaux. D’après Blaszczyk, les tests ont montré que cette réinitialisation n’offrait qu’un répit temporaire, car l’opérateur pouvait ensuite renvoyer les messages dont la réception n’avait pas encore été confirmée. Une personne choisissant d’effacer son téléphone risque donc de perdre ses données personnelles, puis de subir de nouveaux plantages.

Publicité

Blaszczyk a décrit une méthode de récupération au moyen d’Android Debug Bridge, ou ADB, un outil qui permet à un ordinateur de communiquer avec un appareil Android à des fins de développement et de maintenance. La procédure consistait à effacer les enregistrements SMS concernés pendant une courte période où le téléphone était accessible.

La récupération par ADB nécessite un accès technique, et de nombreux propriétaires n’auront pas configuré au préalable la connexion nécessaire. La méthode décrite par le chercheur consistait aussi à déplacer une carte SIM physique dans un téléphone qui n’utilise pas Android, afin que les messages en attente puissent être reçus et leur réception confirmée. Il a prévenu que la récupération pouvait être plus difficile lorsque l’abonnement mobile utilise une eSIM.

En cas de plantages répétés, la priorité concrète est de demander l’aide d’un technicien qualifié avant de choisir l’effacement des données. La procédure de récupération décrite implique des enregistrements système et des paramètres d’accès : elle est donc plus complexe que la suppression d’un SMS ordinaire.

Quelles versions d’Android sont concernées ?

Les comptes rendus techniques indiquent que la principale plage de versions concernées va d’Android 12 à Android 16. Certains la prolongent jusqu’à Android 17. Les tests citent précisément des appareils Pixel et Samsung Galaxy, mais la portée présumée est plus large, car le problème se situe dans du code de téléphonie partagé par Android.

La correction annoncée en octobre 2026 couvre Android 14 à Android 17. Les téléphones fonctionnant encore sous Android 12 ou Android 13 posent le problème de prise en charge le plus évident : ces versions ne bénéficieraient plus de l’assistance de sécurité actuelle de Google, et leurs propriétaires dépendent donc de leur fabricant ou d’un autre fournisseur du système d’exploitation pour obtenir une correction.

La version d’Android d’un téléphone et l’état de ses mises à jour de sécurité répondent à deux questions différentes. La version indique la génération du système d’exploitation. Les informations sur les mises à jour de sécurité permettent de savoir à quand remonte la dernière correction de ses vulnérabilités. Deux téléphones fonctionnant sous la même version d’Android peuvent recevoir les correctifs à des dates différentes.

Les fabricants et les opérateurs influent sur le calendrier de déploiement des mises à jour pour chaque modèle. Les propriétaires doivent vérifier la date de la mise à jour de sécurité dans les paramètres, généralement sous « À propos du téléphone », « Sécurité » ou « Mises à jour logicielles », et installer la dernière version disponible. Pour cette faille, la correction annoncée est associée à la mise à jour d’octobre 2026, mais il est utile de vérifier les informations du fabricant pour le modèle concerné lorsque la date de déploiement n’est pas claire.

Publicité

La correction a suivi une autre voie que le signalement

Selon Blaszczyk, Google a d’abord considéré son signalement comme un problème non lié à la sécurité et l’a clôturé sans accepter la mesure qu’il demandait. Son récit publié fait état de recours supplémentaires et d’un nouveau classement comme problème non lié à la sécurité le 29 octobre. Pendant ce temps, les ingénieurs d’Android élaboraient une correction.

La chronologie rapportée distingue le traitement du signalement du chercheur de l’intégration du code dans le processus de développement et de mise à jour d’Android :

  • 5 mai 2026 : Blaszczyk signale la vulnérabilité à Google pour la première fois.
  • 15 juin : Google crée un correctif technique pour la défaillance du traitement des messages.
  • Juillet : GrapheneOS indique avoir reçu le correctif dans le cadre des préversions de sécurité et l’avoir intégré au cours du mois.
  • 5 août : le correctif aurait été intégré au processus de développement de Google.
  • Octobre : la modification est rendue publique dans l’Android Open Source Project et intégrée aux mises à jour d’Android 14 à Android 17.
  • 29 octobre : Blaszczyk rend ses conclusions publiques.
  • Novembre : GrapheneOS indique que la vulnérabilité devrait figurer dans le bulletin de sécurité d’Android.

GrapheneOS a avancé qu’un problème de communication interne pourrait expliquer la manière dont Google a traité le signalement. Il s’agit d’une hypothèse des développeurs du projet de système d’exploitation. Les éléments décrits ici font état à la fois d’un signalement rejeté et d’une modification technique destinée à empêcher le plantage.

Le bulletin de novembre constituait la prochaine étape annoncée pour la publication. GrapheneOS indiquait avoir déjà intégré le correctif en juillet : la date ultérieure du bulletin concernait donc la documentation publique sur la sécurité, et non le premier déploiement du correctif.

Ce que la correction change

Selon les informations publiées, le correctif de Google élargit la gestion des exceptions afin qu’Android intercepte l’erreur d’exécution et retire le message malformé de la file d’attente. Le traitement peut ainsi se poursuivre au lieu de planter sans cesse sur ce message.

Blaszczyk avait proposé de vérifier la validité de la longueur déclarée dans l’en-tête avant de la convertir. L’approche technique rapportée consiste plutôt à gérer l’erreur et à supprimer le message qui en est à l’origine. Concrètement, la suppression de cet enregistrement remédie aussi au traitement répété qui peut transformer un envoi unique en problème de service durable.

La correction est décrite comme intervenant lorsqu’elle rencontre un message malformé. La vingtaine de messages évoquée dans les tests illustre la gravité des perturbations répétées ; le correctif n’a pas besoin d’attendre un nombre donné de messages avant d’agir.

Publicité

La publication d’un correctif dans l’Android Open Source Project signifie que le code sous-jacent peut être intégré à des logiciels Android. Pour qu’il parvienne à un propriétaire donné, une mise à jour adaptée à son téléphone doit encore être compilée puis distribuée. Il est donc important de vérifier la prise en charge d’un modèle précis, même si Google a corrigé le code.

Ce que les propriétaires peuvent faire dès maintenant

Les propriétaires de téléphones encore pris en charge doivent installer la dernière mise à jour de sécurité du système et consulter les notes de version ou les informations d’assistance de leur fabricant pour vérifier que le correctif est bien inclus. Les utilisateurs d’Android 12 ou Android 13 devraient demander si leur modèle recevra un correctif ou pourra passer à une version d’Android bénéficiant d’une prise en charge.

Blaszczyk a publié une application de démonstration et son code source, ce qui renforce l’urgence d’un déploiement rapide du correctif. Sa publication met en garde contre tout ciblage d’autres personnes, notamment parce qu’une perturbation des communications d’urgence peut entraîner un grave danger.

Les utilisateurs dont le téléphone perd régulièrement le réseau cellulaire ou redémarre devraient contacter le fabricant de leur appareil ou un réparateur qualifié. Un téléphone affichant un écran de récupération doit être manipulé avec précaution si son propriétaire souhaite préserver ses données. Toute personne ayant besoin d’une aide urgente alors que son téléphone ne peut maintenir un appel devrait utiliser un autre téléphone en état de marche.

Pour les propriétaires, l’essentiel est simple : cette défaillance se produit avant même qu’un message suspect puisse être évalué. Pour les appareils encore pris en charge, la protection la plus concrète décrite ici consiste à installer une mise à jour de sécurité à jour, distribuée pour le téléphone effectivement utilisé.

Points clés

  • Un SMS WAP Push malformé peut faire planter le service d’appel d’Android sans aucune intervention du destinataire.
  • Blaszczyk a reproduit la faille sur un Pixel 9 et des appareils Samsung Galaxy ; les interruptions individuelles ont duré environ une à deux secondes.
  • Le traitement répété et les nouveaux envois de l’opérateur peuvent entraîner des perturbations prolongées, des plantages à répétition et l’apparition d’écrans de récupération.
  • La correction annoncée en octobre 2026 couvre Android 14 à Android 17. Les propriétaires d’appareils sous Android 12 ou Android 13 dépendent d’une éventuelle prise en charge supplémentaire par leur fournisseur.
  • Aucune attaque en dehors des tests n’a été signalée. Le chercheur a averti que des interruptions d’appel pourraient empêcher d’accéder aux services d’urgence.
  • Une réinitialisation aux paramètres d’usine efface les données et peut être suivie de nouveaux envois de messages malveillants. Une récupération technique peut nécessiter ADB.
Partager cet article

À lire aussi