BadFuse Attack on Fuse-Backed Trust Mechanisms

Updated 5 July 2026

BadFuse attack is a type of exploit that subverts fuse-backed trust anchors by leveraging vulnerabilities in fuse write paths and fault injection.
It targets platforms like AMD EPYC Milan, antifuse OTP arrays, and Nvidia Tegra X2, compromising security measures such as root seed confidentiality and attestation integrity.
The attack highlights critical weaknesses across storage confidentiality, write-path integrity, and runtime fuse interpretation, calling for stronger hardware protection and error-checking measures.

Searching arXiv for the cited BadFuse-related papers to ground the article in the current literature. The BadFuse attack denotes a class of attacks that subvert security assumptions attached to fuse-backed or one-time-programmable trust anchors. In its most specific and consequential formulation, BadFuse is an end-to-end attack on AMD EPYC Milan that chains the MilanLaunchy exploit with an unprotected fuse-burn interface to extract the 256-bit VCEK root seed, after which an adversary can derive Versioned Chip Endorsement Keys for arbitrary TCB versions and forge valid SEV-SNP attestation reports (Shen et al., 13 May 2026). Related literature uses the same attack label for physically extracting secrets from antifuse OTP arrays via FIB passive voltage contrast and for voltage-glitch subversion of fuse-gated boot logic on Nvidia Tegra X2 (Zonenberg et al., 22 Jan 2025, Bittner et al., 2021). This suggests that “BadFuse” is best understood not as a single mechanism, but as a recurring attack motif centered on defeating the security role assigned to fuses, OTP state, and fuse-mediated policy decisions.

1. Terminological scope and threat model

In the EPYC Milan context, BadFuse targets the final cryptographic root underlying SEV-SNP attestation. The paper states that AMD’s anti-rollback design binds attestation reports to the platform’s TCB version through the VCEK, which is derived from a fused hardware root seed and the aggregate SVN of the ASP bootloader, SEV firmware, and CPU microcode (Shen et al., 13 May 2026). The intended security property is that a platform can attest not only to identity but also to software freshness, so that rollback to older firmware versions remains detectable.

In the antifuse OTP context, the attack label is applied to a different substrate: CMOS one-time-programmable memories based on antifuses that vendors have described as “high security” storage for serial numbers, firmware-verification keys, and encryption keys. The cited work demonstrates that these assumptions fail under focused ion beam passive voltage contrast, even for commodity devices at the 40 nm node (Zonenberg et al., 22 Jan 2025).

In the Tegra X2 context, the attack label is applied to the use of voltage fault injection against fuse-checked secure-boot control flow. There, the target is not a root seed stored in fuses but the logic that interprets fuse state, specifically the bits disabling a hidden UART download bootloader and the bit that locks writes to protected iROM remapping controls (Bittner et al., 2021).

A plausible implication is that fuse-backed trust should be analyzed at three distinct layers: storage confidentiality, write-path integrity, and runtime interpretation of fuse state. The cited works show that compromise at any one of these layers can nullify the intended security benefit of fused state.

2. Cryptographic role of the VCEK root seed on EPYC Milan

SEV-SNP augments SEV and SEV-ES with hardware-enforced integrity via the Reverse Map Table (RMP) and provides confidentiality and integrity for guest VM memory against a malicious hypervisor. Remote attestation is performed by the AMD Secure Processor (ASP), an on-chip ARM core at EL1, which signs an attestation report over the VM’s configuration, RMP state, and platform TCB version using a Versioned Chip Endorsement Key (VCEK) unique to the silicon instance and the current TCB version (Shen et al., 13 May 2026).

At power-up, the immutable Layer 0 BootROM holds a 32-byte “VCEK root seed” in fused on-chip ROM at SMN 0x5D0C4. The root seed is not exposed in the clear to higher firmware layers. The per-version seed is derived by a backward hash chain of up to 256 iterations:

$\begin{aligned} \mathrm{TmpSeed}_{255} &= \mathrm{RootSeed},\ \mathrm{TmpSeed}_{i-1} &= H\bigl(\mathrm{TmpSeed}_i\bigr)\quad(i=255,254,\dots,1),\ \mathrm{VCEK}_{\mathrm{Seed}(\mathrm{cur})} &= H\bigl(\texttt{0x00000000}\,\|\,\mathrm{TmpSeed}_{\mathrm{cur}}\bigr). \end{aligned}$

The paper states that SHA-256 is the hash function used in Milan and that the one-way nature of $H$ prevents older firmware from deriving newer seeds, while allowing a newer seed to derive all older ones. This asymmetry is the basis of rollback detection in attestation (Shen et al., 13 May 2026).

