home-assistant-cli CVE-2026-40602
MEDIUM
GHSA-33qf-q99x-wpm8
Severity by source
AV:L/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:N
Attacker needs no system privileges - delivery is via social engineering of a file; PR:N corrects the vendor's PR:H; AV:L and AC:H reflect local rendering and social engineering complexity; no availability impact per advisory.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
4DescriptionGitHub Advisory
Impact
Up to 1.0.0 of home-assitant-cli (or hass-cli for short) an unrestricted environment was used to handle Jninja2 templates instead of a sandboxed one. The user-supplied input within Jinja2 templates was rendered locally with no restrictions. This gave users access to Python's internals and extended the scope of templating beyond the intended usage.
E. g., it was possible to render a template with hass-cli template bad-template.j2 --local that contained entries like
{%- set b = environ.__globals__['__builtins__'] -%}
{%- set os = b['__import__']('os') -%}
{%- set bio = b['__import__']('builtins') -%}
...or other malicious Jinja2 expressions. This can lead to arbitrary code execution on the local machine.
In a two step process an adversary could trick/convince an user to download third-party templates which contain harmful code (e. g., perform data manipulation or establish a remote shell) then to render those templates unchecked/reviewed/verified with --local.
The issue only affect the local machine and not a remote Home Assistant instance. It also requires user interventions.
Patches
1.0.0 uses ImmutableSandboxedEnvironment and restricts the usage of environment variables.
Workarounds
Evaluate the Jninja2 templates manually or tool-based before rendering with hass-cli.
AnalysisAI
Unsandboxed Jinja2 template rendering in home-assistant-cli before version 1.0.0 enables arbitrary code execution on the local machine when a user processes a maliciously crafted template with the --local flag. Exploitation chains two steps - an attacker distributes a crafted .j2 template and social-engineers the victim into rendering it locally - allowing traversal of Python's __globals__ and __builtins__ to invoke arbitrary OS commands. No public exploit has been identified and CISA KEV does not list this CVE, consistent with SSVC's assessment of zero current exploitation; despite the "Technical Impact: total" SSVC rating, real-world risk is substantially limited by the multi-step social engineering preconditions.
Technical ContextAI
The flaw exists in homeassistant_cli/plugins/template.py, where Jinja2's standard Environment class was used without sandboxing restrictions. Jinja2's default environment exposes Python object internals, enabling template authors to chain attribute lookups through environ.__globals__['__builtins__'] to reach __import__ and load arbitrary Python modules including os. The vulnerable package (pip/homeassistant-cli < 1.0.0; CPE: pkg:pip/homeassistant-cli) also bound os.environ.get directly as a template global, providing unrestricted read access to all environment variables - including potentially sensitive values like HASS_TOKEN or HASS_SUPERVISOR_TOKEN. CWE-94 (Code Injection) is the accurate root cause: user-controlled template content was evaluated in an interpreter context without input restriction. The patch replaces jinja2.Environment with jinja2.sandbox.ImmutableSandboxedEnvironment and introduces a SAFE_ENV_VARS allowlist (HASS_SERVER, LANG, TZ) for environment variable access.
RemediationAI
Upgrade home-assistant-cli to version 1.0.0 or later using pip install --upgrade homeassistant-cli; this is the vendor-released patch confirmed by PR #453 (https://github.com/home-assistant-ecosystem/home-assistant-cli/pull/453) and advisory GHSA-33qf-q99x-wpm8. Version 1.0.0 switches to ImmutableSandboxedEnvironment and restricts environment variable access to an explicit allowlist. If upgrade is not immediately possible, the vendor-suggested workaround is to manually or tool-based inspect all Jinja2 templates before rendering with --local - specifically audit for expressions referencing __globals__, __builtins__, __import__, or class traversal patterns (__mro__, __subclasses__). This workaround relies on human review and is error-prone, particularly for complex or obfuscated templates; it should be treated as a temporary measure only. Avoid rendering templates from untrusted or unverified external sources under any circumstances.
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-94 – Code Injection
View allShare
External POC / Exploit Code
Leaving vuln.today