Supervisor 2026.10.3 changes the default of a feature many Home Assistant users only noticed last week: the check that compares app passwords with the Have I Been Pwned (HIBP) breach database. It now stays off unless you turn it on. The release reached the beta channel on 19 October 2026 at 21:43 Polish time. When we checked later that evening, the stable channel still offered Supervisor 2026.10.2, so most installations will get the change once it is promoted. The Supervisor updates itself when that happens.

Why the check became opt-in

The Supervisor looks at app options marked as passwords. It hashes each one locally with SHA-1 and sends only the first five characters of the hash to HIBP. HIBP returns every hash with that prefix, and the comparison happens on your own machine. The check is years old, but a recent release fixed the warning that reports its results, so many people saw it for the first time.

On 16 October a user opened issue #49314 in the documentation repository: they had never agreed to have their secrets checked by an outside service and wanted to know how to turn it off. Franck Nijhof (frenck) first closed it as "won't fix", then apologised for his replies, pointed out that ha security options --pwned=false already switches the check off and promised to update the documentation.

Pull request #7382 by jasonmp85, merged on 19 October at 17:21, sets the pwned option to false by default. Its description accepts that k-anonymity protects the secrets, but says the check still sends data derived from them to a third party without the user's consent. Installations that never touched the setting get the new default and stop checking. If you changed the option yourself, your saved value stays. To keep the check running, opt in:

ha security options --pwned=true

On the evening of 19 October the documentation page on pwned secrets still said that the check is on by default.

Forged identity headers in ingress

The second change matters if you use apps that sign you in through ingress. Before forwarding a request, the ingress proxy removes any X-Remote-User-Id, X-Remote-User-Name and X-Remote-User-Display-Name headers sent by the browser, so an app can trust these headers as the Supervisor's statement about who is logged in. The filter compared header names case-sensitively, though. A client that sent x-remote-user-id in lower case got its own value through, next to the real one. According to pull request #7377 by Stefan Agner (agners), an app that relies on these headers for single sign-on could be made to treat a logged-in non-admin user as any other Home Assistant user. Header names are now compared in lower case, and the Supervisor sets its own identity headers last. The release notes list this among the bug fixes, without a CVE number.

Other fixes in 2026.10.3

  • Backup names with control characters, including a trailing newline, are rejected. Downloads keep names with spaces, semicolons or non-ASCII characters intact.
  • An app that checks Home Assistant logins no longer rejects the first sign-in with a new password because of a stale cache entry.
  • Restoring a backup with the wrong password reports an invalid backup instead of a generic error and leaves the current configuration untouched.
  • Journal logs show timestamps in the system time zone instead of UTC. The release notes mark this as a breaking change. Home Assistant Core 2026.11 will also add the UTC offset to its own log lines (core #186660).