The fuse-controller layout is central to the attack. Within the ASP’s SMN mapping for secret fuses at 0x5D000–0x5E000, 0x5D044 (32 B) holds the CEK root seed, 0x5D0C4 (32 B) holds the VCEK root seed, and 0x5D0F8–0x5D0FC store control bits, ECC-enable flags, and Fletcher checksums. After BootROM reads these fuse words into SRAM, a hardware latch forces subsequent reads from 0x5D000–0x5E000 to return all zeros. However, the same region remains writable through a dedicated “fuse burner” unit at MMIO 0x5E000–0x5E020, which the paper reports is left unprotected by default (Shen et al., 13 May 2026).

3. Attack chain: MilanLaunchy as the software-only precondition

The AMD BadFuse attack is not a standalone primitive; it is explicitly chained from MilanLaunchy. The prerequisite exploit is based on CVE-2021-26315 in the Milan ASP BootROM, where RSA-PSS verification covers only the encrypted body and header, not the decrypted plaintext. The BootROM decrypts the Wrapped IKEK with AES-128-ECB, decrypts the Wrapped MEK with AES-128-ECB, decrypts the firmware body with AES-128-CBC(MEK,IV) to obtain plaintext, and then verifies {EncryptedBody‖Header} under RSA-PSS rather than the plaintext (Shen et al., 13 May 2026).

The consequence is that flipping bits in the Wrapped IKEK can force arbitrary “random” plaintext in the first AES-CBC block while preserving RSA-PSS validity, because the signed material is the XOR-related ciphertext rather than the resulting plaintext. The paper states that brute-forcing 32 bits of the first decryption key, at approximately $2^{32}$ effort, allows control of the first decrypted 32 bits in SRAM, corresponding to one 32-bit ARM instruction. A branch such as b 0x20000 can then redirect execution into attacker-controlled SRAM (Shen et al., 13 May 2026).

Once code execution at EL1 in the off-chip bootloader has been achieved, the BadFuse stage manipulates the fuse burner through MMIO. The required sequence is to poll the busy state at SMN 0x5E000, write burn-enable to 0x5E014, select the target fuse word via 0x5E004 with a bit-index encoding, toggle the “burn” bit at 0x5E004, and then poll completion again in 0x5E000. The paper states that no hardware or software guard prevents writes to the VCEK seed region (Shen et al., 13 May 2026).

The extraction method relies on a single-bit oracle. Because attempting to rewrite a fuse bit already blown to 1 is a no-op, the attacker burns one candidate bit at a time, performs a cold reboot to clear ASP latches, and requests a fresh attestation report to observe whether the derived VCEK changed. The pseudocode given in the paper initializes Vbase = fetch_current_vcek_seed(), iterates over i in 0..255, performs burn_fuse_bit(i), reboots, fetches Vcurr, and sets seed[i] = 0 if Vcurr != Vbase, else seed[i] = 1; the current VCEK value is obtained by requesting an attestation report through the SEV-SNP ABI, extracting the VCEK public key, and comparing its public value to the baseline (Shen et al., 13 May 2026).

A critical enabling condition is that although ECC and Fletcher-32 redundancy were designed into the fuse words, the paper reports that Milan ships with them disabled, so no uncorrectable-error fault is raised when arbitrary bits are toggled (Shen et al., 13 May 2026).

4. Attestation forgery and failure of rollback prevention

With the full 256-bit RootSeed recovered, the attacker can run the same hash-chain KDF locally to compute $\mathrm{VCEK\_Seed}(\mathrm{cur})$ for any $\mathrm{cur} \in [0..255]$ . The paper then states that SEV-SNP reports are ECDSA-P384 signatures over the report body using the derived VCEK private key for version cur. If $m$ denotes the report message, the attacker computes

$(r,s) = \mathrm{ECDSA\_Sign}_{\mathrm{VCEK\_Priv}(cur)}(m).$

Because the adversary controls the private key material implied by the recovered seed, the system can fabricate reports claiming any TCB version, including future, unreleased ones (Shen et al., 13 May 2026).

The security significance is direct. The paper characterizes the essence of rollback prevention as binding the report signing key to the current SVN via a one-way KDF. Recovering the root seed itself removes that binding as a security boundary: any version-specific key can be regenerated off-chip, so the anti-rollback model no longer constrains what can be attested (Shen et al., 13 May 2026).

The experimental figures in the paper are operationally important because they show that the attack is not merely theoretical. The bitwise oracle requires 256 cold reboots and 256 ABI report requests. On an EPYC 7413 on TYAN S8036GM2NE, the paper states that each iteration, including power cycle, takes under 20 s, and that full seed extraction completes in under 2 hours with 100% reliability on unmodified Milan silicon (Shen et al., 13 May 2026).

A common misconception is that protection against direct fuse reads is sufficient to protect a root seed. The Milan result shows that read blocking after BootROM access does not suffice when the adversary can still manipulate fuse state through an inadequately restricted write path and infer secret bits from resulting cryptographic behavior.

