EUVD-2025-209287
CVSS Vector
CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:N/R:I/V:C/RE:M/U:X
Lifecycle Timeline
3Description
The Semtech LR11xx LoRa transceivers implement secure boot functionality using digital signatures to authenticate firmware. However, the implementation uses a non-standard cryptographic hashing algorithm that is vulnerable to second preimage attacks. An attacker with physical access to the device can exploit this weakness to generate a malicious firmware image with a hash collision, bypassing the secure boot verification mechanism and installing arbitrary unauthorized firmware on the device.
Analysis
Cryptographic bypass in Semtech LR11xx LoRa transceiver secure boot allows physically proximate attackers to install arbitrary firmware via hash collision. The implementation uses a non-standard, collision-vulnerable hashing algorithm (CWE-327), enabling second preimage attacks that forge signed firmware images. Affects LR1110, LR1120, and LR1121 transceivers widely deployed in IoT/LoRaWAN devices. CVSS 7.0 requires physical access (AV:P), low complexity, no privileges. No public exploit identified at time of analysis; EPSS data unavailable for this recent CVE.
Technical Context
The LR11xx family (LR1110, LR1120, LR1121) are LoRa transceivers used in IoT sensor nodes, asset trackers, and smart meters requiring long-range wireless connectivity. Secure boot implementations typically use cryptographic signatures (RSA/ECDSA) over standardized hashes (SHA-256/SHA-3) to verify firmware integrity before execution. CWE-327 (Use of a Broken or Risky Cryptographic Algorithm) indicates Semtech implemented a proprietary or deprecated hash function susceptible to second preimage attacks - where an attacker with one valid signed firmware can computationally find a different malicious firmware producing the same hash. Unlike collision attacks (two arbitrary inputs), second preimage attacks directly forge valid signatures for existing legitimate firmware hashes. This fundamentally defeats the secure boot chain-of-trust, as the digital signature verification passes for attacker-controlled code.
Affected Products
Semtech LR1110, LR1120, and LR1121 LoRa transceiver modules are confirmed vulnerable per CPE identifiers cpe:2.3:a:semtech:lr1110, cpe:2.3:a:semtech:lr1120, and cpe:2.3:a:semtech:lr1121, affecting all firmware versions using the flawed secure boot implementation. These transceivers are integrated into third-party IoT devices from manufacturers like RAKwireless, Seeed Studio, and others producing LoRaWAN gateways, trackers, and sensors. Downstream device vendors may issue separate advisories. Semtech's official security bulletin is available at https://www.semtech.com/company/security/security-bulletins/sem-psa-2026-001.
Remediation
Consult Semtech security bulletin SEM-PSA-2026-001 at https://www.semtech.com/company/security/security-bulletins/sem-psa-2026-001 for firmware updates implementing standards-compliant cryptographic hashing (likely SHA-256 or SHA-3). Patch availability and specific fixed firmware versions must be confirmed from the vendor advisory, as silicon-level secure boot fixes may require hardware revision or microcode updates that cannot be field-deployed. If firmware patches are unavailable, implement compensating controls including physical tamper-evident enclosures, restricted device access in secure locations, and runtime integrity monitoring where feasible. For new deployments, evaluate alternative LoRa transceivers with verified secure boot implementations or require vendor attestation of cryptographic algorithm compliance with NIST FIPS 180-4 or equivalent standards. Supply chain security reviews should verify firmware authenticity through independent cryptographic validation before device commissioning.
Priority Score
Share
External POC / Exploit Code
Leaving vuln.today