Security Advisory: Secure Boot Bypass on NVIDIA Jetson for Linux

NVIDIA Jetson is a popular edge AI and embedded computing platform used to power robotics, drones, autonomous systems, industrial machines, smart cameras, and other connected devices. Built around NVIDIA’s GPU-accelerated hardware and software ecosystem, Jetson enables these systems to run AI and computer vision workloads locally, making it widely used in security-sensitive edge and industrial environments.

Initrd Command Injection Enables Secure Boot Bypass

NVIDIA Jetson Linux has a vulnerability in initrd, where an unprivileged attacker with physical access could inject arbitrary commands to be executed during the boot process, therefore bypassing Secure Boot.

Impact

A successful exploit of this vulnerability leads to secure boot bypass, code execution, escalation of privileges, denial of service, data tampering, and information disclosure.

Specifically, this allows an local attacker to be dropped into a root shell before the Trusted Application (TA) nvluks-srv-app gets closed, leading to disclosure of the root filesystem LUKS encryption key.

Description

NVIDIA Jetson for Linux implements a mechanism that allows the root filesystem to be "self-encrypting" on first run. The idea is that the NVIDIA SDK will partition your SSD with a boot partition and a root partition. On first boot, the root partition is stored in plaintext and a configuration file stored on the boot partition tells the initialization script that this root partition must be encrypted with LUKS. When that happens, the script requests a LUKS passphrase from the luks-srv Trusted Application and configures it for the root partition.

The root partition is now encrypted with LUKS and during all subsequent boots, the initialization script requests the LUKS passphrase from the luks-srv Trusted Application by using nvluks-srv-app. So the root partition is strongly encrypted using a key the flasher does not even know.

Of course, more complex partitioning schemes can be used with the exact same mechanism, the LUKS passphrase is unique per partition (derived from the LUKS key using the partition UUID as context and "luks-srv-passphrase-unique" as label, but I digress).

Vulnerability Identification

This initialization script (/init) is stored in the gzip compressed ramfs named initrd that sits in the /boot partition. It's a rather simple shell script that's vulnerable to command injection through this configuration file that is used for the "self-encryption" feature.

This script implements many things, but what interests us is the following:

1. it checks which root device was provided through boot options command line
2. it attempts to mount the root device
3. once mounted, it checks if a file named opt/nvidia/cryptluks is present on the filesystem
4. if that file is present, it parses it with awk to populate 4 variables (ext_dev, enc_dm_name, crypt_disk_uuid, and disk_format). This maps into the file format documented in their official documentation . A legit value is "/dev/nvme0n1p16 crypt_root UUID=9d3c923a-a35f-4d6d-aa9d-c82ac1461d32 ext4".
5. Once parsed the value enc_dm_name is used unsanitized in an eval call on line 581. The value enc_dev must be an existing partition so we don't have control over that. The value disk_format is only checked in conditionals. We think crypt_disk_uuid can be abused in line 567 but we did not try by fear of encrypting a partition we needed :)

Exploitation

The attack works like this:

1. mount the /dev/nvme0n1p1 partition (plaintext) and place a opt/nvidia/cryptluks file on it with the following content: /dev/nvme0n1p16 x;exec${IFS}/bin/bash${IFS}-i</dev/ttyTCU0>&/dev/ttyTCU0;: UUID=9d3c923a-a35f-4d6d-aa9d-c82ac1461d32 ext4
2. during boot, go to Device Manager -> NVIDIA Configuration -> L4T Configuration and configure this in "Append to Kernel Command Line": root=/dev/nvme0n1p1 console=ttyTCU0
3. save settings, reset, and check that you get a root shell

‍

‍

We confirmed that this can be abused on a live running device with already encrypted rootfs. Secure boot has no impact on this exploitability since we exploit trusted code from NVIDIA

Recommendations

NVIDIA released fixes for every major branch except 38.x (so far):

• NVIDIA Jetson For Linux version 39.2.1
• NVIDIA Jetson For Linux version 36.5.2
• NVIDIA Jetson for Linux version 35.6.5

We will update this section once we know the exact versions patching the 38.x branch, supposedly 38.4.1 and 38.2.2 if they simply increment. Note that the 38.x branch targets only the Jetson T5000 and T4000.

If you can't immediately patch, you should disable access to the Device Manager. This can be achieved by setting the "Auto Boot Time-out" to 0 in the Boot Maintenance Manager, and configuring password protection in Device Manager -> User Password Management. Without access to Device Manager, an attacker cannot configure the kernel command line option required for the exploit to work.

If you're facing advanced attackers (like us), you must fuse the OemK1 key and ideally burn the SecurityMode fuse. Since the L4T configuration settings being abused are saved within the EKB in EKS partition sitting on QSPI flash, and that the EKB encryption key is derived from OemK1, an attacker could replace the content of the EKB if you rely on the default OemK1.

A Look at the Patch

NVIDIA patched the vulnerability by getting rid of all eval calls and adding field validation using regular expressions:

Takeaways

Secure Boot provides strong guarantees and NVIDIA's design for disk encryption and Trusted Application is sound. However, Secure Boot can only be as secure as all the elements in the chain including system initialization scripts. By abusing command injection in NVIDIA’s trusted initrd code, we were able to gain a root shell early in the boot process, bypass the intended security guarantees, and recover the LUKS key protecting the root filesystem.

Organizations using Jetson in robotics, drones, industrial systems, autonomous machines, or other edge deployments should treat physical access as a meaningful attack vector. The primary mitigation is to update to NVIDIA’s fixed release as soon as possible. Where immediate patching is not possible, restricting access to Device Manager and hardening platform keys can significantly reduce exploitability.

If you or your organization want to make sure their devices are protected against such threats, please reach out to us.

References

This was inspired by CVE-2026-24154 and CVE-2026-24153. Note that it's definitely a bypass of CVE-2026-24153 on 36.4.3 since we can talk to the LUKS TA :)

Timeline

• May 13th 2026 - We identify the vulnerability during an audit and exploit it to decrypt the root filesystem.
• May 20th 2026 - We report the vulnerability to NVIDIA PSIRT
• May 22nd 2026 - NVIDIA opens a ticket (tracking number 6207968) and ask about disclosure plans. We indicate we follow 90 days disclosure.
• June 17th 2026 - ONEKEY requests an update on progress
• June 17th 2026 - NVIDIA confirms they could reproduce the issue and are working on a patch
• August 9th 2026 - ONEKEY requests an update, ask if a CVE identifier has been reserved.
• August 13th 2026 - NVIDIA answers that "we have fixed the issue and are about to issue an advisory to our partners. Once we have given them time to fix the issue we will go live. We will likely not make the disclosure date. Would it be possible to get an extension here"
• August 14th 2026 - ONEKEY extends the deadline to September 1st, following disclosure guidelines ("Before the 90-day deadline has expired, if a vendor lets us know that a patch is scheduled for release on a specific day that will fall within 14 days following the deadline, we will delay the public disclosure until the availability of the patch."). ONEKEY requests access to the NVIDIA advisory.
• August 14th 2026 - NVIDIA refuses to share the private advisory.
• August 17th 2026 - ONEKEY indicates that publication is set to September 1st 2026 and that knowing the CVE ID by then would be ideal.
• September 3rd 2026 - ONEKEY publishes its advisory following 90 + 14 days disclosure window