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

I discovered the update incidentally when surfing the Supervisor.

While it is shown there, the binary_sensor.updater still reports

release_notes: ''
newest_version: 2021.1.4

As we all learned how (time) critical updates are and my notification automations rely on this sensor amongst others, I was wondering

  1. what triggers the binary_sensor.updater sensor to become aware of a newer version
  2. what the “security update” notification/information introduced recently would look like and if it should´ve been triggered for 2021.1.4 users when 2021.1.5 became available
  3. on a long-term if there´re plans to provide update notifications by default (ship with HA Core)

I spent many hours to create such on my own… because “security is number 1 priority” :slight_smile:

For screenshots and update notifications for other components I can recommend having a look at @CentralCommand´s great work in this topic:

Paulus, very well handled a difficult situation. As others have commented, this type of thing happens but it is the response to the issue that is even more important. Thank you to you, the core team and the wider “senior” community members who I am sure are putting in hours way over and above you expected.

This has happened many services before and will again unfortunately. Your response to the issues has been an example to how others (and in many many cases much, much bigger organisations) should act in these situations

I got this security bulletin and updated to latest version a couple of days ago.
Working fine until now it kicked my out my app. After digging further, turns out the Nuba Casa account just pushed the update to me and killed the token as it didn’t recognise my update.

Signed out and back it, agreed the terms on NubaCasa and working again?

Kudos again devs!

Thanks for the transparency on this. I’m wondering if we should build an internal encrypted secrets section/vault that we could reference in our configurations…


I’d like to know the same.

Thank you for the immediate disclosure and patch. You’re handling this exactly the right way.

Signed up for Nabu Casa today (has been on my todo list for awhile) got an email alert with the security vulnerability same day and the instance was disconnected from the cloud due to the vulnerability. Pretty awesome - thanks HA devs, continuing to be all over it with this amazing platform!

1 Like

From a general perspective: yes, opening up HA to the internet e. g. by port forwardings and DynDNS greats a massively larger attack surface. That doesn´t mean the risk is guaranteed to be higher, but only remotely accessing HA by VPN hides it from the internet pretty much. Anyway,

  • updates
  • wise choice of installed components
  • enabled 2FA
  • rarely usage of long term access tokens
  • enabling Fail2Ban (http component)

are important anyway, doesn´t matter if HA is exposed to the internet or not.

But the core question is related to the attack channel and I´d also like to know if it affects every HA instance or only the ones sitting on the internet.

you may need to update again, this is a new vulnerability

Well done - a very clear, transparent and inclusive security response - thank you.

First, thank you for the prompt response,

I’ve already removed/changed everything in my config/secrets files, but this episode has made me realize that I have no idea how to effectively secure other integrations that connect to HA via api using the UI after a breach. For example, for my ecobee integration, do I need to delete it and start completely from scratch to obtain a new api key from ecobee? Is there a simpler way to do that from within HA? If so, would that be sufficient or do I need to also change my password on

I know the standard better-safe-than-sorry advice is “reset everything,” but I would appreciate some advice on how to deal with these kinds of integrations.

Maybe I’m missing a trick? (it is late here…)
When I pull the latest version for docker, I seem to be getting 2021.1.4 not 2021.1.5…

Just cleaned out my google developer api credentials and started over. Something I haven’t seen mentioned anywhere else: I had a few ssh command line sensors pulling temperatures off of my two main proxmox hosts (one of which runs my pfsense vm)…and those keys were in /config/.ssh! ugghhhhh

No more ssh sensors for me. I’m pulling my google calendar integration too. It’s just too risky.

Anyone that has updated to 2021.1.5 has these problems?

Nope. What does config checker say? Maybe Remove automations and add back one-by-one (reload automations between each addition and check log after each reload). Did you make any changes since last restart before updating?

1 Like

I have just found this on my log:
2021-01-24 08:31:37 ERROR (MainThread) [homeassistant.setup] Setup of automation is taking longer than 300 seconds. Startup will proceed without waiting any longer

Yes, I am trying to use a backup automations file, but of course I cannot reload automations from server config and neither restart HA. I am gonna try a hard reset powering off the current.

Can you restart from command line?
Hard reset should be avoided where you can

1 Like

Why not? Should be able to.

1 Like

Overall a quick response to threats is always welcome :+1:

I would’ve appreciated the hint that the vulnerability is mainly affecting installations exposed to the internet. The “internal threat” scenario of a bad actor within the network is probably not relevant for most users.

I wonder, however, whether sensitive data could just leaked by custom components / addons to the internet without breaching the network - much like with “hijacked” chrome extensions that turned bad after they switched ownership. Are there any restrictions or checks for trackers or otherwise outbound traffic? Is the scope of the data visible to a custom component limited at all?