Zero-Click-Schwachstelle "SMS of Death" (CVE-2026-58882): Wie manipulierte WAP-Push-Nachrichten Android-Smartphones lahmlegen

Im Jahr 2026 wurde eine kritische Zero-Click-Lücke im Android-Telefoniedienst entdeckt, die ohne irgendeine Nutzerinteraktion komplette Telefonate, Notrufe und sogar das gesamte Gerät zum Absturz bringen kann. Die Schwachstelle - unter dem Namen "SMS of Death" (CVE-2026-58882) bekannt - nutzt manipulierte WAP-Push-Nachrichten, die über den Standard-Port 2948 an das System übermittelt werden. Angreifer können damit Geräte über mehrere Tage hinweg dauerhaft außer Betrieb setzen, während ältere Android-Versionen ohne offizielle Patches ungeschützt bleiben.

Gefahr durch unsichtbare Nachricht

Eine für Nutzer unsichtbare Kurznachricht kann Android-Smartphones unbrauchbar machen. Die manipulierte Nachricht lässt den Telefoniedienst abstürzen und unterbricht laufende Gespräche, auch Notrufe. Sie kann zudem eine Neustart-Schleife auslösen. Nach etwa 90 Sekunden fordert ein Rettungsmechanismus zum Zurücksetzen des Systems auf. Betroffene sollten im Wiederherstellungsmenü keinesfalls "Wipe data" auswählen, um Datenverlust zu vermeiden.

Die Schwachstelle liegt im veralteten WAP-Push-System, über das Mobilfunkanbieter Netzbetreiber-Einstellungen auf Geräte übertragen. Bei der Verarbeitung wandelt Android einen Längenwert fälschlicherweise in eine negative Zahl um. Der Versuch, damit einen Speicherbereich anzulegen, lässt den Telefoniedienst abstürzen. Da Netzbetreiber unbestätigte Nachrichten erneut zustellen, wiederholt sich der Fehler. In Tests verursachte eine einzige SMS bis zu einer Woche lang Ausfälle. Laut dem Forscher können etwa 20 solcher Nachrichten ein Smartphone für längere Zeit unbrauchbar machen.

Technisch vollzieht sich der Angriff über eine speziell kodierte Daten-SMS an Port 2948, den Standardport für WAP-Push-Dienste. Sobald das Paket das Gerät erreicht, liest die Systemfunktion decodeWapPdu() in der Datei WapPushOverSms.java die deklarierte Feldlänge ein. Durch einen fehlenden Vorzeichen- und Bereichsabgleich wird ein manipulierter 5-Byte-Wert zu einer negativen 32-Bit-Ganzzahl umgerechnet (Blaszczyk 2026). Beim Versuch, hierfür Speicher zu reservieren, scheitert Android mit einer unbehandelten NegativeArraySizeException, die den zentralen Telefonie-prozess com.android.phone augenblicklich beendet und bestehende Verbindungen mit dem internen Status CSDEATH trennt (IT-Administrator 2026).

Besonders tückisch ist die Eskalation bei wiederholtem Versand: Treffen innerhalb kurzer Zeit rund 20 bis 30 dieser Steuerungsnachrichten ein, führen die fortwährenden Prozessabstürze zu Schreibkollisionen in der internen SQLite-Nachrichtendatenbank des Betriebssystems. Die resultierende Datenbankkorruption führt dazu, dass das Telefonie-Subsystem fortan bei jedem Neustart sofort abstürzt, was die integrierte Schutzfunktion "Rescue Party" nach rund 90 Sekunden dazu veranlasst, das Löschen aller Nutzerdaten zu fordern (CyberInsider 2026).

Technischer Ablauf: 5-Byte-Fehler und Absturzursache CSDEATH

Die Schwachstelle wird über eine Daten-SMS an den Zielport 2948 übertragen und von der Komponente WapPushOverSms verarbeitet. Enthält der Header die 5-Byte-Folge 88 80 80 80 00, dekodiert Android diesen Wert zu 0x80000000. Ohne Bereichsprüfung wird er zu -2 147 483 648 (32-Bit-signed). Der Versuch, ein Byte-Array dieser negativen Größe zu instanziieren, löst eine unbehandelte NegativeArraySizeException auf dem Haupt-Thread aus, die den Dienst com.android.phone zum sofortigen Abbruch zwingt.

Zielport für WAP-Push-Daten: 2948 (wird direkt vom Telefonie-Framework verarbeitet und umgeht Standard-SMS-Apps)
Fehlerhafter Längenwert im Speicher: -2147483648 (Resultat der Konvertierung von uintvar zu 32-Bit-signed int)

Der Absturz unterbricht laufende Telefonate, inklusive Notrufe, für ein bis zwei Sekunden, bevor das System versucht, den Telefoniedienst neu zu starten.

Ursache der Neustart-Schleife: Beschädigung der SQLite-Datenbank

