Google's Android bulletin lists 216 flaws, 23 critical, in two patch levels, and names no exploitation

216 table rows, 23 of them critical, and two dates to check

Google's Android Security Bulletin for November, published on 2 November 2026, lists 216 distinct CVE ids in its tables (derived). Of those, 119 sit under the 2026-11-01 patch level and 97 under 2026-11-05, and no id appears in both. Twenty three of the 216 are rated Critical (derived: 8 in part one, 15 in part two). The bulletin prints none of these totals; they come from counting rows in the copy read between 11:14 and 11:18 UTC on Wednesday 4 November 2026.

The most severe item, in Google's words, is "a critical security vulnerability in the Framework component that could lead to remote code execution with no additional execution privileges needed." The bulletin adds that user interaction is not needed for exploitation. The Framework table has exactly one Critical row, CVE-2026-58868 (derived), so that sentence points at it.

What this does not establish is the part most readers want. The sentence describes what an exploit would achieve, not whether anyone is attacking: the bulletin as read has no wording at all on exploitation, in the wild, targeted or limited use (searched, derived). It does not say how many devices are affected, which manufacturers will ship the second patch level or when, how the Framework flaw is triggered, or who reported any of the flaws. A silent bulletin is not a clean one, and it is not an alarm either.

Google makes and operates Android and is writing here about its own platform; every claim below about the bulletin is Google's, attributed. SecurityWeek's report is used only to compare counts, never for a fact the bulletin carries.

What the bulletin states, and what it leaves out

Four statements near the top of the page do most of the work. Patch levels of 2026-11-05 or later address all of the issues. Google says it notifies its Android partners of all issues at least a month before publishing, which puts the partner notice on or before 2 October (derived). It promises that within 48 hours of publication it will release the matching AOSP source patches and revise the bulletin with links, a deadline that falls on 4 November (derived). And it says devices with Android 10 and later may receive security updates as well as Google Play system updates.

On the 48 hours: the page gives a date, not an hour, so the deadline is a date too. CVE.org shows Google's records for the two main CVEs published at about 19:54 UTC on 2 November, so if the bulletin went up then, the window closes about 19:54 UTC on 4 November, which is after the read. The part one tables carried no links at 11:14 UTC, and the version table still showed only 1.0, published 2 November. That is a gap to watch, not a breach. The kernel rows, by contrast, already link to public changes. A banner on the same page also says that from 2026 Google publishes source code to AOSP in the second and fourth quarters; the bulletin does not say how that interacts with its 48 hour promise.

The counts by component and severity (derived)

Every figure in the first table is a count of rows in the bulletin's own tables. Each CVE appears once. Part one is mostly Framework (65 rows) and System (53), with a single Android runtime row. Part two is led by the kernel (31) and MediaTek (30).

Part one prints a Type for each row, so it can be split further. Elevation of privilege is the largest class (62 rows), then information disclosure (33), denial of service (20) and remote code execution (4). The kernel table in part two prints types too: 26 elevation of privilege, 3 denial of service and 2 information disclosure. The chip vendor tables print none, and say their severity ratings come from the vendor and the details from the vendor.

Eight of the 216 ids carry a 2025 year in the id (derived), for example CVE-2025-22424 in Framework. A year in an id is when the id was assigned, not when the flaw was found, and the bulletin does not explain why older ids appear.

The 23 critical rows, and what the public records add

Google's severity page defines Critical by consequence. For Critical it lists "Remote persistent denial of service", defined as permanent and needing a reflash of the operating system or a factory reset; the bulletin separately says its ratings assume platform and service mitigations are off or bypassed. So a Critical label is a statement about the worst case, set by Google, and not about how likely an attack is.

Three public records say a little more about the headline flaw. The CVE.org record for CVE-2026-58868, published by Google as the CVE numbering authority at about 19:53 UTC on 2 November, gives the problem type as remote code execution and the affected versions as Android 14, 15, 16, 16-qpr2 and 17. Its description names one function and one file and a bug class, and nothing about what input reaches it; it is printed in full under Technical details. NVD listed the record as Awaiting Analysis, with no CVSS score, at 11:18 UTC on 4 November. And CISA's enrichment on the record carried an SSVC entry timestamped 2 November with Exploitation: none, Automatable: yes and Technical Impact: total. Those are CISA's judgements, not Google's. None of the 216 ids appeared in CISA's Known Exploited Vulnerabilities catalogue, release 2026.11.03 (3 November, 20:00 UTC), when it was read.

