TinyUSB

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. Latest advisories Loading the feed Overview TinyUSB is the default open-source USB stack for microcontrollers: the USB implementation in the Raspberry Pi Pico SDK across every RP2040 and RP2350, in CircuitPython and much of MicroPython, in Espressif's ESP32-S2 and S3 support, across Adafruit's product line, and in vendor SDKs and community ports for STM32, nRF52/53, SAMD and i.MX RT. It sits directly on the physical USB boundary, so a descriptor-parsing bug is exploitable by anyone who can plug something in: the evil-maid and malicious-charger model, against devices that rarely carry any memory-safety mitigation. No CVE has ever been filed against it, which for a stack that exists to parse untrusted input marks an unworked target rather than a clean one. The project pays nothing, so sorona.xyz pays you directly on qualified, reproduced findings. In scope Reports go in as GitHub Security Advisories on hathach/tinyusb , and upstream is the boundary: a vendor SDK copy or a downstream port counts only when the defect is in the upstream tree. Everything in that tree is in play The device stack in full: SETUP packet parsing and the dispatch of standard, class and vendor control requests The host stack in full, including configuration, interface, endpoint and HID report descriptor parsing, all of it read from a device the host has no reason to trust The class driver set as a whole: CDC-ACM, MSC and its SCSI command handling, HID, Audio, Video, DFU and the vendor class The DFU class specifically, a direct firmware-write primitive and the highest-consequence driver in the tree Endpoint buffer management, and the DCD and HCD portability layer between the stack and each silicon vendor's controller The per-port glue for the boards and silicon families the tree supports, where a shared abstraction is implemented once per controller Out of scope Vendor SDK copies and downstream ports where the defect does not exist in upstream hathach/tinyusb Crash-only one-liners, which Google explicitly declines to reward on the patch rail Patches over twelve months old, which Patch Rewards will not consider Limitations of the OSS-Fuzz harness rather than the stack: the integration is x86_64 only and aarch64 is not yet supported, which is a tooling gap rather than a vulnerability For the Google money specifically, anything reported but never patched upstream, since that pathway pays only on a merge Most-valued findings Memory corruption in descriptor or control-transfer parsing reachable by plugging in a hostile device or cable, which is half the expected bug mass here and the reason the stack exists on the trust boundary A DFU-class flaw that lets an attached device write firmware it should not be allowed to write, turning a physical-access moment into permanent control of the board MSC SCSI command handling defects, where a host or device on the other side of the link supplies lengths and offsets the stack then trusts Buffer-management errors in the endpoint and DCD/HCD layer, since one bug there reproduces across every silicon port that shares the abstraction Anything demonstrated with an emulated USB device rather than custom hardware, because it gives the maintainer a reproducer and makes the fix landable 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 with the descriptor set, SETUP packet sequence or emulated-device script that triggers it, and name the port and board you reproduced on One vulnerability per report unless a chain is needed to show the real impact Only upstream hathach/tinyusb counts; vendor SDK copies and downstream ports are not this target unless the defect is in the upstream tree Give the maintainer room to ship a fix before any public writeup. This is a small team and firmware fixes take time to reach devices 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 the maintainer through a GitHub Security Advisory on hathach/tinyusb . There is no CVE history to set expectations against, so agree a timeline explicitly rather than assuming one; 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