How I Found a New Vulnerability in a Popular Home Automation App

By: Oriel Goel - Cyber Security Analyst   |   Updated: 1/28/2021

In this article, I will detail how an attacker using a low-complexity exploit can enumerate and view files remotely on a popular home automation web-app. This can be performed without authentication by exploiting a new Directory-Traversal vulnerability I found (CVE-2021–3152).

The web-application I researched is called “Home Assistant”, which is an “Open-source home automation that puts local control and privacy first”. More specifically the popular custom integration in which I discovered the new vulnerability is called “Home Assistant Community Store”. HACS “is an integration that gives the user a powerful UI to handle downloads of custom integrations and plugins.

I would like to clarify that this vulnerability only affects users that have installed custom integrations in Home Assistant. But since it does not require a high skilled attacker or authentication to perform successfully, its damage potential is vast.

I started my enumeration by running the traffic of the web-app through Burp Suite proxy until I found an interesting folder named “hacsfiles” — which is created for the HACS custom integration mentioned above.

The folder associated with the HACS custom integration. (Burp Suite)

As an attacker attempting to view files remotely with no authentication, I attempted to fuzz GET requests with “WFUZZ” and with a well-known list of filenames called “raft-medium-files.txt”, but I found no interesting files (at first).

wfuzz -c — hc 401,403,404,500 -w ~/raft-medium-files.txt

Since enumerating files in the /hacsfiles folder was unsuccessful, I attempted to list files that are outside the said folder by changing my wordlist to a Directory Traversal wordlist from


$ wfuzz -c — hc 401,403,404,500 -w ./directoy-traversal-wordlist.txt

WFUZZ output

Gotcha! The site responded with “200 OK” code — which seems promising.

In order to view the contents of the file “/etc/passwd” (and not just know it’s accessible), we need to recreate the request from Wfuzz in Burp Suite and look at the response.

Image from Burp Suite showing the contents “/etc/passwd” file from the target.

From this point on we can enumerate and view every file located on the target with no authentication.

How many vulnerable devices are there in the wild?

Since users of Home Assistant want to control their smart home appliances remotely, a large majority of them perform port-forwarding and expose the HA web interface to the internet, and by doing so exposing themselves to this vulnerability. Due to this reason, I performed a simple search in and found over 39,000 devices that were accessible and possibly vulnerable to this new CVE.

According to HACS and Home Assistant Core developers, there are more vulnerable custom integrations other than HACS (which I tested), so there is a good chance that most of the devices found in this search are vulnerable.

What can be done to fix the issue?

While researching the cause of this vulnerability, I found a class in the HACS code called HacsFrontend(HomeAssistantView)” which is located in “config/custom_components/hacs/helpers/classes/”.

Code from HACS Custom Integration

By editing the “requires_auth” parameter to “True” I found that the vulnerability was not present anymore, but according to the HACS developer “The authentication needs to be disabled for this endpoint for it to work the way it needs to work since it’s used to serve custom cards and other files to Lovelace which cannot request files with authentication.” So, it’s not a proper fix for the issue, but a quick and dirty one for those of you willing to edit python files.

I highly recommend updating the HACS integration to the latest version from and also update Home Assistant Core since this is the ”cleaner” way to securing your Home Assistant instance.

Security Bulletin by Home Assistant Core disclosing this vulnerability:

Mitre CVE:

Special Thanks to my co-workers — Adir Halfon for helping with the initial part of testing, and to Anthony Levy for providing help regarding vulnerable devices in the wild.