Interruptable autoboot: the 3-second window that gives an attacker root

20 of the 31 real boot captures in BootIntel's public sample corpus drop into an unauthenticated U-Boot shell if you press a key during power-on. Two thirds of the corpus: consumer routers, dev boards, TI industrial gateways: hand an attacker root over three wires and a $3 UART cable. Several of the routers are still on retail shelves running a fork of U-Boot 1.1.x (DENX shipped 1.1.3 in August 2005 and 1.1.4 that October).

What the prompt actually offers

U-Boot is a bootloader. Its job during autoboot is straightforward: set up RAM, load a kernel image from flash, hand off withbootargs. Between DRAM init and kernel handoff it also opens an unauthenticated command shell on the serial console, waits a configurable number of seconds for a keystroke, and if it sees one, drops into that shell instead of continuing to boot. No password, no token, nothing.

The shell isn't a toy. It lets an attacker with physical access to the debug header do all of:

• Read the entire boot environment (printenv), including any variables the firmware stashed at build time (crypto keys, Wi-Fi provisioning tokens, backend URLs).
• Overwrite kernel command line (setenv bootargs …) to inject init=/bin/sh or single, dropping the system into a root shell before any userspace auth runs.
• Load an arbitrary kernel image from TFTP or USB and boot it (tftpboot, fatload usb, bootm).
• Dump raw flash (md.b, sf read) to reconstruct firmware for offline analysis.
• Rewrite persistent env variables so the compromise survives reboots (saveenv).

Concrete attack path (three commands)

Get-root-without-credentials sequence on a Linux device with interruptable U-Boot:

# 1. attacker connects UART, powers on the device, mashes any key.
Hit any key to stop autoboot:  1
=> printenv bootargs
bootargs=console=ttyS0,115200 root=/dev/mtdblock2 rw

# 2. append init=/bin/sh so PID 1 is a shell, not the vendor init
=> setenv bootargs ${bootargs} init=/bin/sh
=> boot
...
[    2.847523] Freeing unused kernel memory: 128K
sh: no job control in this shell
sh-4.4# id
uid=0(root) gid=0(root)

Three commands, no exploit: the device did what its config told it to. There's no CVE for it because the behavior is a documented U-Boot feature; the vendor just chose to leave it enabled.

Evidence from the sample corpus

Each of these logs is a real capture from a real device. All are served at bootintel.com/samples/<file>.txt and will render as plain text in the browser (no download prompt). Click through to any of them and paste the file into the Fingerprinter to see the detector output for yourself.

This is a representative subset. 20 of the 31 sample logs BootIntel ships have some form of interruptable-autoboot prompt, spanning consumer routers, hobbyist SBCs, and TI industrial gateways.

The countdown is not a defense

Two reasons that argument does not hold up:

First, the 3 seconds is often 0. Countdown values observed across the 20 corpus samples that show the prompt:

Second, even a 3-second countdown falls to a scripted attacker. The exact incantation is public:

# Configure the port first: a bare redirect uses the driver's default
# baud/parity, not 115200. Skipping this step is why the naive one-liner
# quietly fails.
stty -F /dev/ttyUSB0 115200 raw -echo
while true; do printf '\r'; sleep 0.05; done > /dev/ttyUSB0 &
# now cycle power on the target device

A defender who leaves this shell enabled and thinks "attackers can't press a key fast enough" has conceded the physical-access threat model without actually raising the bar.

Why a 2005-vintage U-Boot is still shipping in 2026

Six of the samples in the corpus show U-Boot 1.1.3 or 1.1.4 builds. Upstream 1.1.3 shipped in August 2005; 1.1.4 shipped that October. The build timestamps in the boot lines are 2009-2013, which means the vendor took an already-old U-Boot, added their board support, and locked in that fork. When the SoC family entered production, that same fork went out the door. Two decades later it's still on the shipping firmware.

The fork isn't patched against known U-Boot vulnerabilities in the environment parser, IP stack, or fs stack that the upstream project has since fixed. That is a separate concern from the interruptable-autoboot behavior: and one where specific CVE numbers should be verified against your build's exact patch history, not assumed. This post is deliberately not naming specific CVEs against these builds; the class of exposure is enough to justify replacing the bootloader without also fighting over which of the four known bugs applies.

What a defended device looks like in the boot log

A defended U-Boot has no positive tell. You identify it by what it doesn't print during autoboot. Three patterns to pattern-match against your own capture:

If you see any variant of Hit any key or Autobooting in N seconds in your capture, you are in the first row. If you see a vendor-customized prompt that names a specific key or word to press (rather than the upstream default "Hit any key"), you are in the second row. If the transition from bootloader to kernel happens with no prompt whatsoever, you are in the third row.

Checking your own device

You need a 3.3 V UART adapter and something to record the serial stream. See our UART adapter guide for adapter picks (the $60 Tigard is enough for most devices).

1. Wire GND to GND, adapter TX to device RX, adapter RX to device TX. Nothing to Vcc.
2. Open a serial terminal at 115200 8N1 (BootIntel has one at bootintel.com/terminal: WebSerial, no driver install).
3. Power-cycle the device. Save the boot output.
4. Paste the log into the Fingerprinter. It runs the detectors from our shared library, including autoboot_interruptable, entirely client-side: nothing is uploaded.

If the tool flags interruptable autoboot on a device you own, the fix depends on the target: replace the vendor U-Boot with a current version and rebuild with CONFIG_BOOTDELAY=-2(best), or on devices where the bootloader is locked, gate physical access to the debug header (housing, tamper-evident seals). Neither is free. Both cost less than the recall.

Related

• Device Fingerprinter, paste a boot log, get bootloader / kernel / autoboot detector output immediately. Client-side, no upload.
• Web Serial terminal: capture the boot log directly in the browser (Chromium-based only).
• UART adapters worth owning: hardware picks for the capture step.
• Scanning a fleet rather than one device? BootIntel's paid tiers ingest boot logs at scale with per-device history and CVE tracking.