When security researchers talk about the Android threat landscape, the conversation almost always drifts below the operating system you can see. The lock screen, the app permissions, the update prompts—those are the surface. The vulnerabilities that get actively exploited by real threat actors increasingly live in the silicon and the low-level code: the Qualcomm digital signal processor, the Arm Mali GPU kernel driver, the bootloader firmware, and the Linux kernel that ties it all together. These are the components a sophisticated attacker reaches for when they want to turn a foothold into full device compromise.

For any organization managing a fleet of Android devices—and for the investigators and incident responders at Honeybadger Solutions who see the aftermath—understanding this stack is not academic. It is the difference between a patch that closes a real intrusion path and a checkbox that closes nothing. This article walks through how the Android Security Bulletin cadence works, how chipset and kernel bugs get weaponized in the wild, what it actually means when an Android CVE enters CISA’s Known Exploited Vulnerabilities (KEV) catalog, and why Android’s fragmented update ecosystem makes patch velocity one of the hardest problems in mobile security.

The Android Security Bulletin: Cadence, Patch Levels, and What They Really Mean

Google publishes an Android Security Bulletin on a monthly schedule. Each bulletin documents the vulnerabilities fixed that month, groups them by component, and—critically—ties them to a security patch level. The patch level is the single most useful field a defender can read off a device, and most people never look at it.

Android expresses the patch level as a date string. In any given month, Google typically issues two: one ending in -01 and one ending in -05 (for example, 2024-09-01 and 2024-09-05). The distinction matters. The -01 patch level covers the core Android framework and system components. The -05 patch level is a superset that also includes fixes for device-specific and vendor code—the chipset drivers, the kernel, and the closed-source components from silicon vendors like Qualcomm and Arm. If a device reports the -01 level but not the -05 level, it is missing exactly the class of fixes that this article is about: the chipset and kernel bugs that advanced attackers prize.

Google supplements the main bulletin with a separate Pixel Update Bulletin and the Android Automotive OS Security Bulletin, and silicon vendors publish their own advisories. Qualcomm, for instance, issues a monthly security bulletin describing the vulnerabilities it has patched and handed downstream to device makers. The chain of custody for a single fix is long: a bug is found, the vendor patches it, Google integrates it into the Android Open Source Project and the monthly bulletin, and then every original equipment manufacturer (OEM) has to build, test, and ship it. Every hand-off is a place where patch velocity can stall.

Who Finds the In-the-Wild Exploitation

A recurring name in the discovery of actively exploited Android zero-days is Google Project Zero, often working alongside Google’s Threat Analysis Group (TAG). Project Zero is Google’s elite vulnerability research team; TAG tracks nation-state and commercial-surveillance threat actors. When TAG detects an exploit being used against a real target and Project Zero reverse-engineers it, the resulting root-cause analysis frequently reveals that a “medium severity” driver bug was, in practice, a critical link in a full exploitation chain. Project Zero maintains a public “0-days In-the-Wild” tracker that documents these cases—including one of the CVEs discussed below.

The lesson is uncomfortable but important: a vulnerability’s paper CVSS score is a poor proxy for its real-world danger. A local, non-privileged flaw with a mid-range score can be the exact primitive an attacker needs once they already have code running inside a sandboxed app.

Chipset and Kernel Vulnerabilities Exploited in the Wild

The clearest way to understand the modern Android attack surface is to look at real vulnerabilities that threat actors have actually used. Every CVE below has been verified against the vendor advisory, the National Vulnerability Database, and CISA’s KEV catalog. None is hypothetical.

Arm Mali GPU: CVE-2023-4211

The Arm Mali GPU kernel driver ships in an enormous share of Android devices that do not use Qualcomm’s Adreno graphics. CVE-2023-4211 is a use-after-free vulnerability in that driver: a local, non-privileged user can trigger improper GPU memory-processing operations to gain access to already-freed memory. Because the GPU driver runs in the kernel and is reachable from ordinary app sandboxes, a use-after-free here is a textbook privilege-escalation primitive—exactly what an attacker chains onto a browser or messaging-app exploit to escape the sandbox and take over the device.

The flaw affects a sweeping range of Arm’s driver families: Midgard (r12p0 through r32p0), Bifrost (r0p0 through r42p0), Valhall (r19p0 through r42p0), and the Arm 5th Gen GPU architecture (r41p0 through r42p0), with fixes landing in the r43p0/r44p0 driver releases. Arm’s advisory noted that there were indications of the bug being under limited, targeted exploitation. The in-the-wild activity was surfaced through Google’s Threat Analysis Group and Project Zero. CISA added CVE-2023-4211 to the KEV catalog in November 2023.

