TianoCore EDK II

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Separately, for a merged upstream patch : up to $5,000 Google Patch Rewards pays for a patch you land upstream yourself and that stays merged, without reverts, for one month. It does not pay for the report. This project sits in Tier 2, where awards run from $100 to $5,000; the $15,000 headline is the Tier 1 column and is not reachable here. Patches must be between one and twelve months old, submissions are capped at three per person per month, memory-safety hardening can carry a 2× or 3× multiplier, and sanctions and territory exclusions apply. CVE history 4 Last 12 months 33 Lifetime Memory safety 40 % Parsing/validation 30 % Auth bypass 20 % Info disclosure 5 % Latest advisories Loading the feed Overview EDK II is the reference implementation of UEFI and the upstream from which essentially every x86 PC and server firmware is derived, including AMI Aptio, Insyde InsydeH2O and Phoenix SecureCore, as well as the Arm server firmware stack and the firmware in QEMU/KVM guests through OVMF. A pre-boot flaw here runs beneath the operating system and beneath the hypervisor, survives a reinstall, and is the substrate the whole bootkit class rests on: BlackLotus, CosmicStrand, LoJax. The PixieFail cluster in the network drivers is the reference point for how that surface fails. The project pays nothing for a report, and Intel's bounty is no substitute since its policy covers only projects Intel solely maintains. sorona.xyz pays you directly on qualified, reproduced findings. In scope Reports go in as GitHub Security Advisories under the repository's SECURITY.md, against upstream tianocore/edk2 . An OEM or IBV derivative belongs to that vendor, so the boundary is the upstream tree and every package in it The core dispatch phases, PEI and DXE, and the SMM communication buffer boundary where a ring-0 caller crosses into System Management Mode The network stack in full: the UEFI IPv4 and IPv6, DHCP, TCP, HTTP-boot and iSCSI drivers Filesystem and partition parsing, covering FAT, El Torito and GPT, and the FV/FFS firmware-volume parsers that read the flash image itself Image loading end to end: the PE/COFF loader and the Secure Boot and authenticated-variable verification built on it Capsule update parsing and the variable services store, the paths by which firmware accepts new code and remembers state across boots The BaseCryptLib wrapper and the way it consumes OpenSSL or MbedTLS on behalf of every verification path above OVMF and the virtual platform packages, the open reference target a finding can be demonstrated on without vendor hardware Out of scope OEM and IBV forks such as AMI Aptio, Insyde and Phoenix, where only upstream tianocore/edk2 merges count EDK2 routed as an Intel bounty target: Intel's policy covers only projects 'solely maintained' by Intel, so that is not a second paying route for this code Non-exploitable fuzzer crashes whose fix is a one-liner, which Google explicitly declines to reward on the patch rail Patches over twelve months old, which Patch Rewards will not consider For the Google money specifically, anything reported but never patched upstream, since that pathway pays only on a merge Most-valued findings An SMM callout or communication-buffer validation failure that lets a ring-0 attacker reach System Management Mode, the most privileged execution context on the machine and the top of this codebase's impact ladder Secure Boot or authenticated-variable bypass in the PE/COFF loader or verification path, which makes a bootkit installable on a machine whose owner believes it is locked Remote memory corruption in the UEFI network drivers reachable during PXE or HTTP boot, the PixieFail shape and historically the richest CVE vein here: pre-OS code execution from the local network with no mitigations underneath it Parsing bugs in the firmware-volume, capsule or variable-store code, which are the paths by which an attacker makes a change that survives reinstallation Anything reproducible on OVMF under QEMU, since a finding demonstrable on the open reference platform is one maintainers can act on without vendor hardware Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Send a detailed, reproducible report and name the platform you reproduced on. OVMF under QEMU is the fairest common ground for a firmware finding One vulnerability per report unless a chain is needed to show the real impact Only upstream tianocore/edk2 counts; a bug that exists solely in an OEM or IBV derivative belongs to that vendor Do not expect Intel's bounty to cover this: its policy covers only projects 'solely maintained' by Intel and says projects it merely contributes to 'may fall out of Scope' If you also want the Google patch money, land the fix upstream yourself and keep it merged without reverts for a month. The patch must be between one and twelve months old and you may submit at most three a month Google cannot pay researchers on sanctions lists, in sanctioned territories, or located in Russia or Belarus Disclosure Coordinated with TianoCore through a GitHub Security Advisory, as the repository's SECURITY.md directs, and the project publishes advisories on that channel. Firmware fixes have to travel through IBVs and OEMs before they reach devices, so allow a longer embargo than a normal software project; nothing in the Google rules restricts routing the finding through sorona.xyz. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability