Qualcomm BootROM Sahara/EDL write-what-where secure boot bypass

CVE-2026-25262 is a BootROM CWE-123 write-what-where flaw in Qualcomm's Sahara handling inside Emergency Download Mode (EDL). Public Kaspersky research says it affects all versions of the MDM9x07, MDM9x45, MDM9x65, MSM8909, MSM8916, MSM8952, and SDX50 chipset series, letting an attacker with physical access bypass the secure boot chain and run code with maximum privilege before the OS comes up.

Reality check: the *technical* impact is ugly, but the *operational* attack path is narrow. There is no useful vendor baseline to compare against, and the only public CVSS-like vector we found collapses to 0.0 because CVSS v3.1 treats AV:P awkwardly; that badly understates the per-device impact, but it still does not make this a Monday-morning fleetwide fire drill because the exploit requires hands-on device custody and an EDL/USB servicing path.

Why this verdict

• Physical custody is the gate. The attacker needs hands-on access to the device and a servicing/recovery interaction path, which immediately removes this from the common internet-exposed exploit queue.
• This usually implies a prior failure in process or trust. Internal handling, third-party repair, customs seizure, depot workflows, or supply-chain access are all narrower and less scalable than network exploitation, so the reachable enterprise population drops hard.
• The impact is too deep to ignore. Secure-boot bypass and pre-OS arbitrary code execution with maximum privilege create a high-value compromise on each affected device, especially where credentials, telemetry, microphones/cameras, payment flows, or operational control functions are present.

Why not higher?

It is not higher because the exploit path is not remotely reachable, appears to require physical custody, and carries high technical complexity. We also found no KEV listing and no strong evidence of broad in-the-wild campaigns, which matters when you are triaging thousands of assets.

Why not lower?

It is not lower because the vulnerability sits in BootROM, below the OS trust boundary, and can bypass secure boot with maximum privilege on the device. The lack of a real patch for existing silicon is another amplifier: if an affected asset matters, the residual risk is real even without mass exploitability.

1. Lock the repair chain — Use only authorized depots, maintain documented chain-of-custody, and forbid unsupervised third-party repair for affected assets. For a MEDIUM verdict there is no mitigation SLA; implement this during normal process hardening, but do it before the next repair, redeployment, or travel cycle for any affected fleet.
2. Inventory affected chipsets — Map devices, modems, tablets, IoT nodes, automotive units, and industrial endpoints to the named Qualcomm series so you know where this risk actually exists. There is no mitigation SLA for MEDIUM — go straight into normal asset-governance work and finish inventory well inside the 365-day remediation window.
3. Restrict EDL and depot access — Physically secure service cables, flashing stations, and any workflow that can place devices into EDL or connect to them in recovery mode. For MEDIUM there is no mitigation SLA; fold this into hardware-security baselines and maintenance SOPs before the next field-service event.
4. Force full power loss after suspicious custody events — If an affected device has been out of custody, repaired, or handled suspiciously, perform a trusted inspection and ensure a complete power loss rather than trusting a normal reboot alone. There is no mitigation SLA for MEDIUM, but this should happen immediately at the point of return-to-service because the control is event-driven, not calendar-driven.

Run this on the target device itself if it exposes a POSIX shell, or through ADB shell for Android-based assets. Example: adb push cve-2026-25262-check.sh /data/local/tmp/ && adb shell sh /data/local/tmp/cve-2026-25262-check.sh; no root is required for the common checks, but elevated privileges may improve access to device-tree paths.

#!/bin/sh
# CVE-2026-25262 chipset exposure check
# Purpose: identify whether the current device appears to use one of the
# publicly named affected Qualcomm chipset families.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN

set -u

TMP=""
cleanup() {
  [ -n "$TMP" ] && [ -f "$TMP" ] && rm -f "$TMP"
}
trap cleanup EXIT INT TERM

TMP="/tmp/cve-2026-25262.$$"
: > "$TMP" 2>/dev/null || TMP="./cve-2026-25262.$$"
: > "$TMP" || {
  echo "UNKNOWN: cannot create temp file"
  exit 2
}

append_file() {
  f="$1"
  if [ -r "$f" ]; then
    # Device-tree files may contain NUL bytes.
    tr '\000' ' ' < "$f" >> "$TMP" 2>/dev/null
    printf '\n' >> "$TMP"
  fi
}

append_cmd() {
  # shellcheck disable=SC2068
  if command -v "$1" >/dev/null 2>&1; then
    "$@" >> "$TMP" 2>/dev/null || true
    printf '\n' >> "$TMP"
  fi
}

# Common Linux / Android identification sources
append_file /proc/device-tree/model
append_file /proc/device-tree/compatible
append_file /sys/firmware/devicetree/base/model
append_file /sys/firmware/devicetree/base/compatible
append_file /sys/devices/soc0/family
append_file /sys/devices/soc0/machine
append_file /sys/devices/soc0/soc_id
append_file /sys/devices/soc0/revision
append_cmd uname -a
append_cmd cat /proc/cpuinfo
append_cmd getprop ro.board.platform
append_cmd getprop ro.boot.hardware
append_cmd getprop ro.boot.hardware.sku
append_cmd getprop ro.boot.qcomsoc_id
append_cmd getprop ro.hardware
append_cmd getprop ro.product.board
append_cmd getprop ro.product.device
append_cmd getprop ro.soc.manufacturer
append_cmd getprop ro.soc.model
append_cmd lspci -nn
append_cmd lsusb
append_cmd dmesg

DATA=$(tr '[:upper:]' '[:lower:]' < "$TMP")

if [ -z "$DATA" ]; then
  echo "UNKNOWN: no platform-identification data collected"
  exit 2
fi

# Exact/publicly named affected families from Kaspersky ICS CERT.
# Include common derivative naming seen in products where helpful.
PATTERNS="
mdm9x07
mdm9207
mdm9607
mdm9x45
mdm9645
mdm9x65
mdm9655
msm8909
msm8916
msm8952
sdx50
snapdragon x50
"

for p in $PATTERNS; do
  echo "$DATA" | grep -Eq "(^|[^a-z0-9])${p}([^a-z0-9]|$)" && {
    echo "VULNERABLE: matched affected Qualcomm chipset identifier '${p}'"
    exit 1
  }
done

# If it is clearly Qualcomm but not one of the named affected families,
# keep the result conservative because public sources note other Qualcomm-based
# chips may also be affected.
echo "$DATA" | grep -Eq 'qualcomm|qcom|snapdragon|msm|mdm|sdx' && {
  echo "UNKNOWN: Qualcomm platform detected, but no exact match to the publicly confirmed affected families"
  exit 2
}

echo "PATCHED: no evidence this host uses one of the publicly confirmed affected Qualcomm chipset families"
exit 0

Sources

1. Kaspersky ICS CERT advisory KLCERT-25-012
2. Kaspersky ICS CERT vulnerabilities index
3. Kaspersky press release
4. Kaspersky technical blog
5. Qualcomm May 2026 security bulletin landing page
6. Black Hat Asia 2026 presentation
7. Public Qualcomm EDL/Sahara tooling
8. CISA Known Exploited Vulnerabilities Catalog