Security Disclosure 2: vulnerabilities in custom integrations HACS, Font Awesome and others

This blog looks pretty much the same as the security disclosure of yesterday. However, it is a new disclosure, affecting a similar issue. We want to make sure the information is complete.

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:

Thanks for the quick actions and insightful blog posts. Quite often if a product has seen a security incident it’ll receive more attention from other security experts too, which leads to more vulnerabilities reported; so it isn’t worrying to see two security bulletins shortly after each other. Good to see the responsible disclosure process is being followed here. Thanks to all involved!


Just for my understanding
Would it be safer not to have external access to Home Assistant? Or even then it is possible to get the access to the file system

Don’t wait for the update to appear in your supervisor panel. Run this from the command line now:

ha core update --version=2021.1.5
1 Like

:warning: If you don’t see the update yet:

Go to the Supervisor panel -> System tab -> Hit reload on the Supervisor.

After that, the update will appear (might need to refresh the page in your browser).


HI. Thank you for the transparency! Much appreciated. In the category “dumb questions”; there is talk of “update your credentials”; is meant here the credentials for the custom integration (like HACS) or the main Home Assistant credentials?

The directory traversal attack allowed attackers to access your .storage folder or your secrets.yaml where all your credentials to external services like AWS, Spotify, Tradfri etc are stored. So you’d have to change all of them.

Thank you. Will do.

If you have used any of the custom integrations with a known vulnerability, we recommend that you update your credentials.

Custom components run under HA core. So the recommendation means ALL credentials visible to HA core docker instance? Including ssl folder?

Is the data in addons folder safe?

Could someone in the know please answer this too?

What accounts do you mean? (Asking because I’m wondering if I missed something.)

  • All HA user accounts changed
  • All refresh/long tokens deleted/regenerated
  • SSH keys regenerated
  • SSL keys regenerated (including Lutron)
  • All addon passwords changed
  • All API keys regenerated
  • All other credentials (email etc) in secrets.yaml changed
  • Companion Apps updated
  • HA updated (again)
  • All dashboard devices cache cleared
  • Nabu Casa password changed also just because

Sounds like a lot but took less than an hour. The one thing I haven’t changed was my Nest API. Still on the original integration and don’t want to mess with it.

And yes thanks for being on top of this devs - including the integration devs!

Can someone if possible shed some light on what is causing these vulnerabilities and what to look out for when using custom components?

I use a few custom components that are not very common and I would like to be able to know if they are safe. I guess the new core update has put firewalls in place so that the risk is less now but it still feels like I have no idea how to decide if I can trust a custom component or not. I can understand code pretty good so is there anything in particular to look out for?

Just to be sure…

If the only access to my HA instance from the outside is via Nabu Casa (or via an encrypted-key protected private VPN) then I should not have been prone to any attacks? Is that correct?

Under configuration/users there are numerous system generated users that are uneditable.


I’ve been through much bigger security issues at much bigger companies, and I would like to say that I thought this was handled well and with the right level of openness. If you’ve never had to be on the owner side of this kind of an issue, the sequencing of the patches and messaging may seem strange, but there are myriad of considerations to be balanced.

I’d like to add my thanks to the team for making HA awesome and a fantastic community!


Unfortunately these things happen. I would however like to take this opportunity to once again start the discussion about supporting reverse proxy authentication through nginx.
There have been many discussions on GitHub about this and the current status is that the development team does not feel they have to support nginx because a safe method of remote authentication is provided through nabu casa.
I disagree. A second layer of authentication could have prevented our instances from being exposed.
Home assistant is the only one of many applications I host that does not reside behind my nginx authentication wall. I have never felt comfortable about this and this feeling has only become worse now.

Please reconsider implementing support for nginx.

Edit: for clarification, nginx is supported but everything breaks when you add http Auth or x509 certificates.


If I did not use any of the integrations than am I safe from this attack? I still plan on changing all my passwords today just to be safe

I can do the following in an infinite loop without ever having to authenticate:

  1. Pick up a device or browser that has previously logged into my HA instance
  2. Navigate Configuration -> Users -> {me} -> Change Password
  3. Change password
  4. Continue navigating my HA system as normal on that device and all other devices/browsers

Shouldn’t I have to authenticate before 3 and again before 4? Is there a way to set things up so that either of those would be required? Without it, anyone who gained access to my system still has it even though I have a new password.

EDIT: I found the login session/refresh tokens under the profile for my user, and they can be deleted one-by-one. I presume this will fix the login before 4 if I delete all tokens.

  • Benjamin
1 Like

Ah, those system accounts. Honestly, I figured since they were system generated accounts the system would take care of them. It is a good question, now you’ve got me curious now also. Thanks for clarifying.

What I don’t understand is why it was fully disclosed to the public before it was checked to be fixed, ideally by the security researcher.