Home Assistant Exposed for Unauthorized Scanning of User Passwords

First, fix the time. On October 16th (UTC), user Viss created an issue #49314 in the Home Assistant documentation repository. The title was “I never authorized a scan of my secret integrations,” referring to a feature in the system that would retrieve locally configured password-related fields from the database for online querying and leakage. The maintainer, frenck, first responded rudely, then closed the issue twice, with his attitude getting increasingly hard until he finally said, “Uninstall it if you want.” At 8:33 PM, this issue was posted on Hacker News, quickly rising to the top of the list. By the morning of October 17th, it had received over 150 upvotes and more than 100 comments, with the number still increasing. At 9:11 PM, which was 116 minutes after the first review, frenck posted a long apology on the top comment, admitting that his previous responses were too careless and providing a command to close the issue that had not been written into the documentation. The 48-hour window was from October 16th to October 18th, and this article falls within this window. The identities of Viss, frenck, and the other commentators who appear later in the text are either self-reported or identified by other users. When referring to their identities, specific details are provided; direct quotes can be used because both the issue and Hacker News are public records. All timestamps below come from issue #49314 and Hacker News.

What happened?

The “dispute function” itself is an old feature. According to what frenck disclosed in his apology post, this check has been available in Supervisor for many years. The logic is to scan the fields marked as passwords in the add-on configuration, perform a SHA-1 hash locally, and send only the first 5 characters of the hash result to the Have I Been Pwned (HIBP) password query service. HIBP then returns a list of hashes with the same prefix, and the final comparison is done locally. This mechanism is called K-anonymity: neither the original password nor the complete hash leaves the local device. 1Password, Chrome, and Firefox use the same scheme, and HA’s official documentation already explains this. More specifically, after calculating the SHA-1 locally, the first 5 hexadecimal characters, about 20 bits, are taken to query HIBP’s range API. HIBP returns all hashes under that prefix, usually hundreds of them, and the final full-value comparison is done locally. What HIBP receives is just a prefix; it cannot be inferred which password it is, nor which device it belongs to. From a cryptographic perspective, this function has no flaws, and the documentation also states this. The issue lies not with the mechanism.

The problem lies with the user experience. Viss saw the warning “scanning my secrets” for the first time in version 2026.10.1. He concluded that he had never given permission for this to happen. His request was to change the functionality to an opt-in model, where consent would be required before scanning. Why does the old function only now cause problems? Frenck explained in his apology post: The latest version fixed the bug that caused this warning to appear. It’s the first time old users have seen it.

Next is the upgrade chain from that evening, all with timestamps. At 19:15, frenck made his first comment, starting with “Oh hi there 👋”, and stated that “this is not an invasion of privacy”. He also cited 1Password as an example of other software doing the same, and included links to Cloudflare’s K-anonymity blog and Wikipedia. At the end, he added, “If you want to learn something from this output, remember that the secrets you’re using are already in a leaked database, and can easily be used by others.” At 19:48, Viss responded by introducing himself, saying he ran Phobos Group, gave security lectures regularly, knew Troy, the author of HIBP, and had deployed 1Password on Twitter as the only red team member in 2011 (all of this was his own statement, not independently verified). His core argument remained unchanged: this should have been an opt-in feature, not something that happened “just like that”. As a red team member, he could list many ways to abuse this channel to extract credentials from every HA installed worldwide. At 19:56, frenck left a comment saying, “This issue is closed as it can’t be fixed. Sorry.” The issue was closed.

2:20 PM: Old user 0x00string requested a reopening, stating, “If you don’t handle this reasonably, just say so, and we’ll uninstall and start over.” 2:14 PM: Frenck sent a second closure message, claiming that the other party was “threatening and intimidating,” and said, “If this is enough for you to uninstall and fork… 🤷 Then go ahead. After all, this is open-source software.” 2:33 PM: The issue was posted on HN. 9:11 PM: Frenck’s pinned apology comment appeared, with the command ha security options --pwned=false given, and he acknowledged that the option had always existed, saying, “It turns out that this check can already be turned off.” The issue is now closed, and Frenck has pinned it at the top of the repository.

