Android Security Bulletin September 2026 Patches 180 Flaws, Three Critical Remote Code Execution Bugs in NFC and One in Bluetooth
Three of the critical remote code execution fixes sit in the NFC module and one in Bluetooth, and no companion app can compensate for a radio stack compromised beneath it
Andrew Chukwu, CISSP, MBA | Editor-in-Chief
Sep 11, 2026
Google published the Android Security Bulletin for September 2026 on September 8, then reissued it a week later as version 1.1 with an updated issue list and links into the Android source tree. The bulletin does not read like a vendor advisory becaus there's no product list or headline count. Google sorts each fix under the part of Android it touches, from the runtime and framework through the system layer and kernel to the chipset vendors whose parts ship inside the phone. My tally from version 1.1 is 180 CVE entries, 95 under the 2026-09-01 patch level and 85 under 2026-09-05, with fixes built for every version from Android 14 through Android 17. Device manufacturers had the details at least a month before the public did, which is Google's standing practice and the only timing the bulletin gives.
The System component is where this month's weight sits. Google rates eight of its entries as critical remote code execution, and its section note says the most severe of them needs no additional privileges and no user interaction. Three are in the NFC module, CVE-2026-28639, CVE-2026-49882 and CVE-2026-49884. One is in the Bluetooth module, CVE-2026-49921, which also carries a critical elevation of privilege in CVE-2026-45515.
One is in wpa_supplicant, CVE-2026-28662, the Wi-Fi component. The NFC module adds three more critical elevation of privilege entries and a critical denial of service, and the Kernel section lists a critical elevation of privilege in its NFC subcomponent, CVE-2026-31629, next to a High-rated flaw in the Human Interface Device subcomponent, CVE-2026-43049.
One detail in the bulletin decides how fast any of this reaches a phone. Google's Google Play system updates table lists the fixes it can push directly through Mainline: ART, media, MediaProvider, telephony, UWB, Wi-Fi and adbd. Bluetooth and NFC are not on that list. If you read it plainly, those fixes arrive when the device maker ships its own update, and Google states only that partners were told at least a month before publication.
What this means for the Medtech Industry
Although nothing in this latest bulletin mentions a medical device, and Google publishes no CVSS scores, only its own severity ratings. That does not make it irrelevant. What matters is which layer these fixes sit in, and this month that layer is the radios underneath every companion app.
If your product pairs with a phone or tablet over Bluetooth or NFC, these fixes sit directly under the connection your app relies on. The app can be well built and still inherit whatever happens in the radio stack beneath it, and this month, that stack carried critical remote code execution on both radios.
The second exposure is one you control such as the minimum Android version and patch level your app accepts before it will install or run. Google built this month's fixes for every version from Android 14 to Android 17, which means a phone on Android 14 is affected and needs the update. Whether it ever gets one is a different question, because the update has to come from the phone's maker, and for the Bluetooth and NFC fixes there is no other route. So an app whose only rule is for example "Android 14 or later" will happily pair with a phone that is still running last year's patch level.
This has some regulatory aspects since for instance the EU MDR Annex I, Section 23.4(ab) requires the instructions for use to state the minimum hardware, IT network and IT security requirements needed to run the software as intended. A minimum patch level is exactly that kind of requirement, and it belongs in the instructions for use next to the OS version. The OS version tells you which phones can install the app while the patch level tells you which phones are safe to pair with, and that is the number that moves every month. Setting it once at launch and never revisiting it means the floor quietly becomes the exposure, which is what happened this month for anyone whose rule still reads Android 14 with no patch date attached.
Quick ToDos in the coming days
Start with checking what minimum Android version and security patch level your companion app enforces at install and at runtime, and whether that floor still holds now that critical fixes reach Android 14.
If your device pairs over Bluetooth or NFC, treat CVE-2026-49921 and the three NFC RCE entries as the ones to track by device maker, since neither module is on Google's Play system updates list this month.
If your products embed Android as their own operating system, open a change assessment against the 2026-09-05 level and keep the outcome as a quality record, whether the answer is update, defer or not affected.
As stated ealieer, no medical device is named in this release. however, the exposure is the radio underneath your app and the patch floor your labelling never set, and both are correctable before the next bulletin.
Source
How did this land?
Be the first to react.