Home Assistant: 2026.6.0 is not enough, CVE-2026-64824 needs 2026.7.0

Home Assistant, the popular free software for controlling your home's appliances and IoT devices from one place, has two serious flaws in its backup feature. With CVE-2026-64825 and CVE-2026-64824, feeding a crafted backup file lets an attacker write an arbitrary file anywhere on the device and, ultimately, take it over. No login is required, and both are rated 9.3 (Critical).

The awkward part is that the two fixes landed in different releases: 64825 in 2026.6.0, 64824 in 2026.7.0. This is especially dangerous on "Home Assistant OS" and "Supervised" installs (e.g. on a Raspberry Pi) and on the official Docker image, where the software runs with administrator (root) privileges. Below we walk through what happens and whether your setup is at risk.

Who targets this, and why

The people who exploit this are attackers who find, over the network, a Home Assistant that is mid-setup or in the middle of a backup restore for a server migration. Before setup completes, a Home Assistant has no owner account yet and can accept a backup upload from outside. A freshly launched device, or one being restored during a move, is the prime moment to be targeted.

The attacker plants, inside the backup, something that points at a forbidden location starting with "/" (an absolute path), and writes a file anywhere on the device. What should only ever land in the designated backup folder can now escape that limit — the core of both flaws. Because the write location is attacker-chosen, overwriting a config or script that runs at startup leads to code execution, i.e. takeover.

The damage isn't limited to "losing control of your appliances." Home Assistant ties into door locks, security cameras, indoor sensors, and lighting — things that touch daily life directly. A takeover can mean spying on camera feeds, locking or unlocking doors, and pivoting to the PCs and phones on the same home network. On root-running installs in particular, the whole device can be fully commandeered. That is why the version check and update below should be done promptly.

What happens (the mechanism)

Both are "path traversal (directory traversal)" flaws. Path traversal is a technique where an attacker slips "move up a level" trickery into the part that specifies where a file is saved, forcing reads or writes in places that should be off-limits.

Home Assistant has a backup feature that saves and restores your whole configuration. Inside a backup is a management file called backup.json that summarizes its contents. If an absolute path is written into that file's "name" field, the handling ignores the intended backup-folder limit and puts files straight at the specified location. The result is an arbitrary file write anywhere on the device's filesystem. That is CVE-2026-64825, and its fix shipped in 2026.6.0.

On the easy-to-use "Home Assistant OS" and "Supervised" formats, and on the official Docker image, the software runs with administrator (root) privileges. Being able to write anywhere as root means overwriting critical system files or planting a script that runs at startup — which leads all the way to full control of the device. No login is required, and the abuse of a legitimate "restore from backup" action is what makes these flaws so difficult.

The second hole, CVE-2026-64824 — still open in 2026.6.0

A backup feature splits roughly into two halves: the side that makes (saves) the backup and the side that restores (unpacks) it. Each half had its own hole. Only the first was closed in 2026.6.0. The second one — the restore side — is CVE-2026-64824, and its fix landed in 2026.7.0. Both were published on NVD on July 21, 2026, from the same assigner, at the same moment.

Here is how it works. A backup file is really a tar archive, and a tar archive can hold not just files but shortcuts to other locations (symbolic links). The attacker plants an entry (a tar SYMTYPE entry) whose link target is an absolute path. The restore routine unpacks without checking whether that shortcut is safe, so the file gets written through the shortcut, outside the backup folder. It is like a delivery that is only supposed to reach the front door arriving with its own secret passage to the back one.

This is where the root-running official Docker image matters. Python automatically loads a handful of files every time it starts. One of them is site-packages/sitecustomize.py; overwrite that, and the attacker's code runs the moment Home Assistant next starts. A file write turns into remote code execution. The severity is 9.3 (Critical) on CVSS 4.0, and 8.4 on the older CVSS 3.1.

The dividing line, checked against the source

We confirmed the split by reading the published source directly. The safety switch for unpacking a tar archive is Python's filter argument: fully_trusted means "trust everything inside and extract it as-is," while tar means "reject dangerous entries." In Home Assistant's homeassistant/backup_restore.py, that argument changes as follows.