Main criticism: The mechanism is fine, but the governance is problematic

The first main point is authorization. The function is enabled by default, and the trigger is the fields marked as “password” in all add-on configurations. Users may not be clear about which configurations fall into this category. Although the data flow only includes hash prefixes, it ultimately goes to third-party services. The warning messages did not appear before this version update. Default opt-out, no prompts, and third-party data flow—these three factors combined are what Viss really complains about. The theoretical attack surface he identified also lies at this level: according to his issue, malicious actors who can access the HA repository could theoretically exploit this mechanism. This is the theoretical attack surface pointed out by the issue author; it’s not a confirmed vulnerability, so it’s not discussed in this article.

The second main reason for closing it is self-contradictory. An issue should be opened in the documentation repository, because the switch isn’t documented in the documents. It’s perfectly reasonable to bring it up in the repository. The commenter mcmcmc pointed out this flaw: there was already an option to close this feature, but it wasn’t documented. So, the repository is exactly the right place to open an issue. However, the maintainer closes it under the pretext that “this is a repository; changing the documentation won’t solve the functional issue.” This logic doesn’t hold up.

The third main point is that the way of responding shifted the focus of the discussion. Viss’s argument was that it was a governance mistake, but Frenck’s first review used 1Password as an analogy, turning the topic into “others also do this.” The sarcastic comment from HN’s highly praised reviewer, jackpepsi, is very representative: “You might think this unwelcome scanning is an insult, but we can prove mathematically that we didn’t insult you.” Technically correct and procedurally unauthorized are two different things; the first review only addressed the former.

Speech and Behavior Audit: Four Facets in 116 Minutes

Arranging the words from that evening in order creates ready-made audit material for speech and actions. At 19:15, “This is not an invasion of privacy,” with a link to self-prove. At 19:56, “won’t fix, sorry,” and the issue was closed. At 20:14, “Threats and intimidation are useless” and “Uninstall the fork if you want; it’s open-source anyway.” It was closed again. At 21:11, “My previous response was even more disrespectful than what this deserves; I apologize.” The switch was handed over, the disclosure mechanism was revealed, the reasons for the outbreak were explained, and a source code link was provided (this comment was truncated on the page, and the exact path of the source code hasn’t been fully verified in this article, so it won’t be specified). Only 116 minutes separated these four different personas, and only one thing happened in between: HN fermented for 38 minutes.

The apology response is indeed worth noting, as it provides a lot of additional information: details about the mechanism, the reasons for the outbreak, and the command to close it. These were not included in the previous two responses. In other words, things that users wanted to know clearly in the first round were actually answered by the maintainers, but they chose to close the issue first.

Old issues have also been brought up again. Commenters HN janice1999 and someguydave pointed out that Frenck had the same attitude of “change it if you want, open source it if you like” in the NixOS nixpkgs PR #126326 years ago. They considered this to be his usual communication style. According to the rules, these are accusations made by netizens, and this article records them without making any conclusions. Another commenter, hypfer, believes that bringing up old issues is bad faith, and this is also recorded.

Also, there’s GDPR-related concerns. Commenter Rygian believes that this integration might be illegal under GDPR, on the grounds that “PII is collected without a legitimate basis.” However, others like deadbunny, Matticus_Rex, and nicce argue that only the hash prefixes are sent, and thus they don’t constitute PII. Both sides have valid points, so this isn’t a definitive conclusion.

What does the comment section say?

Among the over a hundred comments, besides the several groups mentioned above, there are also several voices worth recording.

Constructive comparison: Some netizens have identified HA founder balloob as being involved. They said this feature has been available for five years and provided a document link to it. csoghoian, who claims to be a privacy expert, suggested that instead of creating this feature, it would be better to add passkey support. He mentioned that users have been asking for this for a long time and even submitted patches, but they were rejected. Neither of these identities has been independently verified; the information is based on what the netizens reported.

