Android's November 2026 Patch Fixes a Zero-Click RCE Flaw

What happened: Google's November 2026 Android Security Bulletin, published November 2, 2026, discloses a critical vulnerability in the Android Framework component, tracked as CVE-2026-58868, that Google itself describes as capable of "remote code execution with no additional execution privileges needed," adding that "user interaction is not needed for exploitation." That combination—remote, no elevated access required, and no tap or click from the victim—is what security teams mean by a "zero-click" bug, and it is the single most severe issue in this month's bulletin.

What to do right now: Check your device's security patch level in Settings, and install any pending update. Patch levels of 2026-11-01 or later close the Framework and System issues, including CVE-2026-58868; patch levels of 2026-11-05 or later also close the kernel, chipset, and vendor-component fixes in the same bulletin. If your phone or tablet has not offered an update yet, keep checking, and if it is no longer receiving monthly security updates at all, that is itself a reason to consider replacing it.

What Google disclosed in the November 2026 bulletin

The Android Security Bulletin is Google's monthly disclosure of vulnerabilities fixed in the Android Open Source Project and in the broader Android ecosystem (System, Android Runtime, Google Play system updates, kernel, and chipset components from partners such as Qualcomm, MediaTek, Arm, Imagination Technologies, and Unisoc). The November 2026 edition was published November 2, 2026, and states plainly: "The most severe of these issues is a critical security vulnerability in the Framework component that could lead to remote code execution with no additional execution privileges needed. User interaction is not needed for exploitation."

That sentence describes CVE-2026-58868 (Android bug reference A-486464711), the only Critical-severity entry in the Framework table. It affects AOSP-based builds of Android 14, 15, 16, 16-QPR2, and 17, according to the "Updated AOSP versions" column of the bulletin's own vulnerability table.

November's bulletin is one entry in a monthly cadence Google has followed for years; the Android Security Bulletins overview page lists every bulletin back to 2015 and explains how the program works, including why some months (such as July 2026, which the index notes shipped with no new vulnerabilities at all) are quieter than others.

The bulletin also notes that Google "notifies Android partners of all issues at least a month before publishing the bulletin," which is standard practice for coordinated disclosure: manufacturers get lead time to build and test their own patches before the public write-up goes live, so a disclosed CVE does not catch OEM security teams by surprise on publication day.

Google's severity rating is not a CVSS number. The bulletin does not publish a CVSS score for this or any other entry; instead it uses Google's own Critical/High/Moderate/Low scale, which the company explains is based on "the effect that exploiting the vulnerability would possibly have on an affected device, assuming the platform and service mitigations are turned off for development purposes or if successfully bypassed." Google's full severity-assessment methodology spells out exactly how it maps a bug's technical impact to Critical, High, Moderate, or Low. In plain terms: Critical plus "no user interaction" plus "remote code execution" is Google's way of flagging the worst category of bug it tracks each month, even without a third-party CVSS figure attached.

Is CVE-2026-58868 being actively exploited?

As of publication, Google's bulletin contains no statement that CVE-2026-58868 is under active or in-the-wild exploitation—the bulletin text we reviewed describes severity and exploit preconditions (no privileges, no user interaction) but does not include the "limited, targeted exploitation" language Google sometimes attaches to actively abused bugs in other monthly bulletins. Readers should treat this as a newly disclosed, unexploited-but-critical flaw rather than a confirmed attack already happening, while still treating the "patch now" guidance as the right response: a no-interaction RCE in a core OS component is exactly the kind of bug that attracts exploitation once technical details circulate.

The bulletin also lists two additional Critical remote-code-execution entries in the System component—CVE-2026-58876 (A-503543341) and CVE-2026-58936 (A-496614216)—plus several Critical elevation-of-privilege and denial-of-service issues in System (CVE-2026-55275, CVE-2026-55283, CVE-2026-58984, CVE-2026-58814, CVE-2026-58882). All of these ship in the same 2026-11-01/2026-11-05 patch rollup, so a device that is fully updated addresses the Framework RCE and the System-level issues together.

Why a Framework-level RCE is worse than most app bugs

The Android Framework is the layer of system services—window management, activity handling, inter-process communication, and the APIs apps call into—that sits beneath the apps users actually see and above the Linux kernel. A vulnerability here is dangerous for the same reason an operating-system kernel bug is dangerous: it is not scoped to a single app's sandbox, and depending on the specific flaw, exploitation can lead to code running with broader system privileges than any individual app would normally have.

