Espressif ESP-IDF

Skip to content What this pays sorona.xyz pays 1.25× the program's reward, up to +$1,000 per finding, plus a complexity bonus of up to $1,000 for especially complex or well-chained bugs. Finding │ Program pays │ Through sorona.xyz Any severity, at Espressif's sole discretion by severity and impact │ $200 - $3,600 │ $250 - $4,500 Submit a vulnerability CVE history 8 Last 12 months 25 Lifetime Memory safety 40 % Parsing/validation 25 % Auth bypass 20 % Info disclosure 10 % Latest advisories Loading the feed Overview ESP-IDF is Espressif's first-party SDK for the ESP32 and ESP8266, the default microcontrollers of the connected-device world: Espressif has shipped well over a billion chips, and this Apache-2.0 codebase is the firmware substrate under ESPHome and Tasmota, under a very large share of the smart plugs, bulbs, sensors, relays and thermostats sold by Sonoff, Shelly and the Tuya-based white-label vendors, and under an enormous hobbyist base. Two properties make a bug here unusually expensive. The devices are internet-connected by definition, and they are rarely if ever updated after purchase, so a pre-authentication Wi-Fi or BLE parser defect in ESP-IDF has a realised lifetime in the field measured in years rather than in patch cycles. Espressif runs the program itself, with no platform in between: rewards typically range from $200 to $3,600 depending on severity and impact, with the final amount at Espressif's sole discretion and paid by bank transfer. sorona.xyz adds 1.25× on top of whatever Espressif awards, up to $1,000 more, plus a complexity bonus of up to $1,000 for a well-chained finding. In scope Espressif takes security issues in its own software solutions, filed on the structured form to [email protected] , and ESP-IDF is a named product: the SDK's own SECURITY.md routes reporters into the same incident-response process. Rewards run $200 to $3,600 at Espressif's discretion, on one flat band rather than a severity ladder ESP-IDF core: the FreeRTOS port, the heap and its poisoning checks, memory-protection unit configuration, task isolation, and the bootloader and startup code beneath all of it Secure Boot v2 signature verification, Flash Encryption, and the eFuse and key-management code across ESP32, ESP32-S2/S3/C3/C6/H2 and later parts The wireless stacks and their over-the-air packet parsers, which are the pre-authentication remote surface a device exposes simply by being powered on: Wi-Fi, Bluetooth and BLE, and 802.15.4 with Thread on the parts that carry a radio for it esp_https_ota together with the OTA state machine, rollback and anti-rollback logic, where a defect turns the update channel into the compromise channel The storage stack: the NVS partition parser and its encryption, partition-table handling, the SPIFFS and FAT wrappers, and the SPI flash driver underneath them The networking and application components that carry a device's traffic: esp-tls , the HTTP and HTTPS server and client, MQTT, WebSocket, mDNS and the Wi-Fi provisioning components The host-side tooling Espressif ships with the SDK, including the idf.py build front end, the flashing utilities and the signing and eFuse programming tools that handle key material Out of scope Vulnerabilities in third-party libraries, which the program excludes verbatim: that carve-out takes mbedTLS, lwIP and ArduinoJson out even though they are vendored into or used alongside ESP-IDF Third-party services not operated by Espressif Example-only code, unless you can show the same pattern exists in the production SDK Issues in software outside Espressif's longevity commitment period, meaning parts and releases past their supported window Physical-attack and glitching research against the silicon, which the program's text does not address at all and should be assumed out Anything filed as a public GitHub issue, which disqualifies the report regardless of how good the bug is Most-valued findings Pre-authentication remote code execution reached through the Wi-Fi or BLE packet parsers, the highest-impact class here: it needs no pairing, no credentials and no user action, and memory safety is 40% of this project's history A Secure Boot v2 or Flash Encryption bypass that lets unsigned firmware run or lets encrypted flash be read, which breaks the one guarantee a shipped device cannot re-establish in the field An OTA flaw in esp_https_ota or the rollback logic that lets an attacker install firmware of their choosing, since that converts a single bug into permanent control of the device Memory corruption in the NVS or partition-table parsers driven by attacker-controlled stored data, the shape that survives a reboot Authentication bypass in the HTTP server, MQTT or WebSocket components, 20% of the recorded history and the class that turns a local-network device into an open one Anything reproducible on a default menuconfig configuration rather than one the reporter had to weaken, because that is the configuration the billion shipped devices are running Program rules Submit through sorona.xyz first. We validate, coordinate with the program's security team, and add the payout uplift on top of whatever it awards. Use the mandatory structured report form (Espressif_Security_Vulnerability_Report_Form_v1.1.pdf) and send it to [email protected] : the SDK's own SECURITY.md routes reporters to exactly that process Never open a public GitHub issue for a security defect; ESP-IDF's policy says so explicitly and doing it disqualifies the report Hold all vulnerability detail strictly confidential until Espressif has released the patch or the advisory, which in practice runs to roughly 90 days Third-party libraries are explicitly out of scope, which excludes mbedTLS, lwIP and ArduinoJson even though they ship with or alongside ESP-IDF Amounts are at Espressif's sole discretion within the published $200 to $3,600 band and are paid by bank transfer; the program text was revised effective 2026-05-29 Ignore the old bug-bounty page at espressif.com/en/news/bug-bounty: it is dated 2016 with a 2018 update and its $500 and $1,729 figures have been superseded Disclosure Coordinated through Espressif's own incident-response process (ESIRP), which publishes advisories on a documented timeline and asks you to stay quiet until the patch or advisory is out: about 90 days in practice. 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