Google published the October 2026 Android Security Bulletin on 5 October and added AOSP links on 8 October. It has a single patch level, 2026-10-01, and 25 CVEs, seven of them Critical. The most severe, per Google, is a Critical System issue that "could lead to local escalation of privilege with no additional execution privileges needed," with no user interaction.
Two things make this month different from September. Most of the Critical fixes sit in code whose file names point to the Bluetooth stack. And the bulletin restates a change that matters to anyone who builds from source: starting in 2026, AOSP source is published in Q2 and Q4 only.
What's affected
Android 14, 15, 16, 16-qpr2 and 17, depending on the CVE. Devices at patch level 2026-10-01 or later have every fix. There is no second patch level this month, and no kernel or vendor component sections.
Critical, System:
| CVE | Bulletin type | What the CVE record says | AOSP versions |
|---|---|---|---|
| CVE-2026-55269 | EoP | Memory safety issue in FilterCapturedPacket of snoop_logger.cc | 16, 16-qpr2, 17 |
| CVE-2026-55280 | EoP | Out-of-bounds write from uninitialized data, "remote escalation of privilege" | 16, 16-qpr2, 17 |
| CVE-2026-58835 | EoP | Heap overflow in cfg2prop of btif_storage.cc, described as possible remote code execution | 16, 16-qpr2, 17 |
| CVE-2026-58880 | EoP | Race condition in handle_app_val_response of btif_rc.cc | 16, 16-qpr2, 17 |
| CVE-2026-49933 | DoS | Control-flow hijack "in the privileged bluetooth process" via msft.cc | 16, 16-qpr2, 17 |
| CVE-2026-55265 | DoS | Missing bounds check in PduParser.java, remote denial of service | 14 to 17 |
Critical, Framework: CVE-2026-58865, a persistent remote denial of service, also in PduParser.java.
Note that the bulletin's type column and the CVE descriptions don't always match. CVE-2026-58835 is listed as EoP but its record says remote code execution. CVE-2026-49933 is listed as DoS but its record says control-flow hijack leading to privilege escalation. When you triage, read both.
Mainline components: WiFi carries CVE-2026-45524 (a missing permission check in WifiPermissionsUtil.isSystem that the record calls a "possible sandbox escape") and CVE-2026-49878 (an out-of-bounds write in the WPA supplicant's robust AV handling, RCE with System privileges needed). Telephony core carries CVE-2026-58859.
The bulletin makes no statement about exploitation in the wild.
How to check if you're exposed
# Needs 2026-10-01 or later
adb shell getprop ro.build.version.security_patch
# Is Bluetooth on, and is HCI snoop logging enabled?
adb shell settings get global bluetooth_on
adb shell getprop persist.bluetooth.btsnooplogmode
The HCI snoop log is a developer option. CVE-2026-55269 is in the snoop logger's packet filter, so test devices with snoop logging turned on for Bluetooth debugging are the ones to update first.
If you build Android from source, check which branch your manifest tracks:
repo info 2>/dev/null | grep -i "manifest branch"
What to do now
- Patch devices to 2026-10-01. Prioritize Android 16 and 17 devices, since five of the six Critical System fixes apply only to 16, 16-qpr2 and 17.
- Turn Bluetooth off on lab and kiosk devices that don't need it, and switch HCI snoop logging back to disabled when a debugging session ends.
- Install the Google Play system update to pick up the WiFi and Telephony fixes on devices waiting for an OEM OTA.
- If you ship a custom Android build, plan around the Q2 and Q4 source drops. The bulletin says to use the
android-latest-releasemanifest branch, which "always points to the most recent release pushed to AOSP." Fixes that land between drops reach you through the bulletin's patch links, so budget time to cherry-pick them. - Update your triage rules to read the CVE record description, not just the bulletin's type column, for Bluetooth entries.
Why it matters
A quiet month is still a month. Twenty five CVEs is a small bulletin, but most of its Criticals sit in a radio stack that many people never turn off. Where a Bluetooth bug is remotely reachable, the attacker needs to be within radio range rather than get an app installed, which is a different threat model from an app-delivered exploit.
The source schedule is the bigger long-term change. Device makers, automotive teams and anyone running a fork of AOSP now have a twice-yearly rhythm for full source, with monthly fixes delivered as patches on top. That makes your patch-carrying process, not your rebase process, the thing that keeps forks current.
Try it yourself
Take the seven Critical CVEs above and sort them by "reachable over the air" versus "needs local code." Use the CVE record text, not the bulletin type. Then check which of your test devices run Android 16 or 17 and have Bluetooth enabled.
Click through it at your own pace, or open it full screen.
Quick check
Does the October bulletin have a 2026-10-05 patch level for kernel and vendor fixes?
No. Only the 2026-10-01 patch level is listed, and there are no kernel or vendor component sections this month.
An Android 14 device is at 2026-09-05. Which October Criticals apply to it?
CVE-2026-55265 (System) and CVE-2026-58865 (Framework), both in the MMS PDU parser, list Android 14 among the updated versions. The other five System Criticals list only 16, 16-qpr2 and 17.
Which manifest branch does Google say to build from now?
android-latest-release, which points to the most recent release pushed to AOSP. Source is published in Q2 and Q4.
