Loading story…
A technical write-up published by 0x434b argues that Secure Boot can be bypassed without breaking cryptography when trust is lost elsewhere in the boot chain. The article frames Secure Boot as an end-to-end authorization system rather than a simple signature check and groups failures into four categories: verification that never ran or was not enforced, signatures that covered the wrong bytes, trust placed in the wrong signing authority, and cases where verified code differed from what ultimately executed. It cites public examples including CVE-2019-2278, CVE-2023-48425, CVE-2023-50810, CVE-2021-1931, and Android Verified Boot test keys left in production firmware to show how locked devices can still load unauthorized code.
The research also says measured boot and remote attestation only help if they independently measure the state that actually ran, warning that back-end trust decisions can fail when evidence does not reflect real execution. The post was amplified on r/netsec as an offensive-security-oriented walkthrough of hardware roots of trust, Qualcomm and Android boot stages, UEFI, and attestation, while a separate oss-security thread on a proposed fallback.efi/SBAT/GRUB memdisk bypass showed how disputed Secure Boot bypass claims can hinge on trust-model assumptions. In that discussion, maintainers from Red Hat and Oracle argued the reported chain required privileges that already undermine the platform's security guarantees, underscoring the article's broader point that boot integrity depends on enforcement, authority, coverage, and continuity across the full chain.
Get the actors, campaigns, and ATT&CK mapping behind it.
22 events from the most recent confirmed update back to the earliest known activity.
A Reddit post by user 0x00rick linked to the 0x434b.dev article and described it as an offensive-security-oriented walkthrough of secure boot, UEFI, Android Verified Boot, measured boot, and attestation.
0x434b published a technical analysis arguing that secure boot failures fall into enforcement, coverage, authority, and continuity classes, using public case studies rather than presenting a new zero-day.
In the oss-security discussion, Solar Designer proposed July 1, 2026 for public disclosure because distros-list policy allowed a maximum 14-day embargo, and Jeremy Erazo accepted that date.
The article references CVE-2024-32883 affecting MCUboot, where security-relevant TLV types could remain unprotected and feed unauthenticated properties into attestation data.
According to the article, Microsoft mitigated CVE-2024-7344 by revoking old signed binaries through the UEFI dbx while the vendor fixed the loader; the analysis was attributed to ESET.
The article cites CVE-2024-7344 involving a Microsoft-signed UEFI binary, reloader.efi, that manually loaded and executed cloak.dat without calling LoadImage(), bypassing the platform secure boot check for the child image.
The article references CVE-2023-39902 on several NXP i.MX 8M families, where an unauthenticated FIT or FDT description was parsed before the FIT payload was authenticated, enabling writes over SPL memory.
The article cites CVE-2023-50810 affecting the Sonos Era 100, where sonosboot verified a genuine signed kernel while unsigned metadata and boot arguments caused Linux to consume an attacker-controlled initramfs.
The article states CVE-2023-48424 enabled the Chromecast chain by stalling eMMC boot long enough to interrupt U-Boot over UART, and CVE-2023-6181 later provided persistence by abusing insufficiently restricted Bootloader Control Block data from the misc partition during preboot.
The article says CVE-2023-48425 affected Google Chromecast devices using an Amlogic SoC because U-Boot overwrote an AVB verification result with success when the upgrade_step environment variable was set to 3.
The article references CVE-2023-20696 affecting MediaTek preloader, where the signature verifier and later parser interpreted the same certificate container differently, enabling forged firmware hashes to pass as authentic.
The article cites OP-TEE-2022-0001 on Raspberry Pi 3, where an EM fault could clear a non-zero signature error to TEE_SUCCESS and cause acceptance of an invalid signature.
The article references CVE-2019-14560 in EDK II, where the result of GetEfiGlobalVariable2() was not checked when determining whether secure boot was enabled.
The article says CVE-2019-2278 affected several Qualcomm Snapdragon families because a user-keystore signature verification failure during boot did not stop the rejected keystore from being used as an authority.
The article cites CVE-2018-1000205 in U-Boot FIT, where a hashed-strings offset supplied by the FIT itself could influence what the verifier covered.
The article references CVE-2018-20785 affecting the Neato Botvac Connected and related Vorwerk robot vacuums, where a hidden boot menu could XMODEM-upload and execute an unsigned QNX IFS.
The article cites CVE-2016-10277 on the Nexus 6, where Motorola boot configuration allowed initrd injection so a signed kernel consumed an unauthorized initramfs.
A belated oss-security summary reposted the previously embargoed discussion about the claimed shim fallback.efi/SBAT/memdisk bypass chain and noted prior discussion had suggested there was no security relevance.
The oss-security thread records Red Hat and Oracle responders challenging Jeremy Erazo's proposed fallback.efi/SBAT/GRUB bypass chain, arguing it depended on privileges or trust conditions that already defeated the model and might not merit a CVE.
The article says AVBTestKeyInTheWild demonstrated complete attacks on three production devices across Qualcomm, MediaTek, and Unisoc SoCs by resigning modified AVB graphs with public AOSP test private keys.
The AVBTestKeyInTheWild research found AOSP AVB test keys in first-party production firmware and identified 69 potentially vulnerable device models by scanning official firmware images.
The article describes Nokia 6 research showing that forcing a Qualcomm MSM8937 phone into EDL and using signed Firehose programmers with memory primitives enabled patching boot stages after verification and booting a modified kernel and ramdisk.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
Get the adversaries, campaigns, and ATT&CK mapping behind this technique, with detections ready to deploy.
3 references tracked. Mallory keeps watching after this page renders.
reddit.com
Open source0x434b.dev
Open sourceseclists.org
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 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.
Jul 23, 2026
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
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.
Jul 13, 2026