Qualcomm’s December 2023 Trio: CVE-2023-33063, CVE-2023-33106, CVE-2023-33107

In October 2023, Qualcomm disclosed a set of vulnerabilities and warned that several were under limited, targeted exploitation—again flagged by Google’s TAG and Project Zero. On December 5, 2023, CISA added three of them to the KEV catalog (alongside an older use-after-free, CVE-2022-22071), with a remediation due date of December 26, 2023 for federal agencies.

CVE-2023-33063 is a memory-corruption (use-after-free) bug in Qualcomm’s DSP Services, triggered “during a remote call from HLOS to DSP.” The digital signal processor is a co-processor that handles audio, imaging, and sensor workloads; corrupting its memory from the high-level operating system (HLOS) is a powerful pivot.
CVE-2023-33106 is memory corruption “while submitting a large list of sync points in an AUX command to the IOCTL_KGSL_GPU_AUX_COMMAND”—a flaw in the Adreno GPU command interface reachable via an IOCTL system call.
CVE-2023-33107 is memory corruption “in Graphics Linux while assigning shared virtual memory region during IOCTL call,” rooted in an integer-overflow condition, again in the GPU/graphics driver path.

Note what these have in common: they are not Android framework bugs. They are Qualcomm chipset and driver flaws that reach Android devices through the vendor supply chain. That is precisely why they show up only in the -05 security patch level, and why a device stuck on -01 remains exposed.

The Pixel Bootloader Firmware Chain: CVE-2024-29745 and CVE-2024-29748

Not every exploited Android zero-day is used by nation-state spyware. In April 2024, Google patched two Pixel firmware vulnerabilities that mobile-forensic companies were reportedly exploiting to extract data from seized devices. Both were reported by the GrapheneOS project and both entered CISA’s KEV catalog in April 2024.

CVE-2024-29745 is an information-disclosure flaw due to uninitialized data in the bootloader’s fastboot firmware. According to GrapheneOS, forensic tools were rebooting devices that were in the “After First Unlock” (AFU) state into fastboot mode, then exploiting the firmware to dump memory—potentially recovering decryption keys and user data. Google’s fix zeroes memory when entering fastboot mode and keeps USB disabled until the wipe completes.
CVE-2024-29748 is a companion logic-error bug that allows a local attacker to interrupt a factory reset triggered through the device-admin API—useful to an adversary trying to preserve data an administrator is attempting to wipe.

This pair is a reminder that “actively exploited” does not always mean remote malware. Physical-access and forensic-extraction chains are part of the mobile threat model, and they matter enormously for anyone handling devices tied to litigation, investigations, or high-risk personnel.

CVE-2024-32896: From Pixel-Only to All of Android

CVE-2024-32896 is a high-severity elevation-of-privilege vulnerability caused by a logic error that allows a local privilege-escalation bypass. Google first disclosed it in June 2024 as a Pixel-specific firmware issue and stated there were indications it “may be under limited, targeted exploitation.” Then, in the September 2024 Android Security Bulletin, Google reclassified it as an Android Framework vulnerability affecting the broader Android ecosystem—not just Pixel hardware—and shipped the fix at the 2024-09-01 patch level. CISA added it to the KEV catalog in June 2024.

The trajectory of this CVE is instructive. A bug that looked device-specific turned out to affect a far larger population once the framework-level root cause was understood. For fleet managers, it underscores why you cannot assume a Pixel-only advisory is someone else’s problem.

What It Means When an Android CVE Enters CISA’s KEV Catalog

CISA’s Known Exploited Vulnerabilities catalog is the U.S. government’s authoritative, evidence-based list of vulnerabilities that are being—or have been—actively exploited in the wild. A CVE does not get added because it is theoretically severe. It gets added because CISA has reliable evidence of exploitation. That evidentiary bar is what makes the KEV catalog such a useful prioritization tool.

The catalog was established under Binding Operational Directive 22-01, “Reducing the Significant Risk of Known Exploited Vulnerabilities,” which required U.S. federal civilian agencies to remediate every KEV-listed vulnerability by a fixed due date—often just two to three weeks out. When CISA added the Qualcomm trio in a November 2023 alert and subsequent entries, it set those short remediation clocks precisely because active exploitation was confirmed.

In June 2026, CISA revoked BOD 22-01 and replaced it with BOD 26-04, “Prioritizing Security Updates Based on Risk.” The KEV catalog remains central—but instead of a single flat deadline for everything on the list, BOD 26-04 tiers remediation by a combination of risk factors (whether a flaw is internet-reachable, whether it is KEV-listed, whether exploitation can be automated, and its potential impact), with the most dangerous, actively exploited bugs carrying the shortest clocks and mandatory forensic triage. For mobile fleet owners the practical takeaway is unchanged and arguably sharper: a KEV-listed, actively exploited Android flaw sits at the top of the priority stack.

