Six of the 31 boot logs in BootIntel's public sample corpus show U-Boot 1.1.3 or 1.1.4. DENX cut those upstream releases in August and October of 2005. The vendor-fork build timestamps in the logs are 2009 through 2013. The routers running those forks are still on retail shelves in 2026: a 21-year-old codebase nobody has rebased.
Every capture below is from a physical device tested recently enough to submit as a sample: probably a sibling of the one on your own desk.
Evidence from the corpus
Each row links to the raw boot capture at /samples/<file>.txt. Click through and the version line is in the capture: nothing to take on faith.
| Sample | Version line as captured | Device |
|---|---|---|
| bootintel-12.txt | U-Boot 1.1.3 (Dec 4 2013 - 08:55:41) | TP-Link Archer C2 v1.0.0, Ralink APSoC Fork built 8 years after upstream 1.1.3 |
| bootintel-25.txt | U-Boot 1.1.3 (Nov 7 2013 - 17:33:35) | ASUS RT-AC51U, Ralink APSoC (bootloader version 1.0.0.0) Fork built 8 years after upstream 1.1.3 |
| bootintel-29.txt | U-Boot 1.1.3 (Nov 7 2013 - 17:33:35) | ASUS RT-AC51U (second capture of the same board) Fork built 8 years after upstream 1.1.3 |
| bootintel-26.txt | U-Boot 1.1.4 (May 3 2012 - 22:04:42) | AP121 hobbyist reference board, Atheros AR9330 Fork built 7 years after upstream 1.1.4 |
| bootintel-14.txt | U-Boot 1.1.4 (Jan 11 2012 - 20:59:53) | Atheros-based router with athrs17 (AR8327/S17) switch, in HTTP recovery mode on 192.168.1.1 Fork built 7 years after upstream 1.1.4 |
| bootintel-30.txt | U-Boot 1.1.4 (April 17, 2009 Micrel GPHY 200-16) | Micrel GPHY 200-16 network-appliance board Fork built 4 years after upstream 1.1.4 |
The DENX U-Boot release history is publicly indexed at source.denx.de/u-boot. 1.1.3 shipped 2005-08. 1.1.4 shipped 2005-10.
Why a 21-year-old bootloader is on shipping firmware
The answer is prosaic: SoC vendors ship a board-support package. The BSP is a snapshot of upstream at whatever version the reference-design engineer happened to fork from, plus a pile of proprietary drivers for their radio, switch fabric, PMIC, and boot ROM. The moment those drivers hit upstream U-Boot, the vendor owns the diff. Rebasing that diff onto a newer upstream is real engineering work, and the commercial pressure to do it is zero: the customer is buying a router, not a U-Boot version.
So the same 1.1.x fork gets forked into the reference design, copied into the OEM board port, and shipped as-is on the retail SKU. Twelve years later it's in a $25 retail-box router on the shelf. The build timestamp updates to whenever the OEM last touched the source; the underlying upstream version never moves.
The two Ralink APSoC-family samples above have build timestamps eight years newer than upstream 1.1.3. The Atheros AR9330 sample has a build seven years newer than upstream 1.1.4. Every one of these is a vendor-fork build date on top of a 2005 upstream base. Nothing in the version strings suggests anyone ever pulled from mainline.
What twenty years of unrebased fork actually costs
This post is deliberately not citing specific CVE numbers against these builds: whether a given vendor backported a specific fix into their fork is exactly the sort of claim that needs verification against the vendor's actual patch history, not against upstream's changelog. The categories of change the fork has missed are knowable without that verification, and any one of them is enough to justify replacing the bootloader:
- Environment parser hardening. The U-Boot
setenv/saveenvpath has seen multiple rewrites for CRC and bounds handling since 2005. Any of those matter if an attacker with UART access can reach the shell (see the autoboot post: same corpus, different failure mode). - Network stack fixes. TFTP, BOOTP, and DHCP parsers in pre-1.2.0 U-Boot have well-known bounds issues. Only relevant if the vendor left TFTP boot enabled in the shipping config: but on recovery-mode devices it usually is.
- Filesystem support. The FAT, ext2, and JFFS2 code has been rewritten repeatedly since 2005 for malformed-image handling. A U-Boot that can be tricked into loading a crafted image from a plugged-in USB stick is not a hypothetical.
- Config subsystem. Pre-Kconfig U-Boot used hand-maintained
include/configs/*.hper board. Any hardening flag added upstream after the 2014.10 Kconfig conversion (autoboot keying, secure-boot verify-image hooks, memory-region protection) needs a manual backport into the fork to apply. That work rarely happens.
What to do about it
Fixes, best to worst:
- Reflash the device with a supported third-party firmware where the SoC / board is covered. OpenWrt's Table of Hardware is the fastest way to check: Ralink APSoC and Atheros AR9330 devices in the table above have OpenWrt builds that ship a current U-Boot alongside a maintained Linux. The router keeps working; the boot chain moves out of 2005.
- Retire the device if third-party support doesn't exist. Harsh, but usually correct for a router whose vendor stopped shipping firmware updates before COVID.
- Treat the UART header as trusted-code access. If reflashing and retirement are both off the table, at least stop pretending the debug pad is a maintenance convenience. On a device with an unpatched U-Boot fork, "access to the UART" means "full control of what the CPU loads next." Physical enclosures with tamper evidence, at minimum.
Checking your own device
Capture a boot log per the UART adapter guide and paste it into the Fingerprinter. The detector reports the exact U-Boot version string it observes, so a 1.1.x reading is a one-line answer. Anything numerically older than the current stable release (U-Boot 2026.07 as of this writing) matters; anything 1.1.x specifically means the vendor is on a fork that predates every current LTS kernel and most of the engineers now maintaining upstream.
Related
- Interruptable autoboot: the 3-second window that gives an attacker root : the failure mode that turns an old U-Boot into a root shell on the debug pad.
- UART adapters worth owning: hardware picks for the capture step, and picocom/tio/screen commands to save the output.
- Device Fingerprinter : paste a boot log, get bootloader version + kernel + SoC identification. Client-side, no upload.
- Tracking bootloader versions across an install base and want the "is this fork still on 1.1.x?" question answered without pasting logs one at a time? That's what BootIntel's paid tiers are for.