SMS of Death : déni de service Android sans interaction (CVE-2026-58882)

TL;DR

• Un SMS WAP Push mal formé fait planter le processus de téléphonie Android et coupe tout appel en cours, y compris vers les services d'urgence, sans aucune interaction ni message visible. Le chercheur Mark B l'a révélé avec une preuve de concept fonctionnelle le 29 octobre 2026.
• La faille se reproduit d'Android 12 à Android 16, et Google n'a livré le correctif que pour Android 14 à 17, dans la mise à jour de sécurité d'octobre 2026. Les appareils Android 12 et 13, soit 18 pour cent du trafic web Android mondial en octobre 2026, ne reçoivent aucun correctif.
• L'impact est un déni de service, pas une exécution de code : le téléphone plante, redémarre et peut entrer dans une boucle qui finit en réinitialisation d'usine. BleepingComputer rapporte l'identifiant CVE-2026-58882 ; les registres CVE publics ne le portaient pas au 2 novembre 2026, et la faille n'est pas au catalogue KEV de la CISA à cette même date.
• Mettez à jour chaque appareil pris en charge vers le niveau de correctif d'octobre 2026 ou ultérieur. Sur Android 12 et 13, aucun correctif n'existe ; planifiez le remplacement ou la mise au rebut des appareils qui ne peuvent pas quitter ces versions.

Suis-je concerné ?

Vous êtes exposé lorsque toutes ces conditions sont réunies :

• L'appareil exécute Android 12 à Android 17. Le chercheur a reproduit le plantage d'Android 12 jusqu'à Android 16 sur un Pixel 9 et plusieurs modèles Samsung, et le code concerné est livré dans chacune de ces versions.
• L'appareil n'a pas reçu la mise à jour de sécurité d'octobre 2026. Le correctif de Google couvre Android 14 à 17 ; les appareils au niveau de correctif d'octobre 2026 ou ultérieur sont protégés.
• L'attaquant connaît, ou peut deviner, le numéro de la cible. Rien d'autre n'est nécessaire : aucune application installée, aucune interaction et aucun accès préalable.

Le chercheur indique que le plantage se reproduit à un taux de 100 pour cent sur tous les appareils testés. Android 12 et 13 représentaient 18,01 pour cent du trafic web Android mondial en octobre 2026, et ces appareils exécutent le même code de téléphonie sans chemin de correctif.

Vérifiez la version d'Android et le niveau de correctif de sécurité de chaque appareil géré :

adb shell getprop ro.build.version.release
adb shell getprop ro.build.version.security_patch

La première commande affiche la version d'Android, par exemple 14. La seconde affiche la date de correctif, par exemple 2026-10-08 ; toute date du 2026-10-01 ou ultérieure signifie que la mise à jour d'octobre est arrivée sur l'appareil.

Comment corriger ?

Mettez à jour chaque appareil Android 14 à 17 vers le niveau de correctif d'octobre 2026 ou ultérieur :

1. Ouvrez Paramètres, puis Sécurité et confidentialité, puis recherchez la mise à jour de sécurité d'octobre 2026 ; installez-la et redémarrez le téléphone.
2. Vérifiez que l'appareil porte bien le correctif : adb shell getprop ro.build.version.security_patch doit afficher une date du 2026-10-01 ou ultérieure. La disponibilité dépend du fabricant et de l'opérateur, et un redémarrage peut être nécessaire pour terminer l'installation.
3. Revérifiez le parc : tout appareil sous Android 12 ou 13 n'a pas de chemin de correctif, et tout niveau de correctif antérieur à octobre 2026 reste vulnérable.

Il n'existe aucune solution de contournement pour les appareils non corrigés. Le message est traité avant d'atteindre une boîte de réception visible, donc aucune application de blocage de SMS, aucun changement de permission ni aucune habitude de mode avion ne l'arrête. Pour les appareils déjà touchés, les étapes de récupération de « Comment savoir si j'ai été compromis ? » effacent les messages poison via ADB ; elles n'empêchent pas les nouveaux.

Quelle est la cause racine ?

Une longueur d'en-tête WSP arrive comme une valeur 64 bits et est convertie en entier signé 32 bits sans aucune vérification de plage. La valeur tronquée sert ensuite de taille de tableau. La faille se situe dans decodeWapPdu de WapPushOverSms, le composant qui transforme les messages courts WAP Push entrants en intents Android, dans la partie frameworks/opt/telephony de la plateforme.

