ESPHome

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 CVE history 2 Last 12 months 6 Lifetime Auth bypass 40 % Access control 25 % Memory safety 20 % Info disclosure 15 % Latest advisories Loading the feed Overview ESPHome turns a YAML configuration into firmware for ESP8266 and ESP32 hardware, and it runs on millions of smart plugs, switches and sensors permanently joined to their owner's Home Assistant instance over a local API. A device speaking that API holds a credential into the household's automation hub, so a flaw in the firmware reaches further than the one plug it runs on. CVE-2025-57808 is the reference point: an authentication bypass in the bundled web server, published as an ESPHome advisory even though the defective code came from Espressif. The project states in writing that it cannot offer bounties, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy accepts security vulnerabilities in ESPHome and points reporters at a published threat model that defines the trust boundaries. Anyone who can edit a device configuration counts as trusted, and everything below sits outside that trusted position The native API server, the protocol Home Assistant uses to talk to a device, including its noise encryption handshake and the authentication that gates it The over-the-air update path: the OTA password check, the transfer protocol and the image validation that decides what firmware gets written to flash The bundled web server component and its authentication, along with the captive portal and improv provisioning flows that run before a device is on the network The MQTT client, the credentials it holds, and both what it publishes and what it accepts from a broker Wi-Fi provisioning and stored credentials, including whatever a device leaks while it is sitting in access-point mode The Bluetooth Low Energy components: the BLE tracker, the proxy that relays another device's traffic back to Home Assistant, and every BLE client component that parses advertisements Protocol components that read data from external hardware, covering the infrared and RF remote receivers, the Zigbee, Modbus, UART and CAN bus components and the long tail of sensor drivers The Python build toolchain that compiles a configuration into firmware, including config validation and the external components mechanism The ESPHome dashboard and its API, which builds and flashes firmware and holds every device's secrets Out of scope Configuration-driven code execution by someone who can already edit a device config; the published threat model states that person is trusted Espressif's own code, including ESP-IDF and the Arduino ESP32 core, which carries a separate paid programme at [email protected] Home Assistant Core and Supervisor defects, which belong to that project's own policy and advisory stream Third-party external components pulled in from outside the ESPHome tree Physical attacks on a device an attacker already holds, including reading flash over the serial header Denial of service against a device by flooding its network or radio interface Most-valued findings Authentication bypass on the native API or the bundled web server, the class CVE-2025-57808 landed in, since either one is remote access to a device sitting inside somebody's home network Anything that gets unsigned or attacker-chosen firmware onto a device through the OTA path, which is a permanent implant on hardware nobody inspects again Recovery of the API encryption key, the OTA password or stored Wi-Fi credentials from a device or from its network traffic Memory corruption in a component that parses input from radio or from a bus: BLE advertisements, infrared and RF codes, Modbus and UART frames all arrive with no authentication in front of them Provisioning defects in the captive portal or improv flows, where a device is briefly reachable by anyone in range and hands over network access Anything reachable from a compromised MQTT broker or a hostile Home Assistant instance that turns into code execution on the device Defects in the dashboard or the build toolchain that let a hostile configuration or external component execute on the build machine, which typically holds every device's secrets at once 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. Report through GitHub private vulnerability reporting on esphome/esphome, which the project enables The security policy lives in the org-level esphome/.github repository rather than in the project repo, so read it there before filing Read the published THREAT_MODEL.md first. It states that anyone able to edit a device configuration is already trusted with code execution, so config-injection findings are documented as out of scope Name the platform and framework. ESP8266, ESP32 on Arduino and ESP32 on ESP-IDF are different builds, and a defect may exist in only one of them If the defective code is Espressif's rather than ESPHome's, say so and take it to Espressif, which runs a paid programme at [email protected] for issues in its own software Include the YAML configuration that produced the firmware you tested, since the generated code varies enormously with the components enabled The policy states plainly that an open source project cannot offer bounties and offers a credit line instead, so there is no payment to negotiate upstream Disclosure Coordinated privately through GitHub and published as a GitHub Security Advisory alongside a release. Volume is low, two advisories in the last year against six ever published, so triage is unlikely to be instant. Bear in mind that a firmware fix only reaches a device when its owner rebuilds and reflashes, and a great many ESPHome devices are never touched again after installation, so treat public disclosure as the start of a long tail rather than the end of the exposure. 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