U-Boot bündelt Kernel, Device Tree, Ramdisk und weitere Startkomponenten in einem FIT-Paket (Flattened Image Tree) und prüft dessen digitale Signatur, bevor die Kontrolle übergeben wird. Binarly hat nach Schwachstellen in genau dieser Prüfkette gesucht und dabei sechs Fehler gefunden, die alle vor der Signaturprüfung angestoßen werden können.
Die beiden schwerwiegendsten Lücken sind BRLY-2026-037 und BRLY-2026-038. Beide gehen laut Binarly auf denselben ungeprüften Rückgabewert zurück. U-Boot ruft dafür fdt_get_name auf, eine Funktion aus der Device-Tree-Bibliothek, die es nutzt. Bei einem fehlerhaft aufgebauten Image liefert diese Funktion einen Nullzeiger und eine negative Länge zurück. U-Boot verwendet beides weiter, ohne die Werte zu prüfen.
Im einen Fall läuft der Nullzeiger in einen Speicherkopiervorgang. Auf Systemen, bei denen Adresse Null eingeblendet ist, kann daraus ein Stack-Pufferüberlauf werden. Im anderen Fall fließt die negative Länge in eine Zeigerarithmetik ein, die rückwärts durch den Speicher läuft, bis eine gesicherte Rücksprungadresse überschrieben wird. Bei passender Speicheranordnung könnte dadurch in beiden Fällen vom Angreifer bereitgestellter Code die Kontrolle übernehmen.
Die übrigen vier Schwachstellen führen nach Angaben von Binarly zu Abstürzen des Bootloaders. BRLY-2026-039 und BRLY-2026-041 lesen über das Ende des Images hinaus, weil sie eine von Angreifern kontrollierte Größe beziehungsweise einen Offset als vertrauenswürdig behandeln. BRLY-2026-040 dereferenziert einen Nullzeiger, den ein älteres Image-Format ungeprüft zurückliefert. BRLY-2026-042 erschöpft den Stack: Ein tief verschachteltes Image bringt eine frühe Validierungsroutine dazu, sich wiederholt selbst aufzurufen, bis der Speicherrahmen aufgebraucht ist.
Binarly hat für jede Schwachstelle ein Proof-of-Concept-Image und Reproduktionsschritte veröffentlicht und die Fehler an Standard-Builds von U-Boot demonstriert. Berichte über eine Ausnutzung in realen Angriffen liegen bislang nicht vor. Binarly empfiehlt, unter den sechs Funden vor allem die beiden Speicherfehler zu priorisieren: Ein Absturz kann ein Gerät außer Betrieb setzen, Codeausführung während des Starts kann jedoch die gesamte Vertrauenskette unterlaufen.
Ein Angreifer muss dafür allerdings zunächst ein manipuliertes Image in den Bootpfad bringen. Laut dem Quelltext gelingt das meist nur mit physischem Zugriff oder mit einem privilegierten Zugang. Dass ein solcher Zugang nicht zwingend lokal sein muss, hatte derselbe Binarly-Forscher in früheren Arbeiten zu den Server-Management-Controllern von Supermicro gezeigt: Dort konnte ein Angreifer mit Fernzugriff auf die Management-Schnittstelle den geräteeigenen Update-Prozess missbrauchen, um ein manipuliertes Image einzuspielen.
Eine stabile U-Boot-Version mit den Korrekturen gibt es noch nicht. U-Boot hat die sechs Patches zwar im Juni übernommen, die Juli-Version v2026.07 war laut Quelltext aber bereits im April eingefroren und erschien daher ohne die Änderungen. Die nächste Version, v2026.10, wird erst im Oktober erwartet. Binarly rät Herstellern und Betreuern von U-Boot-basierten Produkten deshalb, die Upstream-Korrekturen sofort anhand der in den Hinweisen verlinkten Commits zu übernehmen und die Fälle über die Hinweis-IDs zu verfolgen, weil noch keine CVEs vergeben wurden.
Der Quelltext verweist zudem auf einen früheren Fehler in derselben Signaturlogik: CVE-2026-33243, von U-Boot im April behoben. Auch der verwandte Bootloader barebox war betroffen, weil beide dieselben Image-Werkzeuge verwenden. Die hier relevanten Hilfsfunktionen stammen aus libfdt, der Bibliothek für Flattened Device Tree, die U-Boot unter anderem mit dem Linux-Kernel und barebox teilt. Laut Quelltext kann derselbe Fehler durch ungeprüfte Rückgabewerte überall dort auftreten, wo dieser Code genutzt wird.