Le décodage lit la longueur d'en-tête comme un uintvar, un entier du protocole WSP d'au plus 5 octets, et la reçoit comme un long Java :

// WapPushOverSms.java:217  header length read as long, cast with no bounds check
int headerLength = (int) pduDecoder.getValue32();

Plus loin, la même valeur dimensionne le tampon d'en-tête :

// WapPushOverSms.java:244  the cast value is used as an array size
byte[] header = new byte[headerLength];

Un message fabriqué déclare un uintvar de 5 octets valant 88 80 80 80 00, qui se décode en long 2147483648. Converti en int signé 32 bits, cela donne -2147483648. Allouer new byte[-2147483648] lève une NegativeArraySizeException sur le thread principal de la téléphonie, et le processus meurt :

E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: Process: com.android.phone
E AndroidRuntime: java.lang.NegativeArraySizeException: -2147483648
E AndroidRuntime:   at ...WapPushOverSms.decodeWapPdu(WapPushOverSms.java:244)

Le code d'avant correctif n'attrapait que ArrayIndexOutOfBoundsException autour de ce décodage, donc la NegativeArraySizeException s'échappait et tuait com.android.phone, le processus qui gère les appels, la connexion au modem et les SMS.

Comment la faille est-elle exploitée ?

La preuve de concept est publique, avec source et application installable, et toute l'attaque tient dans un message court :

1. L'attaquant envoie un data SMS, pas un message texte, vers le port 2948 de la cible, le port WAP Push. La charge utile fait 8 octets : 01 06 88 80 80 80 00 BE, un identifiant de transaction, un type de PDU push, la longueur d'en-tête empoisonnée et un type de contenu.
2. Android livre le message à la pile de téléphonie avant toute boîte de réception. InboundSmsHandler.processMessagePart le passe à WapPushOverSms.decodeWapPdu, qui analyse la longueur d'en-tête uintvar comme 2147483648 et la convertit en -2147483648.
3. L'allocation new byte[-2147483648] lève une exception sur le thread principal de la téléphonie. com.android.phone plante, et tout appel en cours se termine avec la cause de déconnexion CS_DEATH.
4. Android redémarre le processus de téléphonie, ce qui prend 1 à 2 secondes sans service. Le SMS n'ayant jamais été acquitté, l'opérateur le relivre, et le plantage se répète. Le chercheur a mesuré des coupures intermittentes jusqu'à une semaine pour un seul message.
5. Le message poison reste en file dans la base brute des SMS, donc il est rejoué à chaque démarrage. Environ 20 messages ont rendu les appareils testés inutilisables pendant de longues périodes ; un appareil Android 12 est entré dans un cycle de redémarrage en récupération toutes les 90 secondes environ, qui s'est terminé en réinitialisation d'usine.

L'application de preuve de concept sur GitHub envoie le message fabriqué depuis un second téléphone Android. Le chercheur l'a publiée avec l'avertissement qu'il s'agit d'une arme fonctionnelle, et sa licence la limite aux tests autorisés.

Comment l'attaque se déroule-t-elle ?

Un seul data SMS de 8 octets vers le port 2948 fait planter la téléphonie via la conversion non vérifiée, et le message en file fait revenir le plantage.

Que peut faire un attaquant ?

L'impact démontré est un déni persistant du service cellulaire du téléphone, et rien dans la divulgation ne prétend à une exécution de code :

• Tout appel en cours est coupé à la mort du processus, y compris un appel aux services d'urgence, et le téléphone ne peut pas passer d'appels de façon fiable pendant l'attaque ou la boucle qui suit.
• Chaque plantage coûte 1 à 2 secondes de coupure téléphonique. La re-livraison opérateur transforme un message en plantages répétés ; un seul message a maintenu un appareil de test en échec intermittent pendant une semaine.
• Environ 20 messages ont rendu des appareils inutilisables, et sur un Android 12 les messages en file ont provoqué une boucle de redémarrage en récupération toutes les 90 secondes. La récupération décrite par le chercheur exigeait soit une procédure de nettoyage ADB, soit une réinitialisation d'usine complète.
• La victime ne voit rien : le data SMS n'apparaît jamais dans Messages, et le numéro de l'expéditeur n'est jamais affiché, ce qui rend aussi l'attaque difficile à attribuer après coup.

Les conditions sont minimales : l'attaquant n'a besoin que du numéro de téléphone. Aucune application, aucune permission, aucune interaction et aucune position réseau ne sont requises.

