Search
Search Results (6 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-14857 | 1 Semtech | 3 Lr1110, Lr1120, Lr1121 | 2026-04-07 | N/A |
| An improper access control vulnerability exists in Semtech LoRa LR11xxx transceivers running early versions of firmware where the memory write command accessible via the physical SPI interface fails to enforce write protection on the program call stack. An attacker with physical access to the SPI interface can overwrite stack memory to hijack program control flow and achieve limited arbitrary code execution. However, the impact is limited to the active attack session: the device's secure boot mechanism prevents persistent firmware modification, the crypto engine isolates cryptographic keys from direct firmware access, and all modifications are lost upon device reboot or loss of physical access. | ||||
| CVE-2025-14858 | 1 Semtech | 3 Lr1110, Lr1120, Lr1121 | 2026-04-07 | N/A |
| The Semtech LR11xx LoRa transceivers running early versions of firmware contains an information disclosure vulnerability in its 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 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. The attack requires physical access to the device's SPI interface. | ||||
| CVE-2025-14859 | 1 Semtech | 3 Lr1110, Lr1120, Lr1121 | 2026-04-07 | N/A |
| 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. | ||||
| CVE-2022-39274 | 1 Semtech | 1 Loramac-node | 2025-04-22 | 7.5 High |
| LoRaMac-node is a reference implementation and documentation of a LoRa network node. Versions of LoRaMac-node prior to 4.7.0 are vulnerable to a buffer overflow. Improper size validation of the incoming radio frames can lead to an 65280-byte out-of-bounds write. The function `ProcessRadioRxDone` implicitly expects incoming radio frames to have at least a payload of one byte or more. An empty payload leads to a 1-byte out-of-bounds read of user controlled content when the payload buffer is reused. This allows an attacker to craft a FRAME_TYPE_PROPRIETARY frame with size -1 which results in an 65280-byte out-of-bounds memcopy likely with partially controlled attacker data. Corrupting a large part if the data section is likely to cause a DoS. If the large out-of-bounds write does not immediately crash the attacker may gain control over the execution due to now controlling large parts of the data section. Users are advised to upgrade either by updating their package or by manually applying the patch commit `e851b079`. | ||||
| CVE-2020-4060 | 1 Semtech | 1 Lora Basics Station | 2024-11-21 | 4.1 Medium |
| In LoRa Basics Station before 2.0.4, there is a Use After Free vulnerability that leads to memory corruption. This bug is triggered on 32-bit machines when the CUPS server responds with a message (https://doc.sm.tc/station/cupsproto.html#http-post-response) where the signature length is larger than 2 GByte (never happens in practice), or the response is crafted specifically to trigger this issue (i.e. the length signature field indicates a value larger than (2**31)-1 although the signature actually does not contain that much data). In such a scenario, on 32 bit machines, Basic Station would execute a code path, where a piece of memory is accessed after it has been freed, causing the process to crash and restarted again. The CUPS transaction is typically mutually authenticated over TLS. Therefore, in order to trigger this vulnerability, the attacker would have to gain access to the CUPS server first. If the user chose to operate without authentication over TLS but yet is concerned about this vulnerability, one possible workaround is to enable TLS authentication. This has been fixed in 2.0.4. | ||||
| CVE-2020-11068 | 1 Semtech | 1 Loramac-node | 2024-11-21 | 5 Medium |
| In LoRaMac-node before 4.4.4, a reception buffer overflow can happen due to the received buffer size not being checked. This has been fixed in 4.4.4. | ||||
Page 1 of 1.