Two limits on that. A value of none and an empty catalogue are statements about what is known on the day; they can change within hours. And "Automatable: yes" is CISA's reading of whether the steps could be chained at scale. It is not a report of exploitation, and this site does not read it as one.

One critical row already has a history on this site

CVE-2026-58882 is listed in System as a Critical denial of service, reference A-517376969, for Android 14 to 17. Brief 554 on this site, an Android text message crash and the gap in October's bulletin, reported on 31 October that this identifier was only reserved, with no published record, and that Google's October bulletin did not list the fix. The October bulletin still does not; what has moved is the rest. The CVE.org record API now returns CVE-2026-58882 as published, dated 2 November at about 19:54 UTC, and the November bulletin lists it.

The link between this row and that crash rests on three matches, not on a Google statement. The CVE record's description names decodeWapPdu in WapPushOverSms.java and a remote denial of service. Brief 554 recorded that Google's public fix commit is titled "Fix remote DoS in decodeWapPdu" and cites bug 517376969, the number in the bulletin row. And that brief reported BleepingComputer using this CVE number for the crash. Neither the bulletin nor the record uses the researcher's nickname, and neither mentions a researcher. A Critical rating for a denial of service fits Google's severity table, which reserves it for persistent cases; the bulletin does not say why it chose it.