"Remote" and "no user interaction" together are the two conditions that matter most for prioritization. A bug that needs a user to install a malicious app or tap a phishing link still requires the attacker to get past app-store review or trick the victim. A bug that needs neither can, in the worst case, be triggered by something a device simply receives—a network packet, a file, a specially crafted message—without any action from the person holding the phone. Google has not published exploit code or a detailed technical write-up of CVE-2026-58868's attack vector in the bulletin itself, and we have not seen one from a vetted third party at time of writing, so the exact delivery mechanism is not yet public.

What platform protections already reduce your risk

Google's bulletin points to a layered set of defenses that lower the odds of successful exploitation even before an individual patch installs. Google Play Protect scans apps on Android devices for malicious behavior on an ongoing basis, which does not stop a Framework-level bug like CVE-2026-58868 directly but does reduce the chance that a malicious app is sitting on your device as a launching point for a chained attack. Newer Android releases also carry platform hardening—sandboxing, exploit mitigations, and memory-safety work—that the bulletin says "makes successful exploitation of many issues on Android more difficult," which is part of why Google continues to urge users still on older, unsupported versions to update to a current release when a device supports it.

None of this is a substitute for installing the patch itself. Mitigations change the odds of a working exploit; they do not close the underlying bug the way the November 2026 update does.

Affected components and patch status

Note that the bulletin uses two patch-level dates on purpose. As Google explains in its own FAQ: "This bulletin has two security patch levels so that Android partners have the flexibility to fix a subset of vulnerabilities that are similar across all Android devices more quickly." A device at 2026-11-01 has the Framework and System fixes, including CVE-2026-58868; a device at 2026-11-05 or later has everything in the bulletin, including kernel and chipset-level items.

How to check your patch level and update

1. Open Settings > About phone > Android version (menu names vary slightly by manufacturer) and look at the "Android security update" or "Security patch level" field.
2. If it does not already read 2026-11-01 or later, go to Settings > System > System update (or your manufacturer's equivalent) and install any available update.
3. Some fixes, including portions of the Framework and System components, can arrive through Google Play system updates rather than a full OS update on devices running Android 10 or later—check Settings > Security > Google Play system update as well.
4. Google's own support article, Check and update your Android version, linked directly from the bulletin, walks through the process for Pixel devices; manufacturer-specific steps differ for Samsung, OnePlus, and other OEM skins, which typically push their own monthly security updates on a similar but not identical schedule.

If your device has not received a security update in several months, or your manufacturer has stopped listing it for monthly patches, that is a separate but related risk: unpatched devices stay exposed to this and every future Framework-level bug indefinitely. Pairing a timely OS update with good baseline hygiene—strong screen-lock settings, cautious app installs, and a secure messaging app for sensitive conversations—reduces overall exposure; see our comparison of Signal, WhatsApp, and Telegram for how far encryption alone can and cannot protect a compromised device.

Who is responsible for pushing the patch to your phone

Google supplies the AOSP source fixes and notifies Android partners "at least a month before publishing the bulletin," per the bulletin's own text, and commits to releasing the corresponding AOSP patches within 48 hours of publication. But Google only controls the update timeline directly for Pixel devices. Every other Android phone—Samsung, OnePlus, Motorola, Xiaomi, and the rest—depends on that manufacturer building, testing, and pushing its own version of the fix, which is why patch availability dates can vary by weeks between brands even for the same underlying CVE. Carrier testing requirements can add further delay on carrier-sold devices.

This is also why Google maintains the two-tier patch-level system described above: it lets a manufacturer ship the Framework/System fixes (2026-11-01) quickly even if the kernel and chipset fixes from a silicon partner like Qualcomm or MediaTek (2026-11-05) take a little longer to integrate and test.

How this compares with other recent "patch now" bulletins

Zero-click, no-privilege RCE flaws in a mobile OS component sit in the same risk tier that has driven urgent patching guidance elsewhere this year—whether it is a network-facing appliance like the SonicWall SMA1000 SSRF flaw or a self-hosted platform like Nextcloud's CVE-2026-110447. In each case the common thread is the same: a bug that does not need the victim to do anything wrong is far more dangerous than one that does, because it removes the human-behavior variable that most security advice (don't click unknown links, verify senders, and so on) is built around.

What's next

Expect three things over the coming weeks. First, AOSP source patches for the issues in this bulletin, which Google says will follow within 48 hours of the November 2 publication and will be linked from the bulletin page as they land. Second, a staggered rollout of manufacturer-specific updates carrying the 2026-11-01 and 2026-11-05 patch levels, arriving on different phones at different times depending on OEM. Third, watch for any update to Google's own bulletin language around CVE-2026-58868—if Google later adds exploitation-status language (the phrasing it uses when a bug is being abused in the wild), that would raise the urgency further, and we will treat that as developing news rather than something confirmed today. Until then, the safest move for any Android user is the simplest one: check your patch level, install the update when it arrives, and do not wait for confirmation of an attack before you do.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage