ignema/wapguardPetite application Shizuku qui supprime les messages WAP Push bloqués du « SMS de la mort » (CVE-2026-58882). Material 3 Expressive.
Une petite application Android qui nettoie après le « SMS de la mort » (CVE-2026-58882) : un SMS WAP Push malformé qui fait planter com.android.phone, fait échouer les appels et reste en file d'attente, de sorte que le plantage se répète jusqu'à ce que le message soit supprimé.
WAP Guard n'empêche pas le plantage, car seul le correctif de sécurité Android corrige le bug — le bulletin d'octobre 2026, pour Android 14 à 17. Ce qu'il fait, c'est supprimer les messages bloqués de la file d'attente des SMS en attente afin que le problème ne revienne pas sans cesse, et que le téléphone ait moins de risques de finir dans une boucle de redémarrage.
Sur Android 12 et 13, il n'y a pas de correctif : ils exécutent le même code et ne sont plus pris en charge, donc le nettoyage est la seule atténuation à défaut de mise à niveau.
Via Shizuku, il exécute, en tant qu'utilisateur shell, les mêmes étapes de récupération que celles publiées par le chercheur pour ADB :
content://sms/raw dont le port de destination est WAP Push (2948) et qui sont bloquées depuis plus de 2 minutes. Un WAP Push légitime (notifications MMS, provisionnement opérateur) quitte la file en quelques millisecondes, donc un message encore en cours de distribution n'est jamais touché.WRITE_SMS actuel du shell, l'autoriser temporairement, supprimer exactement ces ID de lignes, restaurer le mode précédent (même si la suppression échoue), puis réinterroger pour vérifier qu'elles ont disparu. Uniquement ces ID — plus ciblé que la suppression address='<SENDER>' des étapes ADB publiées, et sans avoir besoin de connaître l'expéditeur.L'âge d'une ligne ne peut pas être simplement lu dans sa colonne date. Cette colonne contient l'horodatage du centre de services du PDU, et non une heure de réception locale — InboundSmsHandler transmet directement sms.getTimestampMillis() dans la ligne — donc c'est le SMSC de l'expéditeur qui le contrôle, et un message empoisonné daté de plusieurs années dans le futur n'apparaîtrait jamais comme bloqué. Les lignes datées de plus d'une minute dans le futur (dérive d'horloge) sont donc chronométrées à partir du moment où WAP Guard les a vues pour la première fois selon l'horloge locale.
Chaque commande shell a un délai d'expiration, et son code de sortie comme sa sortie sont vérifiés. Une autorisation WRITE_SMS laissée par une exécution tuée en plein nettoyage est révoquée lors de la vérification suivante, car finally ne s'exécute pas lorsque le processus meurt.
L'écran principal compare également le niveau de correctif de sécurité de l'appareil avec le premier niveau corrigé (2026-10-01), et signale Android 12–13 comme non corrigeables. Il s'agit d'un indicateur rapide, pas d'un test au niveau du code : un fabricant pourrait rétroporter le correctif plus tôt.
Un choix exclusif, Off par défaut :
| Intervalle | Coût | |
|---|---|---|
| Off | — | Analyse à l'ouverture de l'application |
| 15 min | Plancher de WorkManager, plus long sous Doze | Négligeable |
| 30 s | Mode surveillance, un service de premier plan | Notification permanente, consommation de batterie accrue |
Un seul sélecteur plutôt que deux interrupteurs, car les intervalles ne s'additionnent pas : WRITE_SMS est un état global du shell et non propre à l'appelant, donc deux nettoyages simultanés se disputent cet état — l'un restaure le mode précédent pendant que l'autre supprime encore, et cette suppression échoue. Les nettoyages sont sérialisés sur un verrou pour la même raison, car le bouton manuel Clear peut chevaucher une vérification en arrière-plan.
L'interrogation périodique est le seul mécanisme disponible. Il n'y a aucun événement auquel se raccrocher : WapPushOverSms.dispatchWapPdu appelle decodeWapPdu avant de construire l'intent WAP_PUSH_DELIVER_ACTION, donc le décodage lève une exception dans com.android.phone et aucune diffusion n'est jamais émise pour un message empoisonné. L'intervalle d'interrogation constitue donc la fenêtre d'exposition, ce qui est précisément la raison d'être du mode surveillance — 15 minutes de boucle de plantage contre un ou deux plantages.
Quel que soit votre choix, ouvrir l'application nettoie immédiatement plutôt que d'attendre la vérification suivante.
Vider la file d'attente y met fin. Les lignes ne sont dangereuses que parce qu'elles se trouvent dans content://sms/raw et sont réessayées à chaque démarrage, donc une fois supprimées, la boucle est brisée — rien n'est laissé corrompu, et aucun nettoyage supplémentaire n'est nécessaire sauf si d'autres messages arrivent.
Le hic, c'est qu'un téléphone qui redémarre toutes les deux minutes ne restera peut-être pas allumé assez longtemps pour que vous puissiez faire quoi que ce soit ; il vaut donc la peine de savoir ce que vous gagnez en coupant la radio.
Le mode avion, ou le retrait de la SIM, empêche l'arrivée de nouvelles copies. Un message que le téléphone n'accuse jamais réception est renvoyé par l'opérateur — l'étude rapporte qu'un seul message a provoqué des pannes intermittentes pendant jusqu'à une semaine. Pas de radio signifie pas de livraison et pas de nouvelles tentatives, ce qui vous donne un téléphone stable sur lequel travailler.
Ce que cela ne fait pas :
Déplacer la SIM vers un téléphone non-Android mérite d'être envisagé : cet appareil accuse réception des messages en attente, l'opérateur cesse donc de les renvoyer, et vous pouvez ensuite nettoyer le téléphone Android sans que de nouvelles copies arrivent en plein nettoyage. Cela découle du comportement de nouvelle tentative plutôt que d'une étape publiée.
En tout dernier recours, adb shell pm clear com.android.providers.telephony vide la file d'attente — ainsi que tous vos réglages SMS, MMS et APN. Effacer les lignes spécifiques, ce que fait cette application, suffit presque toujours.
Rien ici ne survit à un redémarrage, car Shizuku non plus sans root. Après le premier redémarrage forcé, vous devez réappairer le débogage sans fil ; le mode Watch remarque que le binder est mort, s'éteint au lieu de vider la batterie avec des vérifications qui ne peuvent qu'échouer, et vous prévient.
Ainsi, face à une attaque soutenue, la réponse honnête est que WAP Guard raccourcit chaque plantage mais ne peut pas l'arrêter. Les vraies solutions sont le correctif d'octobre 2026, ou le filtrage par votre opérateur des SMS binaires vers le port 2948.