Android SMS of Death: CVE-2026-58882 crasht Handys per unsichtbarer SMS

Hinweis: Dieser Beitrag wurde mit KI-Unterstützung erstellt und automatisiert veröffentlicht.

Die Android SMS of Death ist seit dem 29. Oktober 2026 öffentlich dokumentiert – zusammen mit einem funktionierenden Proof of Concept auf GitHub. Geführt wird sie als CVE-2026-58882, einer Kennung, die Google und Forscher nennen, die aber bis heute weder im CVE-Register noch in der NVD publiziert ist. Eine einzige, unsichtbare SMS reicht, um das Telefonie-Modul eines Android-Handys abzuschießen. Ohne Tippen, ohne Benachrichtigung, ohne Eintrag im Posteingang.

Was bei der Android SMS of Death technisch passiert

Der Fehler sitzt im Kern der Android-Telefonie, in der Funktion WapPushOverSms.decodeWapPdu(). Android liest dort die Länge des WSP-Headers aus einer WAP-Push-Nachricht als uintvar ein. Der Wert kommt als long zurück, wird ohne Bereichsprüfung auf int gekürzt und anschließend direkt als Größe eines neuen Byte-Arrays verwendet.

Ein entsprechend präparierter Header ergibt dabei einen negativen Wert. Die Speicheranforderung läuft in eine NegativeArraySizeException auf dem Haupt-Thread der Telefonie – und reißt den Prozess com.android.phone mit. Geliefert wird die Nachricht als Daten-SMS an einen WAP-Push-Port, also genau an der sichtbaren Nachrichten-App vorbei. Das Opfer sieht weder Text noch Absendernummer.

Die Folgen beschreibt der Entdecker Mark B. in seiner Offenlegung so:

• Laufende Gespräche brechen ab, auch Notrufe, weil der Telefonie-Prozess neu startet.
• Pro Nachricht ein bis zwei Sekunden ohne Mobilfunknetz.
• Nicht quittierte Nachrichten werden vom Mobilfunknetz erneut zugestellt und lösen den Absturz erneut aus – im Test bis zu eine Woche lang.
• Rund 20 Nachrichten machten Testgeräte über längere Zeit unbenutzbar.
• Auf einem Android-12-Gerät startete das Handy etwa alle 90 Sekunden in den Recovery-Modus. Ohne ADB-Zugriff über einen Rechner bleibt dort nur der Werksreset.

Reproduziert wurde der Absturz laut Offenlegung von Android 12 bis Android 16, quer über Pixel- und Samsung-Modelle.

AD-Checkliste

Dein AD härten: 12 Sofortmaßnahmen

Das PDF mit Bordmitteln, PowerShell-Prüfbefehlen und 30-Tage-Reihenfolge – per Mail, sobald du deine Anmeldung zum Tech-&-Tacheles-Newsletter bestätigst.

E-Mail-Adresse *

Mit der Anmeldung erhältst du die AD-Checkliste als PDF und danach den Tech-&-Tacheles-Newsletter mit Einordnungen zu Security, KI und Crypto sowie gelegentlichen Hinweisen auf meine Bücher und Produktempfehlungen (auch Affiliate-Links) – eingetragen bist du erst nach Klick auf den Bestätigungslink in der E-Mail (Double-Opt-in). Ich werte aus, ob du den Newsletter öffnest und Links anklickst, um ihn zu verbessern. Abmeldung jederzeit über den Link in jeder E-Mail, Details in der Datenschutzerklärung.

Patch-Lage: Wer geschützt ist – und wer nicht

Gemeldet hat Mark B. die Lücke am 5. Mai 2026 über Googles Android-Schwachstellenprogramm. Der Fix ist belegt: Commit 735d967 im Android-Repository frameworks/opt/telephony, verfasst am 15. Juni 2026, Titel „Fix remote DoS in decodeWapPdu“. Statt die Länge zu prüfen, fängt Google die Ausnahme breiter ab und löscht die auslösende Nachricht aus der Rohdatenbank, damit sie beim nächsten Start nicht erneut zuschlägt.

