Severity by source
AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
PR:L replaces the vendor's PR:N because staging a malicious local git repository requires filesystem write access, implying at minimum low-privilege local access; all other vendor metrics are consistent with the description.
Primary rating from Vendor (TuranSec).
CVSS VectorVendor: TuranSec
Lifecycle Timeline
2DescriptionCVE.org
ESPHome through 2026.7.0-dev contains an operator-precedence bug in the cv.url() validator in esphome/config_validation.py: if parsed.scheme and parsed.netloc or parsed.scheme == "file": return parsed.geturl(). Because and binds tighter than or, any file: URI passes validation regardless of netloc. This validator gates the url: field of the external_components YAML directive's git source schema, which is passed to git clone (git supports file:// natively). A crafted external_components block with url: "file:///attacker/repo" clones an attacker-controlled local path, which is then added to Python's import machinery via ESPHome's component loader, executing arbitrary Python code when the YAML configuration is processed (e.g. via esphome config/esphome run).
AnalysisAI
Remote code execution in ESPHome through 2026.7.0-dev allows any attacker who can supply a crafted YAML configuration to execute arbitrary Python code on the machine that processes it. The vulnerability is an operator-precedence bug in the cv.url() validator: Python's 'and' binding tighter than 'or' causes any file:// URI to unconditionally pass validation, bypassing the intended network-URI-only restriction on the external_components git source URL field. ESPHome then invokes git clone against the attacker-supplied local path and loads the resulting repository into Python's import machinery, yielding full code execution with the privileges of the esphome process; no public exploit has been identified at time of analysis.
Technical ContextAI
ESPHome (cpe:2.3:a:esphome:esphome:*:*:*:*:*:*:*:*) is a Python-based firmware build system for ESP8266/ESP32 microcontrollers widely used in the Home Assistant ecosystem. Its external_components YAML directive allows sourcing custom firmware components from a remote git URL, which is validated by the cv.url() function in esphome/config_validation.py before being passed to git clone. The vulnerable expression - if parsed.scheme and parsed.netloc or parsed.scheme 'file': return parsed.geturl() - evaluates as (parsed.scheme and parsed.netloc) or (parsed.scheme 'file') due to Python operator precedence, meaning any URL whose scheme is literally 'file' passes validation regardless of whether netloc is populated. This is a textbook CWE-184 (Incomplete List of Disallowed Inputs): the validator fails to exclude the file:// input class it was designed to reject. Because git natively supports file:// cloning and ESPHome's component loader unconditionally adds the cloned path to Python's sys.path and import machinery, the trust boundary between external URL validation and local code execution is completely bridged.
RemediationAI
No vendor-released patch version has been identified at time of analysis - the provided references point only to the source repository and the vulnerable file, not to a fix commit or tagged release. The correct code fix requires adding explicit parentheses to restore intended logic, either as if parsed.scheme and (parsed.netloc or parsed.scheme == 'file'): return parsed.geturl() to permit file:// URIs that include a netloc, or more defensively by explicitly rejecting the file:// scheme in the external_components URL validator regardless of netloc. As immediate compensating controls, operators should audit all ESPHome YAML configurations for external_components blocks containing url: fields referencing file:// or local paths using grep -r 'file://' *.yaml; automated pre-processing in CI/CD pipelines can enforce rejection of such patterns before esphome is invoked. Restricting filesystem write access for untrusted users to directories outside the esphome working path limits an attacker's ability to stage a malicious repository in a reachable location. Running esphome inside a Docker container with a read-only volume mount for the configuration directory and no access to host filesystem paths prevents local file:// traversal from reaching attacker-controlled content, at the cost of requiring container orchestration overhead.
Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t
BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser
pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi
The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python
BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.
Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301
In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse
Unauthenticated remote code execution affects Kestra OSS (the open-source event-driven orchestration platform) prior to
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne
Same weakness CWE-184 – Incomplete List of Disallowed Inputs
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-53344
GHSA-2g7j-rv69-9w67