For private-sector organizations, the KEV catalog is not legally binding, but treating it as your priority queue is one of the highest-leverage moves in vulnerability management. If a CVE is in KEV, the debate about whether it will be exploited is over—it already has been. Every Android CVE discussed in this article is in the catalog, which means each represents a demonstrated intrusion path, not a speculative one. When you map your fleet’s security patch levels against KEV entries, you convert an abstract patch backlog into a concrete list of “devices a real attacker could compromise today.”

Why Android Fragmentation Makes Patch Velocity So Hard

If Google publishes fixes every month, why do so many devices stay vulnerable for so long? The answer is fragmentation, and it operates at several layers.

The OEM and Carrier Gauntlet

When Google ships a fix in the Android Security Bulletin, it lands in the Android Open Source Project and, for Google’s own devices, in Pixel updates almost immediately. But most Android devices are not Pixels. For everyone else, the fix has to travel through the OEM (Samsung, Motorola, Xiaomi, and dozens of others), which must merge it into their customized Android build, integrate the relevant chipset patches from Qualcomm or Arm, run compatibility and quality testing, and then—in many markets—hand the build to the mobile carrier for additional testing and approval before it reaches the user over the air.

Each step adds latency. A vendor chipset fix disclosed in October can take months to reach a mid-tier device on a specific carrier, if it arrives at all. Budget and older devices frequently fall out of support entirely, leaving KEV-listed chipset and kernel vulnerabilities permanently unpatched on hardware that is still in daily use. This is the structural reason a single Qualcomm or Arm Mali bug can remain a live attack surface across millions of devices long after the fix exists.

Project Mainline and Google Play System Updates

Google’s answer to part of this problem is Project Mainline, delivered as Google Play system updates. Mainline modularizes certain core Android components so Google can update them directly through the Play Store—bypassing the OEM and carrier bottleneck for those specific modules. It is a genuine improvement and has meaningfully accelerated patching for the components it covers.

But Mainline has limits. It updates a defined set of system modules; it does not push kernel patches, closed-source chipset firmware, or bootloader code. The very vulnerabilities most attractive to advanced threat actors—the Qualcomm DSP and GPU driver bugs, the Arm Mali kernel driver, the fastboot firmware—generally sit outside what Mainline can reach. For those, you are still dependent on the full OEM/carrier update chain and the -05 patch level. Mainline narrows the fragmentation gap; it does not close it for the chipset and kernel layer.

A Practical Patch Strategy for Android Fleets

Knowing the threat is only half the job. Here is an actionable approach for organizations managing Android devices—the kind of program Honeybadger Solutions helps clients build and validate.

1. Read and Track the Security Patch Level—Not Just the OS Version

Android version numbers tell you almost nothing about exposure. The security patch level tells you everything. Build an inventory that records each device’s reported patch level (found under Settings and readable programmatically) and, crucially, distinguish the -01 from the -05 level. Prioritize devices that lack the -05 level, because those are the ones missing the chipset and kernel fixes that map to KEV-listed CVEs like the Qualcomm and Arm Mali bugs above. Cross-reference your inventory against the KEV catalog monthly.

2. Enforce Updates Through MDM

A mobile device management (MDM) or enterprise mobility management platform is the backbone of Android fleet patch management. Use it to:

Set and enforce a minimum acceptable security patch level. Devices below it should be flagged and, where policy allows, blocked from accessing sensitive resources through conditional access.
Enforce automatic system and Google Play system updates, so Mainline-delivered fixes land without user action.
Report compliance continuously, giving you a real-time view of which devices are behind and by how much.
Quarantine non-compliant devices—restricting email, VPN, and application access until they update—so a stale device cannot become the soft entry point for a broader breach.

For higher-assurance deployments, prefer devices enrolled in Android Enterprise Recommended programs and, where the threat model warrants it, standardize on hardware with strong first-party update commitments so patch velocity is a purchasing criterion, not an afterthought.

3. Retire Devices That Have Left Support

The hardest but most important control: a device that no longer receives security updates is not a patch-management problem, it is a standing liability. Once an OEM ends security support, KEV-listed chipset and kernel vulnerabilities on that hardware will never be fixed. Establish a hard end-of-life policy tied to the manufacturer’s stated support window, budget for refresh cycles accordingly, and remove unsupported devices from any role that touches sensitive data. No compensating control fully substitutes for a kernel patch that is never coming.

