CVE-2025-14859: Semtech LR11xx Auth Bypass Vulnerability

CVE-2025-14859 Overview

CVE-2025-14859 is a critical secure boot bypass vulnerability affecting Semtech LR11xx LoRa transceivers. The vulnerability stems from the implementation of a non-standard cryptographic hashing algorithm used in the digital signature verification process during secure boot. This flawed cryptographic implementation is susceptible to second preimage attacks, allowing an attacker with physical access to the device to craft malicious firmware that produces hash collisions with legitimate firmware images.

By exploiting this weakness, an attacker can bypass the secure boot verification mechanism entirely, enabling the installation of arbitrary unauthorized firmware on affected devices. This compromises the integrity of the device's security chain and opens the door to persistent device compromise.

Critical Impact

Physical attackers can completely bypass secure boot protections to install malicious firmware, leading to full device compromise with high confidentiality, integrity, and availability impact on the vulnerable system.

Affected Products

• Semtech LR11xx LoRa Transceivers

Discovery Timeline

• 2026-04-07 - CVE-2025-14859 published to NVD
• 2026-04-08 - Last updated in NVD database

Technical Details for CVE-2025-14859

Vulnerability Analysis

This vulnerability (CWE-327: Use of a Broken or Risky Cryptographic Algorithm) exists in the secure boot implementation of Semtech LR11xx LoRa transceivers. The secure boot functionality relies on digital signatures to authenticate firmware before execution, a critical security control designed to prevent unauthorized code from running on the device.

The root issue is that the implementation uses a non-standard cryptographic hashing algorithm that fails to provide adequate collision resistance. Standard cryptographic hash functions like SHA-256 are designed to make it computationally infeasible to find two different inputs that produce the same hash output. However, the proprietary algorithm used in these transceivers contains weaknesses that make second preimage attacks practical.

A second preimage attack allows an attacker who knows the original firmware image and its hash to construct a different (malicious) firmware image that produces the same hash value. When the secure boot process verifies the digital signature, it computes the hash of the firmware image and compares it against the signed hash. If the malicious firmware produces the same hash, the signature verification passes, and the unauthorized firmware is allowed to execute.

Root Cause

The vulnerability originates from the use of a non-standard, weak cryptographic hashing algorithm in the secure boot verification chain. Rather than implementing a well-vetted, industry-standard hash function with proven collision resistance (such as SHA-256 or SHA-3), the affected transceivers employ a proprietary algorithm that lacks sufficient cryptographic strength. This design decision has created a fundamental weakness in the firmware authentication mechanism.

Attack Vector

Exploitation requires physical access to the target device. An attacker must:

1. Obtain legitimate firmware from a device or other source
2. Analyze the weak hashing algorithm to understand its collision properties
3. Generate a malicious firmware payload that achieves a hash collision with the legitimate firmware
4. Flash the malicious firmware to the device using physical access (e.g., JTAG, SPI, or other hardware interfaces)

Once the malicious firmware is installed, the secure boot process will successfully verify the compromised image, allowing the attacker's code to execute with full privileges on the device. This can lead to persistent compromise, data exfiltration, manipulation of LoRa communications, or use of the device as a pivot point for further attacks on connected systems.

The attack mechanism exploits the collision vulnerability in the cryptographic hash function. For detailed technical information, refer to the Semtech Security Bulletin PSA-2026-001.

Detection Methods for CVE-2025-14859

Indicators of Compromise

• Unexpected firmware version or checksum mismatches when comparing against known-good firmware images
• Evidence of physical tampering on devices such as removed enclosures, signs of JTAG/SPI access, or resealed packaging
• Anomalous device behavior including unexpected LoRa transmissions, communication with unknown endpoints, or changed operational parameters
• Firmware update logs showing unauthorized flash operations or updates outside of normal maintenance windows

Detection Strategies

• Implement firmware integrity monitoring that compares running firmware against cryptographically signed manifests from Semtech
• Deploy physical security controls including tamper-evident seals and secure enclosures for critical IoT deployments
• Monitor device behavior baselines and alert on deviations in transmission patterns, power consumption, or operational characteristics
• Conduct periodic firmware audits comparing deployed firmware hashes against vendor-provided golden images

Monitoring Recommendations

• Establish centralized logging for all firmware update events across deployed LR11xx device fleets
• Implement network-level monitoring for anomalous LoRa traffic patterns that may indicate compromised device behavior
• Deploy physical access monitoring and alerts for environments housing critical IoT infrastructure
• Create automated alerts for any firmware version changes that occur outside of scheduled maintenance windows

How to Mitigate CVE-2025-14859

Immediate Actions Required

• Review the Semtech Security Bulletin PSA-2026-001 for vendor-specific guidance and available patches
• Conduct a physical security audit of all deployed LR11xx devices to identify potential tampering
• Implement enhanced physical access controls to limit unauthorized physical access to affected devices
• Prioritize firmware updates as soon as Semtech releases patches addressing the cryptographic weakness

Patch Information

Semtech has published a security bulletin addressing this vulnerability. Organizations should consult the Semtech Security Bulletin PSA-2026-001 for official patch availability, affected firmware versions, and specific update procedures. Contact Semtech support for assistance with firmware updates for production deployments.

Workarounds

• Deploy physical security measures including tamper-evident enclosures, locked cabinets, and restricted physical access to device locations
• Implement network segmentation to isolate LoRa infrastructure from critical systems, limiting the blast radius of potential compromise
• Enable additional monitoring and logging for all device management interfaces and firmware update mechanisms
• Consider device replacement with updated hardware revisions if Semtech confirms firmware-only patches are insufficient

Physical security controls represent the primary mitigation strategy until a cryptographic fix is available, as exploitation requires direct physical access to the device hardware interfaces.