A Secure Boot bypass vulnerability exists in New Horizon Data Systems bootloaders released before 2022-06-01. The affected bootloader is signed and therefore trusted by UEFI Secure Boot implementations that accept the relevant Microsoft third-party UEFI signing chain, but it does not provide adequate protection against misuse as a pre-boot execution path. An attacker can replace the legitimate signed bootloader used by a target system with the vulnerable New Horizon Data Systems bootloader and then use it to load and execute arbitrary code during the pre-boot phase, thereby bypassing or tampering with Secure Boot protections. The issue is fundamentally a trust failure in which a signed third-party UEFI application can be abused to subvert the Secure Boot chain rather than enforce it.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This 10-file repository is a proof-of-concept for CVE-2022-34302, a New Horizon Datasys Reboot Restore Rx/RollBack Rx UEFI bootloader design flaw. The signed shdloader.efi performs its own PE/COFF loading of \EFI\Boot\shdmgr.ef_ instead of using firmware LoadImage()/StartImage() services, so it does not apply Secure Boot signature validation to that second-stage image. Replacing shdmgr.ef_ with a compatible unsigned UEFI application results in pre-OS code execution. The exploit source is under 02 Exploit/. PayloadShdmgr/shdmgr.ef_.c is an EDK2 UEFI application whose UefiMain only displays a confirmation banner and waits for keyboard input. ForceReloc.nasm and its C reference deliberately retain an absolute relocation, ensuring the resulting x64 PE image has a .reloc section; this is necessary because the vulnerable loader rejects images without valid base-relocation data. The .inf, .dsc, and .dec files provide EDK2 module, platform, and package build metadata. Scripts/VerifyPE.py is a Python utility using pefile that validates an EFI binary's machine type, EFI-application subsystem, relocation directory, .reloc section, and basic layout against the loader's expectations. It is a compatibility checker, not the primary exploit. No compiled malicious EFI binary, network communication, remote endpoint, persistence implementation, or operational payload is included. Exploitation requires privileged local or physical control of the EFI System Partition and a non-revoked vulnerable signed bootloader, so this repository is categorized as a POC rather than an operational bootkit.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
4 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
A cited example of a non-shim third-party UEFI application vulnerability that can enable Secure Boot bypass; mentioned only as background.
A Secure Boot-related boot loader bypass vulnerability involving the New Horizon Data Systems Inc boot loader, addressed via Secure Boot DBX updates.
A vulnerability in third-party UEFI bootloaders signed by Microsoft allows attackers to bypass Secure Boot, undermining the boot process security.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.