CVE-2026-18796 in nRF5340
Summary
by MITRE • 09/07/2026
Any application that uses external QSPI flash for encrypted XIP on nRF5340 and relies on that encryption for confidentiality and/or integrity of the externally stored code. No specific nRF Connect SDK version is the root cause; the weakness is in the on-the-fly decryption scheme.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/07/2026
The vulnerability described pertains to a fundamental architectural flaw in the implementation of encrypted Execute-In-Place (XIP) functionality for external Quad SPI flash memory within Nordic Semiconductor's nRF5340 system-on-chip. This issue affects any application that relies on this specific hardware-assisted encryption mechanism to ensure the confidentiality and integrity of code stored externally, regardless of the software version or SDK used. The core weakness lies not in a discrete bug but in the design of the on-the-fly decryption scheme itself, which fails to provide robust security guarantees against sophisticated physical attacks when deployed without additional protective measures.
From a technical perspective, Execute-In-Place allows microcontrollers to execute code directly from external flash memory rather than copying it into internal RAM first, thereby saving valuable processing time and reducing power consumption while maintaining large program storage capabilities. To protect intellectual property and prevent reverse engineering, manufacturers often implement hardware-based encryption where the data is stored in an encrypted format on the flash chip and decrypted transparently by a dedicated peripheral before being fetched for execution. In this specific case involving the nRF5340, the decryption engine operates continuously during code fetches. The vulnerability arises because the cryptographic operations are performed at high speeds with minimal side-channel resistance or physical isolation mechanisms designed to thwart advanced fault injection or power analysis attacks targeting the memory interface and decryption logic.
The operational impact of this weakness is severe for developers who assume that enabling hardware encryption on external flash provides sufficient protection against tampering and theft of proprietary algorithms. An attacker with physical access to a device utilizing this configuration can potentially exploit timing variations, voltage glitches, or electromagnetic emissions during the high-speed decryption process to recover plaintext code or manipulate execution flow. This undermines both confidentiality, as sensitive source code may be extracted, and integrity, as an adversary might inject malicious instructions if they can predict or alter the decrypted data stream. Consequently, applications relying solely on this feature for security are at significant risk of compromise in environments where physical access is possible, such as consumer electronics deployed in uncontrolled locations or industrial IoT devices with exposed interfaces.
This vulnerability aligns closely with CWE-327, which describes the use of a broken or risky cryptographic algorithm, and more specifically reflects weaknesses associated with insufficient protection against side-channel attacks often categorized under CWE-345 Insufficient Verification of Data Authenticity when considering the integrity aspect. Furthermore, in terms of offensive security frameworks like MITRE ATT&CK, this flaw facilitates techniques related to Code Injection (T1202) or Unsecured Access to Sensitive Information (TA0006), as it lowers the barrier for an attacker to extract and modify firmware components without needing complex software exploitation chains. The lack of robust countermeasures against physical probing means that the security boundary provided by the hardware encryption is effectively porous under targeted attack scenarios.
Mitigation strategies must move beyond relying solely on the default configuration of the external flash encryption peripheral. Developers should implement additional layers of defense, such as enabling secure boot mechanisms to verify code signatures before execution, which ensures integrity even if decryption is compromised. It is also critical to utilize internal RAM for storing sensitive cryptographic keys and frequently changing runtime variables that are not stored in the vulnerable external memory space. Physical hardening measures, including epoxy potting or tamper-evident packaging, should be considered for high-security applications to deter physical access attempts entirely. Additionally, Nordic Semiconductor may provide updated silicon revisions or firmware patches that introduce randomized delays, noise injection, or other side-channel resistant techniques into the decryption engine; however, until such updates are widely adopted and verified, architects must assume this specific XIP encryption scheme is insufficient as a standalone security control for protecting against determined physical adversaries.