Final Project Idea

Assignment

Analyze and harden the vulnerabilities of a computing system that you want to secure

What do I want to secure?

I am using HomeAssistant for making Smart Home System. It is good opportunity to protect my smart home system. So I choose it as a final project.

Home Assistant’s commercial services and development are primarily handled by Nabu Casa, Inc., a US-based company. They operate the official cloud service “Home Assistant Cloud,” develop official hardware (such as Home Assistant Green), and support the open-source project.

I searched about security on google search

On the HomeAssistant officeal website, they are writhing about how do they keep security as an open source project.

I mapped HomeAssistant vulnerabilities

Based on the list of published vulnerabilities, I mapped each one to a corresponding area of security, with the help of Claude

Cryptography

CVE-2025-25305 (High, CVSS 7.0) — Incorrect SSL validation for outgoing requests SSL validation for outgoing requests in Home Assistant Core and the libraries it uses was not performed correctly. Weak TLS certificate validation opens the door to MITM interception and tampering — a textbook flaw in the usage of cryptography rather than the cryptographic primitives themselves.

Internet Security (Network)

CVE-2026-54317 (High, CVSS 7.6) — Konnected alarm-panel information disclosure The switch state and zone topology of a Konnected alarm panel were disclosed to unauthenticated actors on the LAN; fixed in Home Assistant Core 2026.6.0. A related earlier case, CVE-2023-50715, disclosed user accounts to unauthenticated actors on the LAN. Both exploit the implicit assumption that “anything on the same network can be trusted.” CVE-2026-55844 (High, CVSS 7.5) — iOS app ignores internal SSID allowlist The iOS Companion app ignored its internal SSID allowlist, potentially leaking the access token and sensor data — a failure in network-boundary判定 (trust-zone determination).

Software Security / Memory Safety

This layer needs a caveat. Because HA is written mostly in Python, it produces almost no classic memory-corruption CVEs (buffer overflows and the like). Within the same “software implementation flaw” category, code-injection bugs are the representative class instead. CVE-2026-40602 — Jinja2 template injection in hass-cli (RCE) In Home Assistant CLI (hass-cli) versions prior to 1.0.0, Jinja2 templates were rendered in an unsandboxed environment, giving user input access to Python internals. The root cause was using the standard jinja2.Environment instead of the safer SandboxedEnvironment; an attacker can traverse introspection attributes such as class, mro, and subclasses() to reach os or subprocess and achieve arbitrary code execution. This is Server-Side Template Injection (SSTI) in its purest form. XSS family — CVE-2026-33044 / 33045 / CVE-2025-62172 Stored XSS in the map card and history-graph card (via a malicious device name), fixed in Core 2026.1.2. The 2025 case CVE-2025-62172 was stored XSS in a graph tooltip (High, CVSS 8.5), fixed in Core 2025.10.2. These are web-application-layer vulnerabilities.

Microarchitecture Security

There are essentially no HA-specific CVEs here. Attacks like Spectre, Meltdown, Rowhammer, and Flush+Reload target the underlying CPU (e.g., the Raspberry Pi’s ARM cores) and DRAM, not HA’s code. To give it meaning in the HA context: if you run HA alongside untrusted add-ons or containers on the same Pi, a malicious add-on could plausibly use a cache side channel to infer another process’s secrets (tokens or keys). CVE-2026-31431 is relevant background — privilege escalation from any user script means a rogue add-on or script could harvest stored credentials, and this kind of insufficient process isolation is exactly the precondition microarchitectural attacks rely on.

OS and Application Security

CVE-2026-34205 (Critical, CVSS 9.7) — Unauthenticated endpoints exposed via host network mode Apps (formerly add-ons) configured with host network mode exposed unauthenticated endpoints bound to the internal Docker bridge interface. On Linux this configuration did not restrict access as intended, so any device on the same network could reach these endpoints without authentication; fixed in Supervisor 2026.03.02. This is a container/app isolation misconfiguration — a canonical OS/application-layer case. CVE-2026-31431 — Privilege escalation The root-privilege escalation from a user script noted above; a concrete instance of the “privilege escalation” pattern. Directory traversal Home Assistant Core before v2025.8.0 was vulnerable to directory traversal — the classic path-traversal pattern where ../ reaches files outside the intended scope.

Human Security

Again, this rarely appears as an HA-specific CVE (social engineering targets people, not a product defect). But HA’s design philosophy depends heavily on human assumptions. The non-qualifying-vulnerability statement from our earlier discussion — “every logged-in user is trusted as much as an owner account” — is this domain. HA’s security depends on the human practice of only handing accounts to trusted people; the moment someone’s credentials are stolen via phishing or pretexting, the lack of technical privilege separation lets the damage reach the whole instance. In CVE-2026-44698, an attacker who steals the access token can impersonate the user and, depending on their role, take over the entire instance — and the entry point for stealing that token (luring the victim into rendering a malicious iframe) is largely social engineering.

Hardware Security

This too is about the underlying Raspberry Pi rather than an HA-specific CVE. The relevant threats assume physical access: pulling the SD card lets an attacker read HA’s configuration files and stored credentials/tokens in near-plaintext form (unless disk encryption is explicitly configured), plus firmware extraction via JTAG/UART debug ports. A local-first architecture has the strength of keeping hardware physically in your own hands, but resistance to physical theft or tampering must be provided separately by the operator.

About MQTT vulnerability

I used Fable5 for asking about threat of this system. I ask as “Are there any vulnerabilities in MQTT?”

Protocol-level weaknesses

1. Plaintext and no auth by default MQTT doesn’t enforce authentication or encryption. A bare Mosquitto broker accepts anonymous connections and sends traffic in plaintext. Even on a LAN, other devices on the same segment can sniff packets and subscribe to topics.

I tried to install plugin “mqtt.luq” into Wireshark.

$ brew install lua

1. Wildcard subscription Subscribing to # lets anyone read every topic on the broker if there’s no authorization control. Without ACLs, a single compromised device can read all sensor data and commands.

2. Command injection / spoofing HA Discovery publishes retained messages to homeassistant/# to auto-create entities. With write access, an attacker can register fake devices or send malicious payloads to a command_topic to control actuators. Weak auth means anyone can turn a relay on.

3. Abuse of Retained + QoS Leaving stale or fake states via retained messages, or exhausting the broker with mass QoS2 traffic (DoS). Common misconfigurations

Running Mosquitto with allow_anonymous true Exposing 1883 (plaintext) instead of 8883 (TLS) outside the LAN Accidentally exposing the broker to the internet (a classic case, found in bulk on Shodan) Hardcoding credentials on the ESP32/M5Atom side

Non-qualifying vulnerabilities

In this statement about “Non-qualifying vulnerabilities”, I will mention one sentence.

Privilege escalation attacks for logged in users. Home Assistant assumes every user is trusted and does not enforce user privileges. It assumes every logged in user has the same access as an owner account

By narrowing the scope, they can focus their limited resources on the most critical areas, thereby maintaining a sustainable security posture.