Ausgeliefert wurde dieser Fix mit dem Android-Sicherheitsstand Oktober 2026 – allerdings nur für Android 14 bis 17. Im öffentlichen Oktober-Bulletin ist die CVE-Nummer nach Recherche von BleepingComputer nicht aufgeführt. Geräte mit Android 12 und 13 stehen außerhalb des Update-Fensters: Sie führen denselben Code aus und bekommen keine Korrektur.

Was das für dich bedeutet

Ein Denial of Service landet in vielen Risikobewertungen reflexartig unter „ärgerlich, aber nicht kritisch“. Hier ist das falsch. Wer in diesem Zustand steckt, erreicht die Notrufnummer nicht zuverlässig – und das trifft keine Serverfarm, sondern genau jene Geräte, die man im Zweifel in der Hand hält. Für Panik gibt es trotzdem keinen Anlass: Der Angriff bringt dem Täter keine Daten, keine Rechte und keinen Zugriff. Er braucht nur eine Telefonnummer und richtet dafür verblüffend viel Schaden an.

Aus CISO-Sicht ist das ein klassischer Fall von Verfügbarkeit statt Vertraulichkeit – und von Patch-Lebenszyklus als Sicherheitsthema. In 25 Jahren IT war das Altgerät fast immer die Lücke: Das ausgemusterte Handy, das als Bereitschafts- oder Alarmtelefon weiterlebt. Genau diese Geräte laufen typischerweise mit Android 12 oder 13. Wer eine BYOD-Flotte oder Feldgeräte betreut, hat hier ein Inventarproblem, kein Patch-Problem. Der Nachbarfall ist noch nicht alt: Beim Pixel-Zero-Day CVE-2026-58704 war es ebenfalls die Mobilfunkschicht, die ohne jede Nutzeraktion angreifbar war.

Konkret jetzt zu tun

• Sicherheitspatch-Ebene prüfen: Einstellungen → Sicherheit → Sicherheitsupdate. Steht dort „1. Oktober 2026″ oder neuer, ist das Gerät versorgt – das gilt allerdings nur für Android 14 bis 17. Der Menüpfad weicht je nach Hersteller ab, bei manchen liegt er unter „Sicherheit und Datenschutz → Updates“. Ältere Stände nachziehen und danach neu starten.
• Im MDM eine Mindest-Patch-Ebene erzwingen: Compliance-Regel auf Patchstand 2026-10-01 setzen, nicht konforme Geräte vom Firmenzugriff ausnehmen. Das wirkt auch bei der nächsten Mobilfunk-Lücke.
• Android 12/13 inventarisieren: Für diese Geräte gibt es keinen Fix. Austauschen – oder ihnen zumindest sofort die Rolle als Bereitschafts-, Alarm- oder Notfalltelefon entziehen.
• Notfall-Erreichbarkeit zweigleisig auslegen: Kein Dienstplan sollte an einem einzigen Android-Handy hängen. Zweites Gerät oder Festnetzweg definieren.
• Playbook ergänzen: Unerklärlicher Neustart-Kreislauf plus abbrechende Gespräche ist ab jetzt ein Prüfpunkt. Vor dem Werksreset den ADB-Weg versuchen – das rettet die Daten.

Und eine Lehre für die Bewertung von Meldungen: Zwischen Googles Code-Fix im Juni und der Auslieferung im Oktober lagen fast vier Monate. Und wer nur Bulletins liest, hätte sie im Oktober gar nicht gesehen: Dort ist sie nicht aufgeführt, laut heise soll sie erst im November-Bulletin nachgereicht werden – dann als kritisch eingestuft. Ein Patchstand ist also kein Kommunikationskanal.

Quellen

• Mark B.: SMS of Death – technische Offenlegung (29.10.2026)
• Android Open Source Project: Commit „Fix remote DoS in decodeWapPdu“
• Android Security Bulletin Oktober 2026
• BleepingComputer: New Android SMS of Death exploit can remotely crash unpatched phones (31.10.2026)
• heise online: „SMS of Death“ – Security flaw crashes Android phones