CVE-2025-14858

Executive Summary

CVE-2025-14858 is a critical information disclosure vulnerability affecting Semtech LR11xx LoRa transceivers running early firmware versions. The flaw resides in the firmware validation functionality: when a host issues a firmware validity check command via the SPI interface, the device decrypts the provided encrypted firmware package block-by-block to validate its integrity. However, the last decrypted firmware block remains uncleared in memory after the validation process completes. An attacker with physical access to the SPI interface can subsequently issue memory read commands to retrieve the decrypted firmware contents from this residual memory, effectively bypassing the firmware encryption protection mechanism.

This vulnerability is particularly severe because it undermines the core security guarantee of encrypted firmware updates. The attack requires physical access to the device's SPI interface, making it a high-risk scenario for deployed IoT devices where physical security is weak. The CVSS score is currently 0.0 due to incomplete scoring, but the actual risk is high given the potential for firmware reverse engineering and persistent compromise.

Supply Chain & Package Security

This vulnerability is not related to NPM, PyPI, Go, or Ruby packages. It is a hardware/firmware-level issue in Semtech LR11xx LoRa transceivers. The supply chain risk is significant for IoT device manufacturers who integrate these transceivers without additional physical security measures.

CVSS Breakdown & Threat Level

The CVSS score is currently 0.0 (UNKNOWN) because the NVD has not yet assigned a vector. Based on the vulnerability characteristics, a reasonable estimated vector would be:

• Attack Vector (AV): Physical (AV:P) - Requires physical access to SPI interface.
• Attack Complexity (AC): Low (AC:L) - Simple SPI commands.
• Privileges Required (PR): None (PR:N) - No authentication needed.
• User Interaction (UI): None (UI:N) - No user action required.
• Scope (S): Changed (S:C) - Affects firmware confidentiality beyond the validation function.
• Confidentiality (C): High (C:H) - Full firmware decryption.
• Integrity (I): None (I:N) - No modification.
• Availability (A): None (A:N) - No denial of service.

Estimated CVSS:3.1 Vector: AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
Estimated Base Score: 5.9 (Medium)

Threat Level: High for physical attack scenarios. The EPSS score is 0.0% due to no known exploitation in the wild, but the vulnerability is technically exploitable.

Deep Dive & Mechanics

The Semtech LR11xx LoRa transceivers implement a firmware validation mechanism to ensure only authorized firmware is loaded. The process works as follows:

1. Host sends firmware validity check command via SPI interface.
2. Device decrypts the encrypted firmware package block-by-block using an embedded key.
3. Device validates integrity (e.g., checksum or signature) of the decrypted blocks.
4. Validation result is returned to the host.

The Vulnerability: After the validation completes, the last decrypted firmware block remains in a memory buffer that is not cleared. The device's memory read commands (used for debugging or diagnostics) can access this residual data. An attacker with SPI access can:

1. Send a firmware validity check command with a known encrypted block.
2. After validation, immediately issue memory read commands to retrieve the decrypted block.
3. Repeat for all blocks to reconstruct the entire decrypted firmware.

Root Cause: Lack of memory sanitization after the validation function completes. The buffer used for decryption is not zeroed out.

Attack Scenario:

• Physical access to the device's SPI pins (e.g., via test points, exposed header, or JTAG/SWD).
• Attacker connects a logic analyzer or microcontroller to the SPI bus.
• Attacker sends crafted SPI commands to trigger validation and then read memory.

Vulnerable vs. Patched Code

Since no patch is available, we can only describe the vulnerable behavior and the expected fix.

Vulnerable Code (Conceptual):

// Firmware validation function
void validate_firmware(uint8_t *encrypted_block, uint32_t length) {
    uint8_t decrypted_block[MAX_BLOCK_SIZE];
    decrypt(encrypted_block, decrypted_block, length);
    if (verify_integrity(decrypted_block)) {
        // Validation passed
    }
    // BUG: decrypted_block not cleared
    // Memory read commands can still access decrypted_block
}

Patched Code (Expected):

void validate_firmware(uint8_t *encrypted_block, uint32_t length) {
    uint8_t decrypted_block[MAX_BLOCK_SIZE];
    decrypt(encrypted_block, decrypted_block, length);
    if (verify_integrity(decrypted_block)) {
        // Validation passed
    }
    // FIX: Clear the buffer after use
    memset(decrypted_block, 0, sizeof(decrypted_block));
    // Also clear any hardware registers that may hold the data
}

Key Differences:

• Vulnerable: No memory clearing after validation.
• Patched: memset to zero the decrypted block and any related hardware buffers.

Exploitation & Lab Setup

Red Team (Attacker)

Prerequisites:

