Loading story…
Binarly disclosed six critical vulnerabilities in U-Boot's FIT signature verification logic that can be triggered by a malicious FIT image before signature checks complete, breaking the intended Verified Boot trust model. The flaws affect code paths present since U-Boot v2013.07, potentially spanning more than 50 stable releases and numerous vendor forks used in embedded devices, routers, IoT products, and server BMCs; two of the issues may allow arbitrary code execution during boot, while the others can cause denial of service.
Researchers warned that exploitation may not require physical access if devices accept firmware through insecure remote update paths such as exposed BMC interfaces, raising the risk of device bricking or persistent firmware implants below the operating system. U-Boot maintainers handled the issues through coordinated disclosure and merged fixes into the mainline repository, and downstream users were urged to update or backport patches because the long-lived, widely reused bootloader code creates broad supply-chain exposure.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
5 events from the most recent confirmed update back to the earliest known activity.
Binarly Research publicly disclosed six critical vulnerabilities in U-Boot’s FIT signature verification logic, warning they affect code paths present since U-Boot v2013.07 and many vendor forks. The disclosure highlighted pre-verification attack paths that could enable denial of service and potentially arbitrary code execution, including via insecure remote firmware update channels such as BMC interfaces.
U-Boot maintainers received a coordinated disclosure from Binarly Research and merged patches for six vulnerabilities in FIT signature verification logic into the mainline repository. The flaws can cause denial of service and, in some cases, arbitrary code execution during boot.
Although upstream fixes for the six FIT signature verification vulnerabilities were merged in June, the U-Boot v2026.07 release was published without them. As a result, vendors must manually pull the upstream patches until a later stable release includes the fixes.
Binarly published individual advisories with proof-of-concept FIT images and reproduction steps for the six U-Boot FIT verification vulnerabilities. The release provided concrete technical details to demonstrate and reproduce the issues affecting U-Boot versions since v2013.07.
A coordinated vulnerability disclosure covering multiple U-Boot vulnerabilities was published to the U-Boot mailing list. This marks the public disclosure point referenced for the affected FIT signature verification issues.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
8 references tracked. Mallory keeps watching after this page renders.
securityaffairs.com
Open sourcecysecurity.news
Open sourcethehackernews.com
Open sourcecyberaccord.com
Open sourcecybersecuritynews.com
Open sourcebleepingcomputer.com
Open sourcebinarly.io
Open sourcelists.denx.de
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Researchers disclosed two separate boot-chain security issues that undermine trusted startup protections on major platforms. CERT/CC warned that outdated Microsoft-signed UEFI **shim** bootloaders—especially `shim` version `0.9` and earlier, including forked or unpatched builds used by vendors such as Red Hat Enterprise Linux, CentOS, Oracle, OpenSUSE, and WhiteCanyon—can be abused to bypass **Secure Boot** and run arbitrary code before the operating system loads. Because the attack executes in the early boot phase, it can evade EDR visibility and establish persistent compromise; Microsoft is responding by expanding the UEFI Forbidden Signature Database (**DBX**) to revoke vulnerable bootloaders, while administrators have been urged to update signature databases first and test carefully to avoid leaving systems unbootable. Paradigm Shift also disclosed an **unpatchable BootROM flaw** in Apple `A12` and `A13` chips and released a proof-of-concept exploit, `usbliter8`, showing that affected devices from the iPhone XS through the iPhone 11 line can be compromised during startup. The bug stems from USB controller behavior in SecureROM that allows unauthorized memory writes via crafted packets, enabling temporary reduction of security settings, booting of unsigned software, and the familiar `PWND` USB serial marker after exploitation. Apple was notified before publication, but because the weakness is embedded in silicon, software updates cannot fully eliminate the risk for affected devices over their operational lifetime.
Jun 29, 2026
Researchers from Eclypsium discovered that nearly 200,000 Linux-based Framework laptops and desktops were shipped with signed UEFI shell components containing a powerful 'memory modify' (mm) command, which can be exploited to bypass Secure Boot protections. The mm command, intended for low-level diagnostics and firmware debugging, provides direct read and write access to system memory, including critical security variables such as gSecurity2. By abusing this command, an attacker can overwrite the gSecurity2 variable with NULL, effectively disabling signature verification for all subsequent UEFI module loads and breaking the Secure Boot trust chain. This vulnerability allows attackers to load bootkits such as BlackLotus, HybridPetya, and Bootkitty, which can evade operating system-level security controls and persist even after OS reinstallation. The attack can be automated using startup scripts, ensuring persistence across reboots. The issue is not the result of a supply chain compromise or malicious intent, but rather an oversight in the inclusion of diagnostic tools signed with trusted certificates. Eclypsium's research highlights that these signed UEFI shells, while legitimate, function as backdoors that undermine the security model of Secure Boot. The presence of such tools in production devices exposes users to significant risk, as attackers can leverage them for pre-OS infections, espionage, sabotage, or ransomware attacks. The gaming industry has already seen commercial cheat providers exploiting similar UEFI-level bypasses, and the same techniques could be adopted by nation-state actors or advanced persistent threats. Framework has acknowledged the issue and is working on remediation, with fixes planned for affected models such as the Framework 13 (11th and 12th Gen Intel). The discovery underscores the broader risk of trusted, signed components containing powerful functionality that can be misused, and the need for rigorous review of firmware-level tools included in shipping devices. The vulnerability demonstrates that even systems marketed as secure and repairable can harbor critical flaws if diagnostic utilities are not properly restricted. The incident serves as a warning to hardware manufacturers and the security community about the dangers of trusted but overly permissive firmware components. Eclypsium's findings have prompted a reassessment of trust models in firmware security, emphasizing the importance of minimizing attack surfaces in pre-boot environments. The case also illustrates how attackers are increasingly targeting lower layers of the computing stack to achieve persistence and evade detection. Framework's response and the ongoing remediation efforts will be closely watched by the industry as a test case for responsible disclosure and mitigation of firmware-level threats.
Jun 29, 2026
runZero disclosed seven vulnerabilities in the widely reused **FatFs** filesystem library, a FAT/exFAT implementation embedded in firmware for devices such as cameras, drones, industrial controllers, crypto wallets, and RTOS-based products. The flaws affect FAT, exFAT, and GPT parsing and can be triggered by crafted USB drives, SD cards, partition tables, or mounted firmware/update images, leading to memory corruption, denial of service, information disclosure, silent data corruption, and possible code execution. The most serious issues include **`CVE-2026-6682`**, an integer overflow in `mount_volume()` that can corrupt file-size metadata and enable downstream exploitation, and **`CVE-2026-6687`**, a stack overflow in `f_getlabel()` tied to exFAT label handling. The disclosure warned that the blast radius is large because FatFs is vendored into ecosystems including **ESP-IDF, STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed, TizenRT, and SWUpdate**, with exploitation often requiring physical access but also potentially reaching devices through OTA workflows that automatically mount malicious images. runZero said all released versions are affected, only **`CVE-2026-6684`** is fixed upstream in **FatFs R0.16**, and no coordinated maintainer response was received despite outreach through **JPCERT/CC**. Researchers published proof-of-concept disk images, a test harness, and a QEMU-based exploit example, while warning that downstream vendors will need to identify and patch their own bundled copies and that remediation may take years for many products.
Jul 7, 2026