Patching

Google published the Android Security Bulletin for November 2026 on November 2. It lists 216 vulnerabilities, 23 of them rated Critical in Google's tables. The most severe is CVE-2026-58868, a Critical remote code execution (RCE) flaw in the Android Framework that needs no extra privileges and no user interaction. Two more Critical RCE bugs sit in the System component: CVE-2026-58876 and CVE-2026-58936. Google lists all three for Android 14, 15, 16, 16 QPR2 and 17.

After 25 fixes in October, this month is large, and it is split across two patch levels again. Level 2026-11-01 carries 119 fixes in the Android platform. Level 2026-11-05 adds 97 in the Linux kernel and in chip vendor code from Arm, Imagination Technologies, MediaTek, Unisoc and Qualcomm. Which of those two dates your compliance rules accept decides whether a phone counts as patched while its kernel and modem bugs are still open.

What the two patch levels contain

The patch level is a date string the phone maker writes into each build. It is an assertion by the maker that the build contains every fix Google lists up to that date. Google publishes two levels each month so partners can ship the fixes that are the same on every Android device first, without waiting on chip vendors.

The first level covers the Android Open Source Project (AOSP) code that every phone shares: 65 fixes in Framework, the Java layer apps call for windows, permissions and system services; 53 in System, the native services and libraries underneath; and one High-rated information disclosure in the Android runtime. Eight of the 119 are Critical. Besides the three RCEs, the System list includes three elevation of privilege bugs (CVE-2026-55275, CVE-2026-55283, CVE-2026-58984) and two denial of service bugs, one of which is the SMS of Death bug, CVE-2026-58882.

The second level covers code that differs by hardware. Of its 97 fixes, 15 are Critical: six in the kernel (two in Bluetooth, three in pKVM, the protected hypervisor that isolates sensitive workloads from the main OS, and one in the HID input driver), eight in MediaTek modem firmware and one in a Qualcomm closed-source component. The vendor tables use each chip maker's own severity rating. A phone with a Qualcomm chip does not need the MediaTek fixes, which is why Google says a device at 2026-11-05 must include all applicable patches.

Google ships 17 of the 2026-11-01 fixes early as Google Play system updates, the channel that updates individual system modules through the Play Store on Android 10 and later. Those count as fixed only once the Play system update installs, which the security patch date does not show.

What attackers are doing

Nothing confirmed. The bulletin carries none of the "limited, targeted exploitation" notes Google adds when it knows of attacks, and neither SecurityWeek nor eSecurityPlanet reports exploitation in the wild. Google has not published technical detail on how CVE-2026-58868 is reached. A remote bug that needs no tap and affects every supported Android version still deserves a short deadline, such as two weeks for 2026-11-01.

What to do

Pick the level per device group

For a model whose maker already ships a 2026-11-05 build, require 2026-11-05. For makers that ship 2026-11-01 first, accept 2026-11-01 now and raise the rule to 2026-11-05 once the full build reaches each model, so the kernel and modem fixes do not drop out of sight.

In Microsoft Intune the setting is Minimum security patch level in an Android Enterprise compliance policy, entered as YYYY-MM-DD. Devices below the date become noncompliant, and Conditional Access can then block work apps. Our October bulletin post shows where it sits for each enrollment type and how to stage it by device group.

Check what devices actually report

MDM tools read the one patch string the device reports and trust it. Google's Android Management API, which many Android Enterprise consoles build on, exposes it as softwareInfo.securityPatchLevel and has no separate field for the vendor level. Workspace ONE UEM and other consoles report the same value, though the column and rule names differ.

In Intune, export devices to Log Analytics through the Intune diagnostic settings and group them by patch level and model:

IntuneDevices
| where OS has "Android"
| summarize arg_max(TimeGenerated, *) by DeviceId
| extend PatchDate = todatetime(AndroidPatchLevel)
| extend Status = case(PatchDate >= datetime(2026-11-05), "Full November",
                       PatchDate >= datetime(2026-11-01), "Platform only",
                       "Behind")
| summarize Devices = count() by Manufacturer, Model, Status
| order by Manufacturer asc, Model asc

The "Platform only" rows are the phones that pass a 2026-11-01 rule while still lacking the November kernel and chip fixes. Models stuck in "Behind" after two weeks are the ones to raise with the maker or to plan for replacement.

Check a single phone

On the phone, open Settings, About phone, Android version, and read both the Android security update date and the Google Play system update date. A restart is needed before either applies.

On a test or lab device with USB debugging, adb shell getprop ro.build.version.security_patch returns the platform level. On devices with a separate vendor partition, adb shell getprop ro.vendor.build.security_patch returns the date of the vendor image, where kernel and chip drivers live. A platform string of 2026-11-05 next to an older vendor date is worth a question to the maker.

If a phone cannot be updated yet

Google offers no workaround for CVE-2026-58868. Keep Play Protect scanning on, make sure no app policy allows installs from unknown sources, and move the work profile or the user's access to a patched device if the phone handles sensitive data. Phones whose maker has stopped shipping monthly updates will never reach either November level; list them by model and plan their replacement.

Checking for compromise

There are no published indicators for any of the November CVEs. For phones that stayed unpatched, review the installed apps your MDM reports for anything outside your approved catalogue, and check Play Protect alerts. A phone that restarts or crashes apps for no clear reason deserves a bug report (Developer options, Take bug report) before any reset.

What a patch level rule can tell you

Microsoft's research on Android update adoption notes that the patch level may not account for maker or carrier-specific bugs, and that Google can fix some components through Play system updates without the date changing. A compliance rule turns the maker's claim into an access decision. This month, 2026-11-01 means the shared Android code is fixed; only 2026-11-05 covers the kernel and modem as well. Since the MDM cannot see the vendor date, spot-check it and the Play system update date on one phone of each model every month.

Our safeguarding and hardening team builds MDM compliance rules and reports like the ones above, and our mobile penetration testing covers the apps and devices your staff carry. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: Android Security Bulletin, November 2026, SecurityWeek, eSecurityPlanet, Microsoft Intune Android Enterprise compliance settings, Azure Monitor IntuneDevices table reference, Android Management API devices reference, Microsoft research on Android security update adoption.