New Qualcomm GBL exploit brings bootloader unlocking to flagship Androids

The Snapdragon 8 Elite Gen 5 is the newest flagship SoC from Qualcomm, and it’s undoubtedly one of the best chips that you can find on top Android flagships. We’re seeing widespread adoption of the SoC across phones like the Xiaomi 17 series, the OnePlus 15, and even the recently launched Galaxy S26 Ultra. This week, a new exploit came to light that appears to affect Qualcomm SoCs, primarily the latest Snapdragon 8 Elite Gen 5, allowing users to unlock the bootloader on phones that were previously notoriously difficult to unlock.

What is the Qualcomm GBL Exploit?

A new exploit, dubbed “Qualcomm GBL Exploit,” has been floating around the internet over the past few days. While the identity of the discoverer is contentious, this exploit appears to target an oversight in how GBL (Generic Bootloader Library) is loaded on modern Android smartphones running on Qualcomm SoCs.

In a nutshell, Qualcomm’s vendor-specific Android Bootloader (ABL) is attempting to load the GBL from the “efisp” partition on phones shipping with Android 16. But in doing so, the Qualcomm ABL is merely checking for a UEFI app in that partition, rather than verifying its authenticity as the GBL. This opens the possibility of loading unsigned code onto the efisp partition, which is executed without a check. This forms the core of the Qualcomm GBL exploit.

GBL exploit gets chained with other vulnerabilities

However, writing to the efisp partition isn’t possible by default because SELinux is set to Enforcing, which blocks disallowed actions. To allow the efisp partition to be written to, SELinux needs to be set to Permissive mode, which can be done if you have root access. However, Permissive SELinux is itself required to unlock the bootloader via the GBL exploit and obtain root privileges, leaving you back at square one.

This is where another vulnerability comes into play.

Qualcomm’s ABL accepts a fastboot command called “fastboot oem set-gpu-preemption” that accepts “0” or “1” as the first parameter. However, this command also appears to unintentionally accept input arguments without any checks or sanitization, allowing you to arbitrarily add custom parameters to the command line. This, in turn, is used to append the “androidboot.selinux=permissive” parameter and switch SELinux from Enforcing to Permissive.

The above command surprisingly flips SELinux to Permissive.

After a reboot, the ABL loads the custom UEFI app without any checks, thanks to the GBL exploit. The custom UEFI app then proceeds to unlock the bootloader by setting both is_unlocked and is_unlocked_critical to “1,” which is exactly what the regular “fastboot oem unlock” command does as well.

Xiaomi had introduced strict time-based, questionnaire-based, and device-limited criteria for bootloader unlock on its phones meant for the Chinese market. The process was so strict that most users eventually gave up on the idea of a bootloader unlock — until now, that is.

Reports indicate that Xiaomi will soon patch the app used in the exploit chain, and it may already have done so with the latest Hyper OS 3.0.304.0 builds released in China yesterday. Most instructions floating around the internet about this exploit chain advise users to disconnect their phones from the internet and not update their firmware.

Does the GBL exploit work on other phones?

It’s not immediately clear if the GBL exploit can work on other Qualcomm SoCs beyond the Snapdragon 8 Elite Gen 5. However, since GBL is being introduced with Android 16, that seems to be a requirement for now.

The GBL exploit should affect all OEMs (except Samsung, which uses its own S-Boot instead of Qualcomm’s ABL). However, the chain of vulnerabilities will differ to achieve a successful result.

From what I can see, Qualcomm has already fixed the checks on the fastboot oem set-gpu-preemption command. and even for other commands like fastboot oem set-hw-fence-value that weren’t part of the exploit chain but could be similarly exploited. However, it’s not clear whether the base GBL exploit has been fixed, and if so, whether the fix has been propagated to Android OEMs and then rolled out to consumers.

We’ve reached out to Qualcomm to learn more about the GBL exploit and whether it has been fixed yet. We’ll update this article when we hear back from the company or if we learn more technical details from other sources.

Thanks to developer Roger Ortiz for their help in piecing this together!