CVE-2026-40602Medium· 5.6▾ SunlitHome Assistant Command-line Interface: Handling of user-supplied Jinja2 templates
▾ Sunlit zone — Low / medium · no exploitation signal
impact 30.8 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Jul 13.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
Last analysed / modified upstream
0.1%
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.
1.0.0 uses ImmutableSandboxedEnvironment and restricts the usage of environment variables.
Evaluate the Jninja2 templates manually or tool-based before rendering with hass-cli.
homeassistant-cli < 1.0.0Upgrade to a patched release:
homeassistant-cli 1.0.0