4. Prioritize by Exploitation Evidence, Then Reduce Attack Surface

Use the KEV catalog to sequence your work: exploited-in-the-wild chipset and kernel bugs first. Pair patching with attack-surface reduction—minimize sideloaded apps, restrict developer options and USB debugging, disable unnecessary services, and harden bootloader states—so that even an unpatched primitive has fewer chains to hang off of. Defense in depth buys time that fragmentation would otherwise steal from you.

Conclusion

Actively exploited Android zero-days are, overwhelmingly, a story about the layer beneath the operating system: Qualcomm’s DSP and GPU drivers, the Arm Mali kernel driver, the Linux kernel, and bootloader firmware. Google’s monthly Android Security Bulletin and the -05 security patch level are the mechanism for closing those holes; Project Zero and CISA’s KEV catalog are the mechanisms for knowing which ones are on fire right now. The persistent gap between “fix published” and “fix installed”—the fragmentation problem—is where threat actors live.

Closing that gap is a discipline, not a one-time task. It requires visibility into real security patch levels, MDM enforcement with teeth, honest device-retirement policies, and a prioritization model anchored to actual exploitation evidence.

If your organization runs Android at scale and you are not certain how your fleet maps against the KEV catalog, that uncertainty is itself a finding. Honeybadger Solutions LLC—a Service-Disabled Veteran-Owned Small Business specializing in cybersecurity, digital forensics, and incident response—provides vulnerability management and mobile security assessments that connect the dots between the CVEs in the headlines and the devices in your pockets. If you would like a clear-eyed look at your mobile attack surface and a patch strategy you can actually execute, reach out to start the conversation.

About Honeybadger Solutions

Honeybadger Solutions LLC is a Service-Disabled Veteran-Owned Small Business (SDVOSB) delivering cybersecurity, digital forensics, and investigative services to clients nationwide. Whether you are dealing with a compromised device, a suspected intrusion, or you simply want to get ahead of these threats, our team can help.

What we do:

Digital forensics — mobile devices (iPhone, Android) and computers (Windows, macOS, Linux); intrusion reconstruction, evidence preservation, and expert-witness reporting
Cybersecurity & incident response — breach investigation, containment, malware and spyware analysis, and remediation
Penetration testing & security assessments — finding the gaps before an attacker does
Managed IT & endpoint security — hardening, monitoring, and patch management for small and mid-sized organizations
Private investigations — including TSCM / technical surveillance countermeasures (“bug sweeps”)
Executive & personal protection

📞 (602) 725-2818 · 🌐 honeybadgersolution.com · Veteran-Owned (SDVOSB) · Licensed & Insured

Concerned a device or network may already be compromised? Contact Honeybadger Solutions for a confidential consultation — we handle mobile and computer forensics, incident response, and everything above.

Related from the Honeybadger Android device-security series

Part of Honeybadger Solutions’ security-intelligence series. Explore the rest of the Android coverage:

Sources

Android Security Bulletins — source.android.com — Supports the monthly bulletin cadence, the security patch level concept, and the -01 vs -05 patch level distinction.
CISA Known Exploited Vulnerabilities Catalog — Supports what the KEV catalog is, that entries require evidence of active exploitation, and that all cited CVEs are listed.
CISA BOD 22-01 (Revoked) — The directive that established the KEV catalog and flat remediation deadlines; revoked June 2026.
CISA BOD 26-04: Prioritizing Security Updates Based on Risk — The June 2026 replacement for BOD 22-01; risk-tiered remediation that still treats KEV-listed, actively exploited flaws as top priority.
CISA Alert (Nov 14, 2023) — Supports CISA’s routine KEV-addition process and short remediation clocks.
Google Project Zero — 0-days In-the-Wild: CVE-2023-4211 — Supports Project Zero’s role in analyzing in-the-wild exploitation and the CVE-2023-4211 Mali GPU use-after-free.
SecurityAffairs: CISA adds Qualcomm flaws to KEV catalog — Supports the December 5, 2023 KEV addition of CVE-2023-33063/33106/33107 and the December 26, 2023 due date.
SecurityWeek: Pixel Phone Zero-Days Exploited by Forensic Firms — Supports the CVE-2024-29745 / CVE-2024-29748 forensic-exploitation details and GrapheneOS reporting.
SecurityWeek: Google Warns of Pixel Firmware Zero-Day — Supports CVE-2024-32896 disclosure and limited, targeted exploitation.
SecurityWeek: Android’s September 2024 Update Patches Exploited Vulnerability — Supports the reclassification of CVE-2024-32896 as an Android Framework flaw affecting the broader ecosystem.