Pourquoi le correctif fonctionne-t-il ?

Le correctif de Google est le commit 735d9672603fa206c4b43cb668c1aa273db70b97, « Fix remote DoS in decodeWapPdu », écrit le 15 juin 2026 et livré dans la mise à jour de sécurité d'octobre 2026. Il n'ajoute pas la vérification de plage proposée par le chercheur ; il empêche le plantage d'être fatal et le message de lui survivre :

// WapPushOverSms.java: widen the catch to cover NegativeArraySizeException
-        } catch (ArrayIndexOutOfBoundsException aie) {
+        } catch (RuntimeException e) {

// InboundSmsHandler.java: a failed decode now deletes the poison message
-                    if (processMessagePart(inboundSmsTracker)) {
+                    boolean success = false;
+                    if (inboundSmsTracker != null) {
+                        try {
+                            success = processMessagePart(inboundSmsTracker);
+                        } catch (RuntimeException e) {
+                            loge("Exception delivering message part", e);
+                            deleteFromRawTable(inboundSmsTracker.getDeleteWhere(),
+                                    inboundSmsTracker.getDeleteWhereArgs(), MARK_DELETED);
+                        }
+                    }

NegativeArraySizeException est une RuntimeException, donc le catch élargi absorbe l'échec d'allocation et marque le message comme erreur générique. Le changement associé dans InboundSmsHandler supprime le message de la base brute quand la livraison lève une exception, ce qui brise à la fois la boucle de re-livraison opérateur et la boucle de rejeu au démarrage. Le commit porte le drapeau EXEMPT CVE_FIX de Google et ajoute des tests pour une longueur d'en-tête de 4294967295.

Le correctif resserre le problème au lieu d'en éliminer la cause. La conversion non vérifiée reste dans le code, et l'en-tête mal formé est désormais rejeté en aval au lieu d'être validé à l'analyse. Cela suffit à arrêter le plantage sur Android 14 à 17, et laisse la conversion identique non corrigée sur Android 12 et 13.

Comment savoir si j'ai été compromis ?

Une attaque qui n'a pas abouti peut ne laisser aucune trace, et une attaque réussie laisse un téléphone qui n'arrête pas de planter. Les signes de la faille elle-même sont sans ambiguïté :

adb logcat -d | grep -i "NegativeArraySizeException"

Une occurrence de NegativeArraySizeException: -2147483648 sous com.android.phone est la signature de cet échec de décodage. Les messages poison sont dans la base brute des SMS, qu'aucune application de SMS normale n'affiche. Listez les lignes WAP Push et leurs expéditeurs :

adb shell content query --uri content://sms/raw --projection _id:address:destination_port:date:deleted

Les lignes portant destination_port=134020, l'encodage du port WAP Push 2948 dans la base brute, venues d'expéditeurs inexpliqués sont les messages à supprimer. La récupération ci-dessous a été contribuée par @sakisdog et documentée dans le dépôt de la preuve de concept ; elle doit s'exécuter dans la fenêtre après le démarrage du téléphone :

adb shell cmd appops set com.android.shell WRITE_SMS allow
adb shell "content delete --uri content://sms/raw --where \"address='<SENDER>'\""
adb shell cmd appops set com.android.shell WRITE_SMS default

Remplacez <SENDER> par l'adresse issue de la requête ci-dessus. Si la boucle ne peut pas être brisée, la solution de dernier recours efface tous les SMS et MMS et réinitialise les réglages APN : adb shell pm clear com.android.providers.telephony. Ne choisissez pas « wipe data » à l'invite de récupération sauf si vous voulez une réinitialisation d'usine.

Chronologie

• 2026-05-05 : Mark B signale la faille au programme de récompenses de vulnérabilités Android et appareils de Google.
• 2026-06-15 : un ingénieur Android écrit le correctif 735d9672603fa206c4b43cb668c1aa273db70b97 dans le cadre de téléphonie.
• 2026-10-01 : Google publie le bulletin de sécurité d'octobre 2026, dont les niveaux de correctif sont 2026-10-01 et 2026-10-08. Le correctif arrive pour Android 14 à 17 avec cette mise à jour ; la faille n'est pas listée dans le bulletin.
• 2026-10-29 : Mark B publie l'analyse technique, l'application de preuve de concept et sa source, et @sakisdog documente la récupération ADB.
• 2026-11-02 : les registres CVE publics ne portent toujours pas l'identifiant rapporté CVE-2026-58882, et la faille n'est pas au catalogue KEV de la CISA.

FAQ

Est-ce une exécution de code à distance ?

Non. L'impact démontré est un plantage de processus et le déni de service téléphonique qui s'ensuit. Aucune source de la divulgation ne prétend à une exécution de code, et le commit de correctif de Google qualifie lui-même la faille de déni de service distant.

Le message apparaît-il dans l'application Messages ?

Non. L'attaque est un data SMS vers le port 2948, et Android le traite dans la pile de téléphonie avant toute boîte de réception. La victime ne voit jamais le contenu ni le numéro de l'expéditeur, ce qui rend aussi l'attaque difficile à attribuer après coup.

Pourquoi Android 12 et 13 ne sont-ils pas corrigés ?

Les mises à jour de sécurité du cadre applicatif sont livrées aux versions prises en charge, ce qui pour cette faille signifie Android 14 à 17. Les appareils Android 12 et 13 exécutent le même code de téléphonie mais sortent de cette fenêtre de mise à jour. À moins d'un rétroportage par un fabricant, ces appareils restent vulnérables jusqu'à la fin de leur durée de service.

Comment savoir si le numéro de CVE est correct ?

Considérez-le comme rapporté, pas confirmé. BleepingComputer nomme CVE-2026-58882, et le commit de correctif de Google porte son drapeau EXEMPT CVE_FIX, ce qui confirme qu'un CVE a été attribué. Au 2 novembre 2026, la base CVE publique et la NVD ne portent pas encore l'entrée, donc le numéro peut changer à sa publication.

Un opérateur peut-il bloquer ces messages ?

Aucun document publié ne décrit de filtre côté opérateur. La valeur mal formée vit dans l'en-tête WAP Push d'un data SMS ordinaire, donc le blocage devrait viser ce port ou cet encodage. Aucun tel filtrage n'est décrit dans les sources. La seule protection côté terminal est le niveau de correctif d'octobre 2026.

Que doit faire un parc d'entreprise cette semaine ?

Mettez à jour chaque appareil Android 14 à 17 vers le niveau de correctif d'octobre 2026, inventoriez les versions qui rapportent Android 12 ou 13, et planifiez leur remplacement ou leur mise au rebut. Ces appareils ne peuvent pas recevoir le correctif, et l'attaque n'exige que leurs numéros de téléphone.

Références

• Analyse technique « SMS of Death », avec cause racine, impact et preuve de concept : https://smsofdeath.com/ (publiée le 29 octobre 2026 ; consultée le 2 novembre 2026)
• Application et source de la preuve de concept, et discussion de la récupération ADB : https://github.com/MarkBlah/smsofdeath (publiés le 29 octobre 2026 ; consultés le 2 novembre 2026)
• Commit de correctif Android 735d9672603fa206c4b43cb668c1aa273db70b97, « RESTRICT AUTOMERGE: Fix remote DoS in decodeWapPdu » : https://android.googlesource.com/platform/frameworks/opt/telephony/+/735d9672603fa206c4b43cb668c1aa273db70b97 (écrit le 15 juin 2026 ; consulté le 2 novembre 2026)
• Source de WapPushOverSms.java au commit de correctif, lignes 217 et 244 : https://android.googlesource.com/platform/frameworks/opt/telephony/+/735d9672603fa206c4b43cb668c1aa273db70b97/src/java/com/android/internal/telephony/WapPushOverSms.java (consultée le 2 novembre 2026)
• Bulletin de sécurité Android, octobre 2026 : https://source.android.com/docs/security/bulletin/2026/2026-10-01 (publié en octobre 2026 ; consulté le 2 novembre 2026)
• BleepingComputer, « New Android SMS of Death exploit can remotely crash unpatched phones », source de l'identifiant CVE-2026-58882 : https://www.bleepingcomputer.com/news/security/new-android-sms-of-death-exploit-can-remotely-crash-unpatched-phones/ (publié le 31 octobre 2026 ; consulté le 2 novembre 2026)
• Statcounter Global Stats, part mondiale des versions d'Android, octobre 2026 : https://gs.statcounter.com/android-version-market-share/worldwide (consulté le 2 novembre 2026)
• Catalogue KEV de la CISA, flux vérifié pour CVE-2026-58882 : https://www.cisa.gov/known-exploited-vulnerabilities-catalog (consulté le 2 novembre 2026)