• Physical access to the target device's SPI interface.
• A microcontroller (e.g., Arduino, Raspberry Pi Pico) or logic analyzer capable of SPI communication.
• Knowledge of the LR11xx SPI command set (from datasheet or reverse engineering).

Exploitation Steps:

1. Identify SPI pins: Locate SCK, MOSI, MISO, CS on the device (often test points or header).

2. Connect attacker device: Wire the microcontroller to the SPI bus.

3. Send firmware validity check command:

   # Example using spidev on Linux
   import spidev
   spi = spidev.SpiDev()
   spi.open(0, 0)
   spi.max_speed_hz = 1000000
   
   # Command to trigger firmware validation (hypothetical)
   # Replace with actual command from LR11xx datasheet
   VALIDATE_CMD = 0xAB
   ENCRYPTED_BLOCK = b'\x00' * 256  # Example block
   
   spi.xfer2([VALIDATE_CMD] + list(ENCRYPTED_BLOCK))
   

4. Read residual memory:

   # Memory read command (hypothetical)
   MEM_READ_CMD = 0xCD
   ADDRESS = 0x2000  # Address where decrypted block might be stored
   LENGTH = 256
   
   response = spi.xfer2([MEM_READ_CMD, ADDRESS >> 8, ADDRESS & 0xFF, LENGTH])
   decrypted_block = bytes(response)
   

5. Repeat for all blocks to reconstruct the full firmware.

Expected Output: The attacker obtains the decrypted firmware, which can be analyzed for vulnerabilities, backdoors, or intellectual property.

Blue Team (Defender)

Detection:

• Monitor SPI bus for unusual sequences of commands (e.g., validation followed by memory reads).
• Use a hardware security module (HSM) to encrypt firmware at a higher level.
• Implement physical tamper detection (e.g., switches, mesh) that triggers firmware wipe.

Mitigation:

• Apply firmware patch when available (clear memory after validation).
• Disable memory read commands in production firmware.
• Use epoxy or conformal coating to protect SPI test points.
• Implement SPI bus encryption or authentication.

Lab Setup for Testing:

• Use a Semtech LR11xx evaluation board.
• Connect a logic analyzer to SPI lines.
• Write a script to send validation commands and observe memory reads.
• Verify that decrypted data is accessible.

Indicators of Compromise (IOCs)

Network IOCs:

• None (attack is physical, no network traffic).

Host/Device IOCs:

• Unusual SPI command sequences: validation command followed by memory read commands.
• Physical tampering evidence: exposed SPI pins, solder flux, probe marks.
• Firmware hash mismatch if attacker modifies firmware after decryption.

File IOCs:

• Captured decrypted firmware binary (if attacker exfiltrates it).

Behavioral IOCs:

• Device unexpectedly enters debug mode or responds to memory read commands.
• Repeated validation attempts without a legitimate firmware update.

Detection Engineering

YARA Rule

rule CVE_2025_14858_Firmware_Leak {
    meta:
        description = "Detects decrypted firmware blocks in memory dumps from LR11xx devices"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-14858"
    strings:
        $firmware_header = { 4C 52 31 31 78 78 } // "LR11xx" magic bytes
        $decrypt_pattern = { ?? ?? ?? ?? ?? ?? ?? ?? } // Placeholder for known plaintext
    condition:
        $firmware_header and #decrypt_pattern > 10
}

Sigma Rule

title: CVE-2025-14858 - SPI Memory Read After Firmware Validation
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects SPI command sequences indicating exploitation of CVE-2025-14858
author: Valters IT
date: 2025-04-10
logsource:
    category: hardware
    product: spi
detection:
    selection:
        - command: 0xAB  # Validation command
        - command: 0xCD  # Memory read command
    condition: selection | count by device_id > 1
falsepositives:
    - Legitimate firmware updates
level: high

Suricata Rule

alert tcp any any -> any any (msg:"CVE-2025-14858 - SPI Memory Read After Firmware Validation"; content:"|AB|"; offset:0; depth:1; content:"|CD|"; within:100; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Physical Security: Encapsulate SPI test points with epoxy or disable them in production.
2. Firmware Update: Contact Semtech for a patched firmware version that clears memory after validation.
3. Disable Memory Read: If possible, disable memory read commands in the device configuration.

Long-term Fixes:

• Implement hardware-level memory clearing after cryptographic operations.
• Use a secure boot process that does not expose decrypted data.
• Add SPI bus authentication (e.g., challenge-response) to prevent unauthorized commands.

Workarounds:

• Use a hardware security module (HSM) to encrypt firmware at a higher layer.
• Implement physical tamper detection that erases sensitive data.

Vendor Communication:

• Monitor Semtech's security advisories for official patches.
• If no patch is available, consider replacing the transceiver with a more secure alternative.

Valters IT

{/* [Security Hash: B91B0864074F345309302518] */}