ESPHome EUVD-2026-53344

Exploitation requires three concrete, simultaneous conditions. First, the attacker must be able to write a malicious git repository to a known or predictable path on the local filesystem of the machine running ESPHome - this rules out purely remote attackers and requires at minimum local write access to a directory such as /tmp, a home directory share, or a mounted network volume. Second, the attacker must control or inject content into an ESPHome YAML configuration file that will be processed by the target machine, specifically crafting an external_components block with a git source whose url: field contains a file:// URI pointing to the staged repository. Third, a user or automated pipeline must actively invoke an esphome subcommand that triggers YAML parsing and component loading - such as esphome config, esphome run, or esphome compile - satisfying the UI:R requirement. What limits exploitation: the local attack vector (AV:L) eliminates unauthenticated remote exploitation; user interaction (UI:R) prevents silent background triggering; the attacker's repository must be staged before the esphome invocation occurs; and YAML files that do not include an external_components directive with a git source url: field are entirely unaffected by this vulnerability.

The vendor-provided CVSS 8.6 (AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H) reflects a meaningful but constrained threat. The local attack vector (AV:L) is the primary limiting factor: exploitation requires the attacker to stage a malicious git repository on the target's local filesystem, which presupposes some prior foothold or filesystem write access - making PR:N arguably overgenerous; PR:L better reflects the realistic requirement. The Changed Scope (S:C) and full impact triad (C:H/I:H/A:H) accurately capture that successful exploitation yields arbitrary Python code execution, escaping the validator's security context entirely. No EPSS score, CISA KEV listing, or public proof-of-concept was present in the input data, and no vendor advisory or patched release has been identified. Real-world risk is highest in shared developer environments and CI/CD pipelines where ESPHome YAML files are sourced from untrusted or externally shared repositories and processed automatically; isolated hobbyist workstations where the operator controls all YAML input face substantially lower practical risk. The absence of a network attack vector prevents mass-exploitation scenarios and meaningfully suppresses the real-world exploitability compared to the raw CVSS score suggests.

An attacker with local filesystem write access creates a malicious git repository at a controlled path such as /tmp/evil-components/, embedding arbitrary Python code in a component __init__.py file. The attacker delivers a crafted ESPHome YAML configuration - via a shared project repository, a pull request to a team repo, or a social-engineering download - containing an external_components block with url: 'file:///tmp/evil-components'; when a developer or CI pipeline runs esphome config device.yaml or esphome run device.yaml, cv.url() incorrectly validates the file:// URI, git clones the local malicious repository, and ESPHome's component loader imports and executes the attacker's Python with the full privileges of the invoking process.