LR1110: Use of a Broken or Risky Cryptographic Algorithm
CVE-2025-14859 is a high-severity use of a broken or risky cryptographic algorithm vulnerability in LR1110 from Semtech, with a CVSS 4.0 base score of 7.0 out of 10. It can be exploited with physical access to the device by an unauthenticated attacker, without any action from a user. The record lists version BL2 FW 0x1001 as the first without the flaw, so updating LR1110 to that release or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.11% chance of exploitation within 30 days, which is low compared with other CVEs.
High severity with no evidence of exploitation so far.
What to do
- Update LR1110 to BL2 FW 0x1001 or a later version.
- Update LR1120 to BL2 FW 0x2001 or a later version.
- Update LR1121 to BL2 FW 0x2101 or a later version.
- Read the advisory on semtech.com for workarounds and exact fixed builds.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Semtech | LR1110 | before BL2 FW 0x1001 | BL2 FW 0x1001 |
| Semtech | LR1120 | before BL2 FW 0x2001 | BL2 FW 0x2001 |
| Semtech | LR1121 | before BL2 FW 0x2101 | BL2 FW 0x2101 |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- PhysicalThe attacker must physically touch the device.
- Attack complexity
- LowNo special conditions are needed; the attack works reliably.
- Attack requirements
- NoneThe attack does not depend on a particular deployment or configuration.
- Privileges required
- NoneNo account or login is needed.
- User interaction
- NoneNo action by a victim is required.
- Confidentiality (vulnerable system)
- HighSerious loss of confidentiality on the vulnerable system.
- Integrity (vulnerable system)
- HighSerious loss of integrity on the vulnerable system.
- Availability (vulnerable system)
- HighSerious loss of availability on the vulnerable system.
- Confidentiality (other systems)
- LowLimited loss of confidentiality on systems beyond the vulnerable one.
- Integrity (other systems)
- LowLimited loss of integrity on systems beyond the vulnerable one.
- Availability (other systems)
- NoneNo loss of availability on systems beyond the vulnerable one.
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. Scored by CNA (sierrawireless.com).
Official description
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.
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Use of a Broken or Risky Cryptographic Algorithm
The product uses a broken or risky cryptographic algorithm or protocol.
How developers prevent this class of flaw
- Ensure that the design allows one cryptographic algorithm to be replaced with another in the next generation or version. Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. With hardware, design the product at the Intellectual Property (IP) level so that one cryptographic algorithm can be replaced with another in the next generation of the hardware product.
- Carefully manage and protect cryptographic keys (see CWE-320). If the keys can be guessed or stolen, then the strength of the cryptography itself is irrelevant.
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Industry-standard implementations will save development time and may be more likely to avoid errors that can occur during implementation of cryptographic algorithms. Consider the ESAPI Encryption feature.
More Use of a Broken or Risky Cryptographic Algorithm vulnerabilities (CWE-327)
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: total).
- Record last changed materially (score, affected products, status or references).
References
Recent Use of a Broken or Risky Cryptographic Algorithm vulnerabilities
- 9.1 Critical severity
- 7.5 High severity
- 9.8 Critical severity
- 9.1 Critical severity
- 9.8 Critical severity
- 7.5 High severity
Spotted an error? Tell us.