Disclosure: security vulnerabilities in custom integrations HACS, Dwains Dashboard, Font Awesome and others

This is a disclosure about security vulnerabilities found in 3rd party custom integrations. Custom integrations are not created and/or maintained by Home Assistant. Users install them at their own risk. We want to inform you about these because the found vulnerabilities impact the security of your Home Assistant instance.

If you do not use custom integrations, your Home Assistant is not vulnerable. If you do use custom integrations, your instance might be vulnerable if you use one of the impacted integrations.

Read the blog post here: https://www.home-assistant.io/blog/2021/01/22/security-disclosure/


Really impressed with the way this has been handled, especially giving users clear paths to mitigate the vulnerability without advertising it to potential bad actors. Great work from everyone involved.


Thank you for your professional response to this.

For some reason the lists of vulnerable / previously vulnerable custom integrations are not showing up in my browser. Could be a firefox extension thing my end. Either way I can see the lists in the original blog post linked in small text at the end of the post.

EDIT: Ha. Well that’s one way of fixing it :slight_smile:


It’s not an extension thing, same thing is happening here. Was just typing a similar post when yours appeared.


I’ve flagged this to the Powers That Be


Also for those wondering:

Is more commonly known as BWAlarm (ak74 edition).

EDIT: the powers that be have updated this.

1 Like

Will there release technical information so that future custom developer will not make same mistake ?

I believe changes have already been made to HA to close this vulnerability already, hence the push to get everyone to update their installation. If a new component is developed against the current HA codebase, it’s already going to avoid this vulnerability.

Great writeup, glad to see the info!

allowing an attacker to access any file that is accessible by the Home Assistant process.

So this means that if I’ve got HA running in docker, any file in a volume I’ve got mounted to that docker container correct?

That is correct.

While updating the credentials for my user accounts a thought occurred to me. What about the system accounts that I have no control over?

Have they been altered with the patch or is it not possible to authenticate from external sources with them?

1 Like

If it’s something that can be ‘relatively’ easily explained, purely out of curiosity, how would this have happened? IE how would the vulnerability have been exploited?

That is to say that as far as I know I can only access hacs from my interface when it is logged in, but the vulnerability appeared to be able to utilise an ‘unauthenticated webview’.

I don’t understand how homeassistant and custom components speak to each other, so maybe it’s obvious to some, but if anyone can give us a clue in 5 paragraphs or fewer just to satisfy my curiosity I’d appreciate it.

If it’s way too complicated for a simple explanation, that’s fine too :see_no_evil:

You just need to install one of the custom integration and have that loaded, and you are affected.


I’m sorry for probably a dumb question:
Exactly what credentials do I need to change:
A) credentials from the users that I’ve created in home-assistant
B) credentials that are stored in configuration.yaml, and probably any credential that I’ve entered in the integrations
C) any more??

We recommend changing any credential or value you consider secret. That includes A & B.


I understand that I would be affected if I loaded one of the vulnerable components, I was asking how someone would have actually used that to attack my instance.

I’m only asking for layman’s terms, not actual hacking instructions, I’m just curious and would like to understand it a bit better.

My confusion mainly being with the concept of an unauthenticated webview being able to access the system via one of these components.

These custom integrations create an unauthenticated endpoint for serving files to the frontend. They should only serve their own static files.

1 Like

Some custom components send files and/or data from the backend (server) to the frontend (browser) because they need this to work as advertised.
The attack consists in tricking the component to send data they are not meant to send.


Is there any additional information available about the URL of the webview? I’d like to look through my proxy’s access logs to see if my HACS install was taken advantage of. Even something as simple as just “grep for [this]” would be great, if there’s anything specific enough.

Ah, OK. That makes sense. Thanks.

(and thanks @thomasloven for the extra, which also makes it clearer as to the process)