Qualcomm BootROM Bug Lets Attackers Bypass Secure Boot in Minutes

On April 20, 2026, Kaspersky ICS CERT published technical details for CVE-2026-25262, a vulnerability in the BootROM of seven Qualcomm chipset series that allows an attacker with physical access to write arbitrary data to arbitrary memory addresses before the operating system loads. The flaw, classified as CWE-123: Write-What-Where Condition, irreversibly breaks the secure boot chain at the lowest level of the hardware trust hierarchy. Qualcomm was notified in March 2025, confirmed the vulnerability, and reserved the CVE identifier, but explicitly stated that fixing devices already produced is "fundamentally impossible."

The BootROM as the Final Link in the Chain of Trust

The BootROM is the "bedrock foundation" of the mobile security hierarchy: a read-only memory integrated directly into the silicon that, by definition, cannot be modified once it leaves the factory. As Kaspersky writes in its technical blog, "the most trusted layer of them all" is precisely this component that precedes any operating system, any hypervisor, any software verification mechanism.

It is this very level that CVE-2026-25262 compromises. The vulnerability is not an implementation error in updatable firmware, a secondary bootloader, or the operating system: it is a Write-What-Where Condition in the ARM Primary Boot Loader residing in the BootROM itself. An attacker who reaches the device physically can overwrite any memory address before the secure boot chain even begins, with effects that propagate to every subsequent level of the security stack.

The mechanism is technically significant because it inverts the fundamental assumption on which secure boot rests: that the first code executed is immutable and verifiable. If the BootROM itself hosts an arbitrary-write condition, every subsequent verification — digital signatures, hashes, certificate chains — becomes theoretically bypassable. As the Kaspersky blog notes: "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."

Sahara: From Rescue Protocol to Attack Channel

The Sahara protocol is the heart of the problem. Implemented in the ARM PBL of the BootROM, Sahara is the software component that manages Emergency Download Mode (EDL), a recovery mode designed to let manufacturers and service centers revive unbootable devices. It is a standard industrial tool, not an exotic or hidden feature: every authorized service center working on Qualcomm hardware uses it.

The file-chunk verification logic in Sahara contains the Write-What-Where Condition that classifies the flaw as CWE-123. The Kaspersky blog describes it in unequivocal terms: "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." The HELLO/handshake/upload/execute communication flow, born to save "bricked" devices, thus becomes the vehicle for total compromise.

The risk profile consequently shifts from the traditional domain of cybersecurity — networks, applications, users — to the physical: unauthorized repairs, border crossings, loss, and theft. Any scenario where a device leaves its legitimate owner's direct control for a few minutes becomes potentially catastrophic. Sergey Anufrienko, security expert at Kaspersky ICS CERT, highlighted in a statement carried by BrandIconImage and Manila Standard that rebooting is an insufficient response: "compromised systems may simulate a reboot without actually resetting." Only complete power interruption — physical battery removal or total depletion — guarantees a clean restart.

The Impossibility of a Patch and the Industrial Profile of Affected Chips

Seven chip series are explicitly affected: MDM9x07, MDM9x45, MDM9x65, MSM8909, MSM8916, MSM8952, SDX50. Kaspersky specifies that "every single version released to date" of each series is affected, with no exceptions for revisions or variants. The deployment of these platforms spans critical sectors: MDM9207 powers IoT modems, healthcare monitoring devices, logistics trackers, banking terminals, and smart home gear; MSM8916 drives budget smartphones; SDX50 is used in automotive control units.

Qualcomm's response, as documented by Kaspersky, draws a hard line: "While fixing already-made devices is fundamentally impossible, the company promised to make all future chips without this vulnerability." This statement has immediate operational consequences: no firmware update path exists, no distributable patch exists, no software mitigation can heal the BootROM on already-fabricated silicon. Protection becomes purely procedural, tied to physical control of the device throughout its entire lifecycle.

CVE-2026-25262 was included in Qualcomm's May 2026 security bulletin, confirming institutional acknowledgment. The CVE.org record currently remains in "reserved" status, with no technical details populated: the identifier's existence is verified, but the CVSS score is not stated in available textual sources.

"While fixing already-made devices is fundamentally impossible, the company promised to make all future chips without this vulnerability."

What to Do Now

For organizations managing devices built on the seven affected Qualcomm chip series, risk management shifts to physical and procedural controls. With no retroactive patches, the concrete actions are as follows.

First: inventory active devices mounting MDM9x07, MDM9x45, MDM9x65, MSM8909, MSM8916, MSM8952, or SDX50 chips. The mapping must include industrial IoT, healthcare monitoring, logistics trackers, banking terminals, smart home, budget smartphones, and automotive units.

Second: implement physical custody chains that limit unauthorized access. Since a few minutes of USB connection via EDL are enough for full compromise, every device must remain under direct or supervised control during transport, repairs, and border crossings.

Third: in case of suspected compromise, do not rely on a reboot as proof of cleanup. According to Kaspersky research and Anufrienko's statement, compromised systems can simulate a reboot. The only action that guarantees a clean state is complete power loss: physical battery removal or total depletion.

Fourth: plan replacement with hardware based on future Qualcomm chips explicitly promised to be free of the vulnerability. In sectors with long lifecycles — industrial IoT, healthcare, automotive — this transition requires dedicated budget and timelines.

The Secure Boot Line Shifts from Digital to Physical

Kaspersky ICS CERT's publication transforms the Sahara protocol from an industrial maintenance tool into a critical compromise vector. For organizations managing fleets of devices based on the indicated Qualcomm series, the security boundary no longer runs through firewalls or patch management: it runs through the physical chain of custody.

Qualcomm's statement on the impossibility of retroactive fixes closes any technical discussion of mitigation. The vulnerable device remains vulnerable for its entire physical lifecycle. The question the industry must now face is procedural: who has physical access, under what conditions, with what controls. This is no longer a cybersecurity question in the traditional sense: it is a question of hardware physical security.

Sources

• https://www.kaspersky.com/blog/qualcomm-cve-2026-25262/55811/
• https://www.brandiconimage.com/2026/04/kaspersky-flags-vulnerability-in.html
• https://manilastandard.net/tech/314732460/kaspersky-discovers-vulnerability-in-qualcomm-snapdragon-chips-that-can-lead-to-data-loss-device-compromise.html
• https://www.cve.org/CVERecord?id=CVE-2026-25262
• https://ics-cert.kaspersky.com/vulnerabilities/qualcomm-chipsets-series-write-what-where-condition-vulnerability-in-bootrom/
• https://blackhat.com/asia-26/