CVE-2026-18796: nRF5340 QSPI Flash Encryption Vulnerability

CVE-2026-18796 Overview

CVE-2026-18796 affects applications running on the Nordic Semiconductor nRF5340 System-on-Chip that use external Quad Serial Peripheral Interface (QSPI) flash for encrypted execute-in-place (XIP). The weakness resides in the on-the-fly decryption scheme itself, not in any specific nRF Connect Software Development Kit (SDK) release. Applications relying on that encryption for confidentiality or integrity of externally stored code are exposed. The issue is categorized under [CWE-1342] (Information Exposure through Microarchitectural State after Transient Execution and related cryptographic design weaknesses in on-chip data protection).

Critical Impact
An attacker with physical access to the device and its external QSPI flash can undermine the confidentiality and integrity guarantees expected from encrypted XIP, exposing proprietary firmware and enabling tampering with executable code.

Affected Products

Nordic Semiconductor nRF5340 SoC configurations using external QSPI flash for encrypted XIP
Applications built on the nRF Connect SDK that depend on QSPI on-the-fly decryption for code confidentiality
Firmware images stored on external QSPI flash and executed in place on the nRF5340

Discovery Timeline

2026-09-07 - CVE-2026-18796 published to the National Vulnerability Database
2026-09-09 - Last updated in NVD database

Technical Details for CVE-2026-18796

Vulnerability Analysis

The nRF5340 supports execute-in-place from an external QSPI flash device with on-the-fly decryption performed by on-chip hardware. Developers rely on this feature to keep firmware confidential and tamper-resistant when it must reside off-chip. The vulnerability lies in the design of the decryption scheme applied to the external flash contents. Because the weakness is architectural, no single nRF Connect SDK version can be identified as the root cause, and updating the SDK alone does not resolve the exposure. Exploitation requires physical access to the target and the ability to interact with the external QSPI flash bus, which raises attack complexity but does not eliminate the risk for devices deployed in the field or shipped to untrusted environments. Successful exploitation impacts confidentiality and integrity of the externally stored code, and can also affect downstream components that trust that code.

Root Cause

The root cause is a design weakness in the on-the-fly decryption scheme used for encrypted XIP from external QSPI flash. The scheme does not provide the cryptographic properties required to guarantee confidentiality and integrity of arbitrary code stored off-chip. See the Nordic Semiconductor SA Documentation for the security architecture context.

Attack Vector

The attack vector is physical. An adversary must have direct access to the device, its external QSPI flash, or the interconnect between them. With that access, the adversary can read ciphertext, manipulate stored blocks, or observe the decrypted stream to defeat the confidentiality and integrity assumptions of encrypted XIP. Because the weakness is in the scheme rather than an implementation bug, no exploit code is required on the target itself.

No public proof-of-concept exploit is available at this time, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog.

Detection Methods for CVE-2026-18796

Indicators of Compromise

Unexpected modifications to firmware images stored on external QSPI flash, detected via out-of-band hash comparison against known-good images.
Evidence of physical tampering with the device enclosure, QSPI flash package, or PCB traces between the SoC and flash.
Devices returning from field service or unauthorized custody with mismatched firmware signatures or altered boot behavior.

Detection Strategies

Perform attested measurement of external flash contents at boot using on-chip secure storage as the anchor of trust.
Compare device-reported firmware hashes against vendor-signed manifests during fleet inventory checks.
Track anomalies in device behavior that could indicate substituted or modified XIP code, such as unexpected network destinations or protocol deviations.

Monitoring Recommendations

Instrument production devices to report boot-time integrity measurements to a central telemetry system.
Maintain a hardware bill of materials and cryptographic manifest for every firmware image deployed to nRF5340 targets.
Review supply-chain and field-service logs for opportunities where physical access to affected devices may have occurred.

How to Mitigate CVE-2026-18796

Immediate Actions Required

Inventory all nRF5340 deployments that use external QSPI flash for encrypted XIP and identify which rely on that encryption for confidentiality or integrity.
Treat externally stored code as untrusted and add independent authentication of firmware images loaded from QSPI flash, such as signature verification before execution.
Restrict and monitor physical access to devices, including during manufacturing, shipping, deployment, and service.

Patch Information

No specific nRF Connect SDK version is identified as the root cause, and no patch resolves the underlying scheme weakness. Refer to the Nordic Semiconductor SA Documentation for current guidance on secure storage and firmware protection primitives available on the nRF5340.

Workarounds

Where feasible, store sensitive code in internal flash on the nRF5340 rather than external QSPI flash.
Layer an authenticated encryption scheme, implemented in application code, over any data stored on external QSPI flash rather than relying solely on the on-the-fly decryption hardware.
Add anti-tamper measures at the hardware level, including enclosure tamper detection and secure-boot enforcement that verifies image signatures before granting execution.
Rotate keys and re-provision devices identified as physically compromised, and retire units that cannot be re-secured.

bash

# Configuration example
# Enforce signed image verification before executing code from external QSPI flash.
# Consult Nordic Semiconductor documentation for the specific Kconfig symbols
# applicable to your nRF Connect SDK version and secure-boot configuration.