What this does not establish: that every phone showing 2026-11-01 carries the fix (the bulletin's promise says it should); anything about Android 13 and earlier, where the bulletin lists no version below 14; or what the researcher claimed, which brief 554 covers. Brief 554's statements were time stamped 31 October, and its "reserved only" point has been overtaken.

Two patch levels: a date string is not a fix you can see

Google's answer to why there are two levels is that partners get "the flexibility to fix a subset of vulnerabilities that are similar across all Android devices more quickly." A build may declare 2026-11-01 only if it includes all part one fixes and every earlier bulletin's. It may declare 2026-11-05 only with all applicable patches in this and earlier bulletins. The strings are dated one day before the bulletin and three days after it (derived), which says nothing about when a device receives them.

Zoom

Part two is where delivery is least visible. Of its 97 rows, 57 carry an asterisk, which the bulletin defines as an issue that is not publicly available, with the update "generally contained in the latest binary drivers for Pixel devices". Those are the Arm, Imagination, MediaTek, Unisoc and Qualcomm closed source rows (derived), with ratings and details supplied directly by the vendors. The other 40 are kernel and Qualcomm rows with public references (derived). For a phone that is not a Pixel, a fix in a chip vendor component has to pass from the chip vendor to the device maker, and often a carrier, before the date string changes (this site's reading). The bulletin does not describe that chain. Google's help page says only that update schedules vary by device, manufacturer and mobile carrier, and that other devices should ask their maker or carrier.

The Pixel is Google's own case. Google's Pixel and Wear bulletins index listed bulletins up to October 2026 at 11:16 UTC on 4 November, with no November page, and a request for the expected November address returned not found. This site therefore cannot say when Pixel phones receive 2026-11-05. SecurityWeek reports that Android XR and Wear OS bulletins were also published on Monday; those were not read.

The third delivery path is Google Play system updates. The bulletin lists 17 ids as Project Mainline components, 13 in System and 4 in Framework, spread across media codecs, MediaProvider, profiling, telephony, Wi-Fi and media framework components (derived). One of the 17 is Critical, CVE-2026-58876, a System remote code execution. The Framework critical, CVE-2026-58868, is not in the list, so on the bulletin's own table it is not described as arriving that way; whether it could is not stated. The bulletin adds that for some devices on Android 10 or later the Play system update will carry a date string matching 2026-11-01. Google's help page lists Google Play system update as its own line, apart from the Android security update line.

The friendly name check: six labels doing the work of a control

A comforting or alarming label is not a control. These six appear in the bulletin or in coverage of it, and each is narrower than it sounds.

The last row is the clearest case. SecurityWeek's headline says over 200; the bulletin's tables give 216. The rounding is fair, but only the count tells you that part one and part two are different sizes of problem.

Where the bulletin and SecurityWeek differ

The counts agree. SecurityWeek's article, published 3 November, gives 119 for part one with the same split, 97 for part two and 17 for Play system updates, all of which match the rows. The differences are in wording: it says two dozen critical issues where the rows give 23, and it says the 17 were patched ahead of the monthly rollout, a phrase the bulletin does not use. It names CVE-2026-58868 as the most severe, which matches the single Critical Framework row. It reports no exploitation of its own.

What to do, in order

The first item follows the bulletin and Google's help page. Items marked as this site's suggestion do not come from Google. No step here involves an attack.

Technical details

The bulletin is a set of tables and prints no code, no configuration and no detection rules. These are the artifacts it and the public records do print, copied as read between 11:14 and 11:18 UTC on Wednesday 4 November 2026. None is exploit detail; the CVE description is the one Google published as the numbering authority. What a defender does with them: the first block is the property makers are told to set, which your device management tool may report under another name (Google does not say which); the others are what to look up when a ticket cites a CVE.

[ro.build.version.security_patch]:[2026-11-01]
[ro.build.version.security_patch]:[2026-11-05]

The Framework critical and the seven System criticals, as the tables print them. The columns are CVE, references, type, severity and updated AOSP versions. The A- prefix is an Android bug id. The 2026-11-01 level is the one that carries these.

Framework
CVE-2026-58868  A-486464711  RCE  Critical  14, 15, 16, 16-qpr2, 17

System
CVE-2026-58876  A-503543341  RCE  Critical  14, 15, 16, 16-qpr2, 17
CVE-2026-58936  A-496614216  RCE  Critical  14, 15, 16, 16-qpr2, 17
CVE-2026-55275  A-522376559  EoP  Critical  16, 16-qpr2, 17
CVE-2026-55283  A-522375782  EoP  Critical  16, 16-qpr2, 17
CVE-2026-58984  A-514731794  EoP  Critical  15, 16, 16-qpr2, 17
CVE-2026-58814  A-517378147  DoS  Critical  14, 15, 16, 16-qpr2, 17
CVE-2026-58882  A-517376969  DoS  Critical  14, 15, 16, 16-qpr2, 17

The Google Play system updates table lists the Project Mainline components. Only CVE-2026-58876 in it is Critical, and CVE-2026-58868 is not in it.

Subcomponent                               CVE
Media Codecs                               CVE-2026-58933
Media Codecs, Media Framework components   CVE-2026-58938
MediaProvider                              CVE-2026-59011, CVE-2026-59022
Media Codecs                               CVE-2026-58876, CVE-2026-58953, CVE-2026-58968
MediaProvider                              CVE-2026-58821
Profiling                                  CVE-2026-59016
Telephonycore                              CVE-2026-49922, CVE-2026-49934, CVE-2026-55289, CVE-2026-58883
WiFi                                       CVE-2026-58867, CVE-2026-58870, CVE-2026-58877, CVE-2026-58884

The descriptions in the CVE.org records for the two rows discussed above, exactly as the CVE numbering authority published them, followed by the CISA enrichment on the first. These are the fullest public statements of what the flaws are. This site adds no detail to them.

CVE-2026-58868 (CVE.org record, CNA description)
In onOutputReceived of FrameDecoder.cpp, there is a possible out-of-bounds write due to a heap buffer overflow. This could lead to remote code execution with no additional execution privileges needed. User interaction is not needed for exploitation.

CVE-2026-58882 (CVE.org record, CNA description)
In decodeWapPdu of WapPushOverSms.java, there is a possible out of bounds read due to an integer overflow. This could lead to a remote denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.

CVE-2026-58868 (CISA ADP, SSVC)
timestamp: 2026-11-02T00:00:00+00:00
Exploitation: none
Automatable: yes
Technical Impact: total
role: CISA Coordinator

The question the bulletin leaves open

Google says it gave its Android partners at least a month's notice, and two dates to put on their builds. The fleets that matter to you are not Google's. Which of your phones will show 2026-11-05, which maker has said when, and what does your device management tool do on the day a phone still reads 2026-10-01?

Key facts