Android
Imagine handing your smartphone over for repair. A couple of days later, you pick it up — and great, it’s working again! But you won’t even realize that your device has been injected with malicious code, allowing attackers to access your smartphone even when it’s locked.
This is the beginning of the story shared by Kaspersky ICS CERT researchers, Alexander Kozlov and Sergey Anufrienko, at the Black Hat Asia 2026 conference. They managed to uncover a vulnerability that flips conventional assumptions about smartphone and IoT security on their head. Its core lies at the very heart of Qualcomm chips.
What is BootROM?
To grasp the severity of this discovery, we first need to look at how a modern device powered by a Qualcomm chip boots up. Think of it as a fortress with multiple layers of security. Each subsequent layer verifies the pass issued by the previous one. The bedrock foundation — the most trusted layer of them all — is the BootROM, a read-only memory baked directly into the silicon that can’t be modified once it comes off the fab.
The BootROM is the very first thing to run when a device powers on. It verifies the signature of the next bootloader, which in turn verifies the next, building a chain of trust all the way up to the operating system. If an attacker can compromise this chain at the BootROM level, it’s game over: the malicious code will execute before the main operating system even has a chance to load.
This is exactly what attackers can do by exploiting the CVE-2026-25262 vulnerability discovered by Kaspersky ICS CERT researchers.
Emergency Download Mode as an entry point
The research began with a protocol called Sahara. This is a component of Emergency Download Mode (EDL). Manufacturers and service centers use it to revive bricked devices: the phone is connected to a computer via USB, and a special utility program signed by the manufacturer (in this case, Qualcomm) is uploaded to it.
Sahara is implemented directly within the ARM PBL (Primary Boot Loader) — the BootROM itself. This means the protocol runs before any operating system boots, before any user access privileges are checked, and before any security controls are activated. The device simply waits for a USB connection, ready to accept data.
The communication scheme looks simple: the device sends a handshake (HELLO) to the computer, the computer selects the mode, a cycle begins to upload the utility program in chunks, and finally, the device executes the uploaded code. And it was within the verification logic of these very file chunks that the vulnerability was identified.
Write-what-where: the core of the vulnerability
In technical terms, the bug introduced by the developers is classified as CWE-123: Write-What-Where Condition. This is about as bad as it gets when it comes to flaws in low-level programming. An attacker can write arbitrary data to an arbitrary address in the device memory.
Without diving too deep into the technical weeds, suffice it to say that by exploiting the discovered vulnerability, attackers can gain access to any data on the device, including user-entered passwords, files, contacts, geolocation data, as well as the hardware sensors like the camera and microphone. In certain scenarios, complete control over the device is possible. Just a few minutes of physical access to the device via a cable connection, and the gadget has been compromised. This creates a risk if you hand your smartphone over to a repair shop, pass it to someone else to set up and install apps on, or just leave it unattended.
Which devices are affected
The CVE-2026-25262 vulnerability affects the following Qualcomm chip series: MDM9x07, MDM9x45, MDM9x65, MSM8909, MSM8916, MSM8952, and SDX50 — every single version released to date, until the vulnerability is patched by the manufacturer.
These are no obsolete museum pieces. The MDM9207, which we used for the bulk of our research, is integrated into modem modules for the internet of things (IoT), industrial equipment, smart home devices, healthcare monitoring systems, logistics trackers, and banking terminals. The MSM8916 powers many budget smartphones, while the SDX50 is used in automotive control units.
How vulnerable devices get attacked
The catch is that the attacker needs physical access to the device to pull this off. In the real world, this translates to:
- Smartphone repairs at third-party repair shops, where the phone is left for several hours
- Customs checkpoints in certain countries, where devices are withheld, inspected, and then returned
- Lost and found scams, where your phone is stolen, tampered with, and then mysteriously found
- Corporate espionage via an insider or a rogue employee
With just a few minutes of physical access to the device an attacker can plant a backdoor so deep inside that standard research tools won’t even detect it in most cases.
Why there’s no patch — and what to do
Qualcomm was notified of the discovery in March 2025 and confirmed the vulnerability in its chips. To identify it, the vendor reserved CVE-2026-25262, and on April 20, 2026, Kaspersky ICS CERT published technical information on the vulnerability and recommendations for users.
Qualcomm included this vulnerability in its May security bulletin. While fixing already-made devices is fundamentally impossible, the company promised to make all future chips without this vulnerability.
If you currently own a device with an affected chip, use our recommendations below to help mitigate the risk of infection.
- Enforce strict physical control: don’t leave your devices unattended, especially when traveling or on business trips.
- Choose only authorized service centers for repairs and maintenance.
- Regularly update your firmware — this won’t patch the BootROM vulnerability, but it can eliminate many related vulnerabilities at higher levels.
- Use a Kaspersky for Android on your device. This will safeguard your gadget from other threats that, combined with this vulnerability, could lead to unpredictable consequences.
If you notice that your gadget with a vulnerable Qualcomm chip starts acting up — overheating when idle, reporting unexpected spikes in network traffic, or exhibiting strange app behavior — you may have fallen victim to this vulnerability. You can wipe the malicious code and reset your device to its baseline state simply by completely cutting its power. This means either pulling the battery or letting it drain all the way to zero until the gadget shuts down entirely. In this case, the malicious code will most likely not persist on the device — during our research, we were unable to confirm that it could achieve persistence in non-volatile memory.
Want to learn more about severe vulnerabilities in Android phones? Check out these posts:
