CVE-2022-34303 is a Secure Boot bypass vulnerability in Eurosoft UEFI bootloaders released before 2022-06-01. The affected bootloader is signed and therefore trusted by Secure Boot, but it can be abused to undermine Secure Boot protections. An attacker who can replace the legitimate signed bootloader with the vulnerable Eurosoft bootloader can then load and execute arbitrary code during the pre-boot phase. This breaks the intended trust chain of UEFI Secure Boot by allowing a trusted-but-dangerous boot component to be used as a vehicle for unauthorized code execution before the operating system starts.
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 five-file repository is an operational, manual UEFI Shell proof-of-concept for CVE-2022-34303, a CryptoPro Secure Disk signed-bootloader issue enabling BYOVUA (Bring Your Own Vulnerable UEFI Application). The repository contains two interactive UEFI Shell scripts under 02 Exploit/, a detailed README, GPLv3 license, and a generic build-artifact .gitignore. It contains no compiled UEFI application, network client, or remote C2 functionality. ApproachA_Patch_Function.nsh identifies the SecurityStubDxe-installed Security2 protocol, obtains its FileAuthenticationState callback address, and directs the operator to patch its first four bytes so it immediately returns EFI_SUCCESS. ApproachB_Nullify_gsecurity2.nsh uses the Security1/Security2 protocol-interface addresses to help find the DxeMain global gSecurity2 pointer, then sets that pointer to NULL. In both cases, DxeMain LoadImage() no longer performs Security2 signature checks, allowing unsigned EFI binaries to load. The scripts are deliberately interactive: UEFI Shell limitations prevent parsing command output or automatically scanning/calculating addresses, so the user must inspect dh, dmem, and mm output and adapt values to the specific firmware build. The README identifies OVMF addresses only as examples and notes that firmware updates/rebuilds require rediscovery. The technique is pre-OS and requires booting the trusted-but-vulnerable CryptoPro UEFI shell; it is not a network exploit.
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.
3 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
A Secure Boot-related boot loader bypass vulnerability involving the Crypto Pro 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.