
Google stellt mit dem November 2025 Patch für Android Geräte für die Versionen 13,14,15,16 Fehlerbehebungen bereit, welche kritische Sicherheitslücken schließen. Dabei werden zwei wichtige Schwachstellen behoben:
| CVE | Kurzbeschreibung | Schweregrad |
|---|---|---|
| CVE‑2025‑48593 | Remote‑Code‑Execution (RCE) über eine speziell gestaltete Anforderung | Kritisch (Android 13-16) |
| CVE‑2025‑48581 | Elevation of Privileges (EoP) durch Manipulation der System‑API | Hoch (Android 16) |
Alle noch von Google unterstützten und betroffenen Android-Versionen haben einen Patch welcher bereits über die offiziellen OTA‑Updates verfügbar ist.
Eine Verzögerung der Aktualisierung erhöht die Angriffsfläche erheblich – besonders in Unternehmen mit hoher Compliance-Anforderung.
Hier eine Beispiel-Checklist für die Durchführung einer Aktualisierung der Geräte. Individuelle Anpassungen, welche die Situation und Begebenheiten Ihres Unternehmens reflektieren, können hiervon abweichen.
| Schritt | Aktion | Detail & Warum |
|---|---|---|
| Geräteinventar & Status | Status der Android und Patch-Versionen über datomo MDM Überprüfen. Selektion von Geräten, welche ggf. keine Updates erhalten sollten | Ermittelt, welche Geräte noch nicht auf den aktuellen Patch installiert haben und welche Geräte Update-Fähig sind (z.B. inkompatible Programmversionen, Compliance-Regeln etc.) |
| Rollback‑Plan & Backup | 1. Für jedes Gerät sollte ein Backup bestehen 2. Der Rollback-Workflow sollte bekannt und getestet sein | Schnelle Wiederherstellung im Falle von unerwarteten Problemen (z. B. App‑Crash oder Instabilität). |
| Pilot‑Deploy | 1. Aktualisierung einer Testgruppe, z.B. 5–10 % der Testgeräte. 2. Überprüfung der Gerätefunktion und des Gerätestatus (Gerätelog‑ und Crash‑Reports analysieren, ggf. MDM‑Logs). | Validiert das Update, erkennt eventuelle Inkompatibilitäten mit Unternehmens-Apps oder Hardware‑Spezifika. |
| Update‑Policy & Wartungsfenster | 1. Festlegen eines „Wartungsfensters“, in welchem die wenigsten Nutzer gestört werden, das IT-Team jedoch bereit ist, auf unvorhergesehenes zu reagieren. 2. Nicht Freitags. | Minimiert Nutzer‑Downtime, hält die Update‑Rate kontrollierbar und ermöglicht schnelle Reaktion bei Problemen. |
| Benutzer-Kommunikation | 1. Benachrichtigung der Nutzer, mit Update‑Informationen (Datum, Dauer, erwartete Neustart). 2. FAQ bereitstellen: „Was passiert nach dem Update?“, „Wie kann ich prüfen, ob mein Gerät aktualisiert wurde?“ 3. Support‑Kontakt einbinden für Fragen. | Transparenz reduziert Nutzerfrustration und erhöht Akzeptanz des Rollouts. |
| OTA‑Update senden | 1. Update über MDM‑Server anweisen 2. Status der Aktualisierungen überprüfen | Gewährleistet Verteilung und Erfolg des Updates |
| Geräteüberprüfung | Überprüfung der Gerätefunktion und des Gerätestatus (Gerätelog‑ und Crash‑Reports analysieren, ggf. MDM‑Logs). | Validiert das Update, erkennt eventuelle Inkompatibilitäten bisher unbemerkter Probleme mit Unternehmens-Apps oder Hardware‑Spezifika. |
| Reaktionsplan für Geräte ohne Compliance | 1. Geräte, die nicht den Patch‑Level erreicht haben, z.B. vom VPN- oder WLAN‑Zugriff ausschließen (Conditional‑Access‑Policy). | Verhindert potenziellen Datenverlust bzw. Ausnutzung der CVEs durch nicht gepatchte Geräte. |
Google stellt auf der Seite des Android-Sicherheitsbulletins weitere Informationen zur Verfügung.