The antifuse work shows a distinct but structurally analogous BadFuse pattern: instead of exploiting a writable fuse-burn path, it exploits the physical readout properties of 40 nm CMOS gate dielectric breakdown antifuses through passive voltage contrast (PVC) under FIB imaging (Zonenberg et al., 22 Jan 2025). In the cited bitcell model, an unprogrammed cell behaves as $C_{\mathrm{core}}$ in series with $R_{\mathrm{off}} \gg 10^{12}\ \Omega$ , while a programmed cell forms a conductive filament with $R_{\mathrm{prog}} \sim 1\,\mathrm{k}\Omega–10\,\mathrm{k}\Omega$ . Under ion-beam charging, the surface potential obeys $H$ 0 at steady state, with the programmed state exhibiting larger leakage and therefore lower surface potential. The attack exploits the resulting contrast in secondary-electron yield.

The array geometry imposes an important limitation: each Metal 1 via on a bit-line contact is shared by two vertically adjacent cells, so the PVC readout yields the bitwise OR of the north/south pair. Even with this constraint, the paper reports Contrast-to-Noise Ratio (CNR): >100 gray levels in 8-bit SEM images, imaging error rate: <10^-6 per bit, throughput of one 2 kbit plane in approximately 1 hour of FIB PVC time, and a full 24-plane compromise in approximately 2–3 days (Zonenberg et al., 22 Jan 2025). This directly challenges the longstanding claim that antifuses are “significantly more difficult” to extract than Flash or mask ROM.

The Tegra X2 work shows the third pattern: fuse state remains intact, but voltage glitching causes the processor to mis-handle the result of a fuse check (Bittner et al., 2021). The relevant fuses are FailureAnalysisMode (FAM), PreProductionMode (PPM), and SECURE_BOOT. In production devices, FAM=1 and PPM=1 disable the hidden “NvBootUartDownload()” path, while SECURE_BOOT=1 locks writes to PIROM_START and ACCESS_PIROM. The attack uses an FPGA, a high-speed crowbar circuit with an Infineon IRF8736 MOSFET on VDD_SYS_SOC, and synchronization via RESET_IN to inject a glitch approximately 2.63 ms after reset with width around 11.3 µs and amplitude corresponding to a drop from 0.95 V by approximately 0.9 V (Bittner et al., 2021).

The paper gives two concrete early successes after an 8 h brute-force pass at $H$ 1 and $H$ 2, each with success rate 1/10⁵, and then reports that constraining $H$ 3 produced approximately 1 success per second on average for $H$ 4 (Bittner et al., 2021). Here the security failure lies in temporal faultability of the logic that enforces fuse-based policy.

Variant	Target	Mechanism
AMD EPYC Milan	VCEK root seed at 0x5D0C4	Software-only code execution plus writable fuse burner and VCEK-difference oracle
40 nm antifuse OTP	Antifuse memory contents	FIB passive voltage contrast readout of programmed vs. unprogrammed cells
Nvidia Tegra X2	Fuse-gated boot decisions	Voltage fault injection against early BootROM fuse checks

Taken together, these results indicate that the security role of fuses can fail through logical write abuse, physical state extraction, or fault-induced misinterpretation.

6. Mitigations, limitations, and broader significance

For EPYC Milan, the paper proposes several mitigations: hardware fuse write-protect bits for the VCEK seed region; enabling and enforcing ECC + Fletcher-32 checks on fuse reads such that mismatches or uncorrectable errors cause a permanent ASP halt; removing the “Custom_PK” override fuse function; and auditing the BootROM decryption flow so that the signature covers the plaintext, as in Zen 4+ (Shen et al., 13 May 2026). The paper also mentions an alternative migration of VCEK derivation to a DICE-style model that incorporates firmware measurements, while noting that this would sacrifice rollback flexibility.

For antifuse OTP, the reported countermeasures are array-level and circuit-level: split-bit mapping so that OR readout yields all ones, dedicated single-cell contacts to eliminate via sharing, grounded M2 shielding, thicker dielectric or multi-layer antifuse stacks, reactive on-die monitors that detect charge injection or FIB current, and cryptographic designs that store only a per-device root key rather than raw secrets in fuse memory (Zonenberg et al., 22 Jan 2025).

For Tegra-style glitching, the proposed defenses include triple-redundant fuse bits with majority voting, cross-rail voltage monitors, analog comparators with <10 ns detection windows, watchdog reset on glitch alarm, duplicated branch conditions, random delays, maximal-Hamming-distance constants, and loop-integrity checks (Bittner et al., 2021). The paper explicitly notes that software hardening forcing two independent timing alignments reduces overall success from $H$ 5 to $H$ 6.

A broader misconception addressed by these works is that fuses are intrinsically “tamper-resistant” because they are non-volatile, physically one-time programmable, or checked by immutable ROM. The literature shows a more conditional picture. A fuse may be difficult to read directly yet still be vulnerable if its write path is insufficiently constrained, if its physical state can be inferred by imaging, or if the control-flow decisions depending on it can be faulted. In this sense, the BadFuse literature shifts attention from the mere presence of fused state to the end-to-end integrity of the entire mechanism that stores, consumes, and enforces it.