wolfBoot

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 get accepted upstream and that stays merged, without reverts, for one month, not for the report. wolfBoot sits in Tier 2, which caps at $5,000; the $15,000 headline is the Tier 1 column and is not reachable here. Patches must be no more than twelve months old, submissions are rate-limited to three per person per month, and sanctions and territory exclusions apply. Latest advisories Loading the feed Overview wolfBoot is the secure bootloader companion to wolfSSL and wolfCrypt, targeting Cortex-M and RISC-V microcontrollers where FIPS 140-3 validated crypto and measured boot are required in a tiny footprint: medical devices, industrial controllers, avionics-adjacent equipment, automotive secondary ECUs and metering. It is one of the very few open-source bootloaders already shipping post-quantum LMS and XMSS signature verification, so it matters disproportionately to the next decade of firmware signing. On an MCU the bootloader is the root of trust and there is usually nothing above it that can compensate for a defect. It carries zero CVEs, which reflects how little external attention this code has had. wolfSSL pays nothing for a report, so sorona.xyz pays you directly on qualified, reproduced findings. In scope Reports go to wolfSSL through the address in the project's SECURITY.md. The covered object is the GPL-3.0 upstream bootloader in full, with the paid commercial build variants sitting outside it The whole pre-verification parsing surface: firmware image header (manifest) parsing and the TLV field walker, which run on attacker-supplied bytes before any signature has been checked Signature verification across every algorithm the bootloader supports, covering the ECDSA, Ed25519, RSA and post-quantum LMS and XMSS paths, where a verification flaw makes an unsigned image boot The update machinery end to end: rollback and anti-downgrade version enforcement, the update-partition state machine that decides which image is authoritative, encrypted-update key handling, and the swap and backup logic for A/B updates, including behaviour across an interrupted or power-cut swap TPM 2.0 measured-boot integration and the wolfTPM interface, where a measurement that can be influenced breaks attestation Every platform port the project ships, covering Arm Cortex-M, RISC-V, PowerPC and x86, whose linker and memory-protection assumptions differ from one another Out of scope The commercially licensed build variants insofar as they diverge from the GPL-3.0 upstream Vulnerability reports with no merged patch behind them, which earn nothing on Google's rail Non-exploitable crash-only one-liners, which sit at the bottom of the reward ladder and often below it Patches over twelve months old, which fall outside the program's age window Physical-attack scenarios such as glitching or decapping that assume laboratory access to the die rather than a software path Patches the wolfSSL maintainers decline, since the reward is contingent on the merge rather than on the idea Most-valued findings Anything that makes an image verify when it should not. A signature-verification or manifest-parsing flaw that boots unsigned or attacker-signed firmware is the whole ballgame on a bootloader, and parsing plus auth bypass is 65% of the expected bug profile here Memory corruption in the TLV header walker reachable before signature verification, since that code processes untrusted bytes with the full privilege of the boot stage Rollback-protection bypass that lets a fielded device be pushed back to a known-vulnerable firmware version, which quietly reopens every CVE that version carried Defects in the LMS or XMSS verification paths, which are new, stateful, and have had far less external review than the ECDSA and RSA code beside them Update state-machine flaws around the A/B swap: an interrupted or attacker-timed swap that leaves the device booting the wrong partition or an unauthenticated one Measured-boot integration flaws where a value an attacker influences still produces an attestation the verifier accepts 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. The cash on Google's rail is paid for a merged upstream patch rather than for a vulnerability report; a report on its own earns nothing there Submit the patch to the wolfSSL maintainers yourself and keep it merged, without reverts, for one month before claiming Patches must be no more than twelve months old when you submit them for reward Three Patch Rewards submissions per person per month is the hard cap Only the GPL-3.0 upstream qualifies; wolfSSL's paid commercial licence is a separate product and a patch confined to its build variants is outside the open-source object Google cannot pay individuals or entities on sanctions lists, in sanctioned territories, or located in Russia or Belarus Disclosure Coordinated with wolfSSL through the address in the project's SECURITY.md; the company publishes advisories and credits reporters by name but pays nothing for the finding. That matters here because firmware written to a signed-image format takes months to reach fielded devices. 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