Treffen in kurzer Abfolge etwa 20 - 30 manipulierte Kurznachrichten ein, kollidieren die wiederholten Prozessabstürze mit Schreibzugriffen auf den internen SMS-Speicher ( content://sms/raw ). Dadurch wird die zugrundeliegende SQLite-Datenbank korrumpiert. Sobald das Gerät neu startet, schlägt der Telefoniedienst sofort fehl, was nach ca. 90 Sekunden den Rescue-Party-Modus aktiviert.

Schwellenwert für permanente Boot-Loops: 20 - 30 Nachrichten (kurz hintereinander)

Historie der Offenlegung und Google-Reaktion

Der Sicherheitsforscher Mark Blaszczyk meldete die Schwachstelle am 5. Mai 2026 über Googles Vulnerability Reward Program. Google stufte die Meldung zunächst als "Won't Fix" bzw. "Non-Security Issue" ein, integrierte jedoch im Oktober 2026 eine Fehlerbehebung in die AOSP-Quellcode-Tags. Die öffentliche Offenlegung erfolgte am 29. Oktober 2026 inkl. Proof-of-Concept auf GitHub, jedoch ohne prominente Aufnahme im monatlichen Android-Sicherheitsbulletin.

Meldung an Google VRP: 05.05.2026
Öffentliche Offenlegung: 29.10.2026

Google bewertete die Schwachstelle als kritisch (CVE-2026-58882) und entwickelte intern bereits im Juni 2026 einen Patch. Der Patch wird für Android 14 bis 17 bereitgestellt, während Android 12 und 13 keinen offiziellen Support mehr erhalten - die Lücke bleibt dort bestehen, sofern Hersteller keine eigenen Korrekturen ausrollen.

Statistiken und Auswirkungen

Verbindungsunterbrechung pro Absturz: 1 - 2 Sekunden (Quelle S1)
Maximale Wiederholungsdauer durch Netzbetreiber: 7 Tage (Quelle S1)
Erfolgsquote des DoS-Angriffs in Tests: 100 % (Quelle S3)
Netzsperrfrist bei Notruf-Inkompatibilität (Australien): 28 Tage (Quelle S1)

Gegenmaßnahmen und Rettung des Geräts

Ein Werksreset ("Wipe data") verhindert das Problem nicht dauerhaft, da das SMS-Center des Netzbetreibers die Nachricht bis zu sieben Tage lang erneut zustellen kann. Die empfohlene Vorgehensweise besteht darin, das Smartphone an einen Computer anzuschließen und das Entwicklerwerkzeug Android Debug Bridge (ADB) zu nutzen. In dem kurzen Zeitfenster nach einem Neustart lassen sich die fehlerhaften SMS-Einträge manuell aus der Warteschlange entfernen:

USB-Debugging muss bereits vor dem Absturz aktiviert und der PC autorisiert sein.
Mit dem Befehl adb shell content delete --uri content://sms/raw --where "_id=?" (Beispiel) die manipulierten Nachrichten löschen.
Das Gerät neu starten - ohne erneute Abstürze.

Ein vorübergehendes Entfernen der SIM-Karte unterbricht weitere Zustellversuche, beseitigt jedoch nicht bereits im lokalen SMS-Cache gespeicherte Daten.

Risiken und Gegenargumente

Hürde USB-Debugging für Endanwender: Die Bereinigung funktioniert nur, wenn USB-Debugging vor dem Absturz freigeschaltet und der PC autorisiert wurde; andernfalls bleibt Laien oft nur der Datenverlust.
Verzögerung durch Drittanbieter-Hersteller: Selbst wenn Google den Quellcode für Android 14-17 bereitstellt, benötigen Geräte von Herstellern wie Samsung, Xiaomi oder Motorola oft Wochen bis Monate, bis OTA-Updates die Endgeräte erreichen.

Häufig gestellte Fragen (FAQ)

Warum taucht die schädliche SMS niemals im regulären Posteingang auf?Die Nachricht wird als WAP-Push-Daten-SMS über Port 2948 direkt an den internen Systemdienst übergeben, der Netzbetreiber-Konfigurationen verwaltet, und umgeht die Benutzeroberfläche der Nachrichten-App vollständig (Quelle: SMS of Death Project ).Hilft es, vorübergehend die SIM-Karte zu entfernen?Ja, das Herausnehmen der SIM-Karte unterbricht den Empfang weiterer Netzbetreiber-Zustellversuche und stoppt die Abstürze, beseitigt aber nicht die bereits in der lokalen SMS-Warteschlange abgelegten Datensätze.Warum beseitigt ein Werksreset das Problem nicht zwingend?Da das Smartphone den Erhalt der Nachricht vor dem Absturz nicht an die Basisstation quittieren konnte, speichert das SMS-Center des Netzbetreibers die Nachricht bis zu sieben Tage lang und stellt sie nach dem Zurücksetzen sofort erneut zu (Quelle: CyberInsider ).

Fazit

Die Zero-Click-Schwachstelle "SMS of Death" demonstriert, wie eine unsichtbare, nur fünf Byte lange Manipulation im WAP-Push-Framework einen kritischen Systemprozess zum Absturz bringen und Android-Smartphones über Tage hinweg lahmlegen kann. Während Google für Android 14-17 bereits einen Patch bereitstellt, bleiben Geräte mit Android 12 und 13 ohne offiziellen Fix verwundbar, und die Verzögerungen bei OEM-Updates verlängern das Risiko. Nutzer sollten dringend prüfen, ob das Update installiert ist, und - im Falle eines Befalls - die ADB-Methode zur Entfernung der fehlerhaften Nachrichten einsetzen, anstatt das Gerät blind zu resetten. Die regulatorischen Implikationen, etwa in Australien, zeigen zudem, dass ein erfolgreicher Angriff nicht nur technische, sondern auch rechtliche Konsequenzen nach sich ziehen kann.