Qualcomm GBL Exploit Unlocks Bootloaders on Android 16 Flagships

Researchers released a three-vulnerability exploit chain in early March 2026 targeting Qualcomm’s Generic Bootloader Library, enabling bootloader unlocking on flagship Android 16 phones including Xiaomi 17 and Redmi flagships – the Xiaomi 17, Redmi K90 Pro Max, and POCO F8 Ultra.

Xiaomi had made bootloader unlocking so arduous that many users abandoned the prospect entirely: waiting periods of up to 30 days, detailed questionnaires, and annual per-account device limits stood between enthusiasts and their own hardware. With the proof-of-concept now publicly documented, that barrier has effectively collapsed for devices powered by Qualcomm’s Snapdragon 8 Elite Gen 5.

Android 16 introduces the Generic Bootloader Library as a new boot stage, and its implementation on Qualcomm silicon leaves an authentication gap affecting every non-Samsung OEM using the platform. Manufacturers like Xiaomi had layered their own restrictions on top of Qualcomm’s standard unlock process, but the exploit bypasses those OEM-level controls entirely by manipulating the underlying bootloader state. Qualcomm confirmed fixes were distributed to OEMs in early March 2026, and Xiaomi has already begun patching HyperOS – leaving affected users a narrowing window to act before the loophole closes permanently.

How the Exploit Chain Works

Understanding why the exploit works requires a closer look at how Android 16 handles the new GBL boot stage – and where Qualcomm’s implementation falls short. At its core, the exploit targets a fundamental flaw in how Qualcomm’s Android Bootloader handles that stage.

On Android 16 devices the ABL attempts to download the GBL from the efisp partition but checks only for the presence of a UEFI application, not its authenticity. Qualcomm uses its own verification process rather than UEFI secure boot, and the GBL itself is unsigned – a combination that leaves the door open for arbitrary code execution at the bootloader stage.

Qualcomm introduced the GBL boot stage in its ABL to standardise the boot process across OEMs while retaining control over bootloader behaviour, but that design choice created the authentication gap researchers exploited. Placing a custom UEFI app in the efisp partition sets both the “is_unlocked” and “is_unlocked_critical” flags to “1,” replicating exactly what the standard “fastboot oem unlock” command does.

In effect, the device believes it received a legitimate unlock command, even though the instruction came from an unsigned application loaded through the unverified GBL boot stage. Once both flags are set, the bootloader treats the device as officially unlocked, allowing users to flash custom recovery images, install alternative operating systems, or modify system partitions.

The SELinux Bypass

Writing to the efisp partition is normally blocked because SELinux runs in Enforcing mode. A second vulnerability enables the bypass: the fastboot oem set-gpu-preemption command accepts input arguments without any validation or sanitization. By injecting the “androidboot.selinux=permissive” argument, an attacker can flip SELinux from Enforcing to Permissive mode, removing the partition write restriction entirely and opening the path to write arbitrary data to protected partitions.

Qualcomm’s patch for this vulnerability confirms the command lacked proper input sanitization – a gap that also affected similar commands like “fastboot oem set-hw-fence-value” that were not part of the original exploit chain. By patching both commands, Qualcomm addressed the active exploit vector and a potential secondary attack surface that could have been used independently. That Qualcomm extended its fix beyond the commands directly used in the chain suggests the underlying sanitization problem was more widespread than the exploit itself revealed.

Writing to the Boot Partition

With SELinux disabled, the path to the efisp partition is open – and on Xiaomi devices, a third component delivers the payload. The exploit leverages HyperOS’s MQSAS app’s IMQSNative binder service and its system-level permissions to write the custom UEFI app to that partition. MQSAS (MIUI Quality Service and Secure) runs with elevated privileges that provide a convenient vector for partition writes normally requiring root access.

For non-Xiaomi devices, alternative methods are required depending on each OEM’s app permissions model. Researchers would need to identify an equivalent high-privilege system service on other brands to replicate this step, making portability uneven across the Android ecosystem.

Affected Devices and Scope

Beyond the confirmed Xiaomi devices, the exploit’s reach depends heavily on how OEMs implement Qualcomm’s bootloader. Security researchers have confirmed the exploit on affected flagship models including the Xiaomi 17 series, Redmi K90 Pro Max, and POCO F8 Ultra. Other phones using the Snapdragon 8 Elite Gen 5, such as the OnePlus 15, are theoretically vulnerable, though command sequences may differ depending on each OEM’s bootloader implementation. Circulating online for several days, the exploit had already reached a substantial audience before Qualcomm issued its statement.

Samsung devices are explicitly excluded from the vulnerability. Samsung uses its own S-Boot bootloader instead of Qualcomm’s ABL, making Galaxy phones entirely unaffected despite sharing the same Snapdragon 8 Elite Gen 5 chipset. Because Samsung does not rely on the GBL boot stage at all, neither the unsigned UEFI app trick nor the SELinux bypass applies to its devices – positioning Samsung’s proprietary bootloader as the only architecturally immune solution among major Android OEMs using Snapdragon silicon.

Because GBL is being introduced with Android 16, the vulnerability is tied specifically to that release. Whether it affects Qualcomm SoCs beyond the Snapdragon 8 Elite Gen 5 remains unknown, and scope will likely only become clear as community members test the chain on additional hardware. On the GBL exploit PoC repository, the proof-of-concept has already attracted 761 stars and 260 forks, indicating notable community interest in testing across additional configurations and chipset generations.

Qualcomm and OEM Response

In response to the public disclosure, Qualcomm moved quickly. Qualcomm has already patched the input sanitization vulnerability in the fastboot oem set-gpu-preemption command and fixed similar issues in other commands not part of the exploit chain. A Qualcomm spokesperson confirmed fixes were made available to OEM customers in early March 2026, credited the Xiaomi ShadowBlade Security Lab for using coordinated disclosure practices, and urged end users to apply security updates as they become available from device makers. Notably, the spokesperson’s statement made no mention of which specific devices or chipsets were affected, leaving that determination entirely to OEM partners.

Xiaomi has already begun deploying patches. According to Android Authority, HyperOS 3.0.304.0 builds released in China on or around March 13 are expected to close the exploit loophole. Patch speed reflects the coordinated disclosure timeline: Xiaomi’s own ShadowBlade Security Lab discovered the vulnerabilities and reported them to Qualcomm before the exploit became public, giving the chipmaker time to prepare fixes before community testing began in earnest.

Patch timing has created an unusual dynamic for the Android modding community. Many instructions circulating online advise users interested in unlocking their bootloaders to disconnect their phones from the internet and avoid firmware updates – retaining access to both the SELinux bypass and the unsigned GBL loading mechanism while forgoing other security fixes bundled with the update. Xiaomi had previously imposed some of the strictest unlock policies in the Android ecosystem, including per-account device limits and waiting periods that discouraged tinkering – making this exploit particularly notable for its user base.

Also included in the proof-of-concept repository is a relock EFI binary, making the entire process reversible for users who want to return to a locked bootloader state after installing custom software. Having both unlock and relock binaries available in a single repository lowers the barrier for experimentation considerably, and suggests the exploit authors anticipated users wanting to preserve warranty status or pass device integrity checks required by banking and payment apps. Whether similar exploit chains emerge for other Snapdragon-based Android 16 devices will depend on how quickly OEMs deploy Qualcomm’s patches and whether additional bootloader vulnerabilities surface in the GBL implementation.