The fixing commit is 1e457600f1093c15e1325742d03e2b76498c79c1 (PR #172252, merged May 27, 2026), and GitHub's branch comparison confirms it is contained in 2026.7.0 and absent from 2026.6.0. You can read the files yourself: the 2026.6.4 version next to the 2026.7.0 version. In short, as long as you stay on the 2026.6.x line, the restore path still trusts everything inside the archive.

Is my setup affected? (Quick reference)

Whether you're affected comes down to your Home Assistant version. Find it under Settings → System → General, or from the lower-left menu. Match it against the table below.

July 2026 shipped five releases: 7.0 on July 1, 7.1 on July 3, 7.2 on July 10, 7.3 on July 21, and 7.4 on July 24. The newest is 2026.7.4, but 7.4 itself carries no security fix — the dividing line is 2026.7.0. Any 7.0 or later has CVE-2026-64824 closed. Absent a reason to pin, take the newest 2026.7.4.

The riskiest cases are Home Assistant exposed directly to the internet, and instances about to be set up or restored to a new server. If yours is already configured and only reachable from your home network, the exploit window is narrow — but with a fix out, updating early is the safe move.

What to do right now

The fix is to update Home Assistant to 2026.7.0 or later (currently 2026.7.4). If there's an update notice in the admin, apply it there (official update guide). On "Home Assistant OS," check Settings → System → Updates for both the core and OS updates. On Docker, check that your image tag isn't still pinned to a 2026.6.x and re-pull. Afterward, confirm the version reads 2026.7.0 or later.

If you can't update immediately, or you're about to set up or restore, a solid stopgap is to not expose Home Assistant directly to the internet. If you need remote access, keep it behind a VPN or a trusted relay so the setup screen and restore feature can't be reached from outside. Since CVE-2026-64824 runs through the restore path, while you remain on 2026.6.x, not restoring any backup you did not create yourself is itself a defense.

Where the official advisory stands

As of this update, the vendor has not published its own security advisory. GitHub advisory IDs exist for both — GHSA-5hxg-r395-fqxx for CVE-2026-64825 and GHSA-cwh8-w64c-4j5h for CVE-2026-64824 — but both are marked "unreviewed," meaning they were ingested automatically from NVD. Neither appears on Home Assistant's security page nor in the core repository's advisory list. The accurate status: the IDs and the fixing commit are known, but no advisory from the developers has been issued. Which is precisely why checking your own version is worth the minute it takes.

Public sources show no report of real-world exploitation, no published proof-of-concept, and no listing on the U.S. CISA catalog of actively exploited vulnerabilities (KEV). Still, Home Assistant is widely used worldwide, and with the fixing commit public the technique is easy to infer. A third issue was disclosed the same day: cross-site scripting via async_get_media_image() in the Shelly integration (CVE-2026-64823, 4.7 on CVSS 3.1, affecting versions before 2026.5.4). Moving to 2026.7.0 or later clears that one too.

FAQ

Summary

Home Assistant, the popular software for controlling home appliances and IoT devices, has two 9.3-rated flaws in its backup feature. CVE-2026-64825 sits on the "making a backup" side and CVE-2026-64824 on the "restoring" side; either lets a crafted backup write a file anywhere on the device and lead to takeover. No login is required, and impact is largest on root-running "Home Assistant OS" / "Supervised" installs and the official Docker image.

The split fix versions are the trap. 2026.6.0 settled only 64825; 64824 closed in 2026.7.0. In the source, the tar extraction argument reads fully_trusted through 2026.6.4 and tar from 2026.7.0. Update to 2026.7.0 or later (currently 2026.7.4). Also stick to the basics: don't expose Home Assistant directly to the internet, and don't restore backups of unknown origin.

Sources

• ▸ NVD - CVE-2026-64824 (backup restore path traversal / fixed in 2026.7.0)
• ▸ NVD - CVE-2026-64825 (Home Assistant Core path traversal / arbitrary file write)
• ▸ NVD - CVE-2026-64823 (cross-site scripting in the Shelly integration)
• ▸ GitHub - backup_restore.py at tag 2026.6.4 (filter="fully_trusted")
• ▸ GitHub - backup_restore.py at tag 2026.7.0 (filter="tar")
• ▸ GitHub - home-assistant/core PR #172252 (fixing commit 1e45760)
• ▸ GitHub Advisory - GHSA-cwh8-w64c-4j5h (CVE-2026-64824, unreviewed)
• ▸ GitHub Advisory - GHSA-5hxg-r395-fqxx (CVE-2026-64825, unreviewed)
• ▸ Home Assistant - Security page
• ▸ Home Assistant - Release notes (current 2026.7.4)
• ▸ Home Assistant official site
• ▸ Related: tracker of actively exploited vulnerabilities, CISA KEV (Japanese, this site)