Because there was none. This is pro-active mitigation.
I realise English is not your first language but read the announcement again. There is no suggestion that anything bad has happened, just that they (the devs) recognise the possibility it could happen and are reacting to that.
Think of it this way:
Your chicken coup has holes. We want to patch them before the varmints get in. They ain’t got in yet but we see where they could.
Thanks! I did understand but see I didnt write it down properly. I corrected my sentence. Much appreciated. 
I disagree.
There is no way the Hass Team could know if the security hole has been used until now.
So it is not correct to say it has not happened in the exact same way as it is not correct to say it is happened.
I understand that the Hass developers cannot ans should not vet and check custom components.
However what should be done is a better management fo custom components.
By better I mean : some restrictions on capabilities / accesses available to custom components.
I am thinking about a special user to run custom components which is more controlled / walled
I am not knowledgeable enough to understand if this is feasible but something shall be done.
I suggest that maybe next what the heck may be dedicated to security and privacy…
Is there a log entry that will indicate if I’ve been compromised?
Yes, your stuff may turn on and off randomly, a-la Mr-Robot style.
If you want to discuss UI or update thingies, please create a separate topic. Let’s keep things nice and on topic so everybody can benefit from the actual issue presented in this thread.
Thanks 
FYI: The Security Bulletin https://alerts.home-assistant.io/#security_bulletin.markdown has a broken link https://alerts.home-assistant.io/docs/installation/updating/ .
There are a number of custom components offering integrations with banks, energy providers, crypto currency wallets, etc.
If a malicious actor wanted to, those integrations could be exploited to intentionally request (the user to enter), then exfiltrate those credentials allowing financial fraud (among other abuse).
Put aside whether you think it’s a good idea to link those services into a home automation platform, let alone use a custom component to do it (because if you think that’s a bad bad idea, I agree, but we’re not “everyone”).
So no, there are plenty of other potential attacks possible other than just turning your house into a haunted mansion.
(I’m not insinuating that any known component (custom or otherwise) does this, or that that this remediation covers that potential abuse. I’m just highlighting that the risk is potentially worse than just uncooperative home lighting)
I mean I agree it probably is, but has this been officially confirmed anywhere or is this just hypothetical ?
Communicating security breaches is tricky, especially in open source. So I think we should indeed cut the devs some slack here and see how this unfolds. But transparency in communication is key. Commercial actors always get slammed (and rightfully so) for being opaque around security incidents. And lack of transparency will inevitably open the door to conspiracy theories, as clearly demonstrated by the current worldwide situation. That said, I’m sure that the devs will give us an updated situation when they sorted out things internally.
Read this:
Any estimate to when more details will be available, so that I don’t have to keep checking the blog post?
maybe I missed it in the heated discussion above , but, now we are all on the necessary version, is the idea of this restricted custom components access, part of the future core HA design?
I’m pretty sure they’ll accept PRs improving on that, without restricting functionality.
Note that you need card-mod for that. Also, instead of using rest sensors, you might be able to use the updater or version integrations.
If you want to understand the specific attack that is the focus of this security bulletin, you only need to look at the “filter” patch to HA Core (linked above). This is not about a component intentionally sending data to an outside entity. This is about a component that might, unintentionally, fail to properly sanitize API requests coming in to HA Core allowing someone to access information which was not the intent of the component. Input sanitization is complex because it has many dimensions and some are not obvious to casual developers. This is open source so the only guarantee you have is if you, yourself study the code and make or suggest improvements to the API security model through PRs. You are deluding yourself if you think you can demand anything of open source developers. Suggest, yes; beg, yes; demand, well YMMV.
For all those that thought this was about components sending out data; I am amused at how many of you don’t seem to grasp that literally every single component in HA that communicates with an outside service is leaking information. If you don’t like that and want to prevent the leak then you need to put every IOT device, including HA, on a separate WiFi with no Internet access.
I’ll illustrate my point with a simple example that probably applies to every person on this thread. When you installed HA did you give it accurate location information? e.g. did you give it the actual GPS coordinates of your house? Well then the default weather component (met.no) or any other weather component you’ve enabled is “leaking” your exact location and the fact that you are running HA. Even if the first thing you did after you started HA for the first time was to disable met.no; there is a good chance that it sent your location to met.no at least one time.
Another example that has nothing to do with HA: If you have a recent roomba model with mapping and you let it on your WiFi with Internet access; then the roobma is leaking a floor plan of your house and could be leaking the contents of your house too. It has object detection and could report all the objects it recognizes; even people.
Disconnecting these things from the Internet or otherwise blocking the information “leak” greatly diminishes their value. So before you get out the pitchforks demanding changes, you need to think about the ramifications of what you are asking.
Last a bit of advice. You should not give HA access to any data that you consider sensitive. Anyone giving HA credentials to their financial institution is just, IMO, crazy. This really applies to every IOT device on the market; none of them are secure enough.
This is an interesting case study in how decisions made months, even years prior can have lasting effects down the road. When I started using Home Assistant, I opted for the ‘Venv on a VM’ route because, for me, it was far more powerful and reliable than Hassio on a Raspberry Pi with an SD Card. Here we are, years later, and Supervised HA now meets my standards for use while the venv languishes behind, mainly because upgrading is very, very manual. (I’ve lost track of how many times I’ve broken my venv because python wasn’t upgraded correctly.)
But I digress… I still expect the devs to tell us which custom components they’ve identified as suspect so that we may take appropriate action. Updating HA isn’t the only way to address this problem, especially if the problem exists because of a custom component written by an unscrupulous programmer.
A cynic may suggest that tinging this update with a security colouring encourages updating