The cost of trust is particularly noticeable. Commenters onionisafruit and fg137 both mentioned that they were about to purchase HA Green hardware, but this decision caused them to hesitate. They emphasized that what made them hesitant wasn’t the fact that hash values were provided to haveibeenpwned, but rather the responses they received on GitHub regarding this matter. The communication style of an open-source project directly led to hesitation in placing an order for hardware. This is the most concrete manifestation of the community’s cost of trust.

The opposing views also need to be taken into consideration. Commenter ragall believes that the developers’ responses are very reasonable and restrained, while the users are rather rude. altairprime sympathizes with the maintainers, saying “Resolute software creators are becoming less popular amidst a chorus of self-righteous opposition.” These opinions contradict the main argument, but they are real parts of this debate, so they will not be edited in this article.

Ordinary users can do three things

First, for those using HA and not wanting to be detected, simply turn it off. The command is ha security options --pwned=false, which comes from the maintainer’s pinned apology post. Its reliability is undisputed. This also explains something else: this option wasn’t previously included in the documentation. The fact that you can’t find it doesn’t mean it doesn’t exist.

Secondly, take this opportunity to review your password configurations. Although this warning is intimidating, it also does a useful thing: it checks all the fields marked as “password” in your add-ons through HIBP. Leaving aside the tone of Frenck’s initial comment, the content is correct. Any passwords that appear in the leaked database should be changed. Replacing weak passwords is more practical than arguing about whether you should do so or not.

Third, consider the response of the maintainers as a signal for choosing the right project. In this case, what really made users hesitant was the process of having issues be closed in a stubborn manner after two rounds of feedback. When evaluating any open-source project where you need to trust it with family data, look at how and what words are used to close issues. The underlying governance culture is more honest than what’s stated in the README.

Conclusion

Moderation Statement: This post does not incriminate any party. The identities of Viss, balloob, and csoghoian are self-reported or identified by netizens. The text is limited in scope; frenck responds as a Member, which can be considered an official response. Theoretical attacks are summarized according to the author’s perspective, without acknowledging existing flaws. The claim about GDPR violations is a speculation from the comments section, presented both for and against. The source code path in the apology comment was not fully verified due to page truncation and is not specified permanently. Old issues with NixOS are recorded based on netizen reports. Verified facts include: issue #49314’s full timestamp, four key quotes, the shutdown command, K-anonymity mechanism and official documentation, and HN dissemination data (a snapshot from October 17th morning with over 150 support votes) all originating from GitHub issues and HN sources. Two points to watch out for: first, whether HA officially adds instructions on how to shut down the system to prevent future users from having to read the issue to know their rights; second, whether the functionality should be changed to opt-in as requested by Viss, or at least provide guidance on shutdown in the warning message. If either happens, v2 will be released.

Reference source

• GitHub issue #49314 (home-assistant/home-assistant.io): Original source. All timestamps and exact quotes from the source are provided. Started on 2026-10-16, final status: Closed. frenck has been pinned.

• HN story 50124251: Submitted at 20:33 UTC on 10-16. Snapshot taken at 10-17 morning with score 155▲/104💬. The text states “Over 150 support votes, still increasing.” Comments from mcmcmc/jackpepsi/Rygian/deadbunny/Matticus_Rex/nicce/onionisafruit/fg137/balloob/csoghoian/ragall/altairprime/janice1999/someguydave/hypfer are all self-descriptions by the commenters. The text is attributed to each individual commenter.

• HA official documentation on more-info/pwned-passwords page: Official description of the K-anonymity mechanism, with full verification.

• Cloudflare blog validating-leaked-passwords-with-k-anonymity: frenck’s first review self-references, proving that this mechanism is widely used in the industry.

• frenck’s pinned apology comment: In the issue, at 21:11 UTC on 2026-10-16, the command to close and the source of the mechanism are disclosed. Comments are truncated on the page, and the source code link path is not fully verified.