I tell myself I run a local-first house so I don’t have to think about other people’s servers. No cloud, no account I didn’t ask for, nothing phoning home at 3am. It’s a good philosophy, and most days it holds up. But “local” quietly turns into “trusted” in your head, and that’s the part that bit me. A couple of security write-ups landed in my feed recently, both about gear I actually run, and they nudged me into doing something I’d been avoiding: an honest security pass over my own setup. I found two things I’d been ignoring. Neither was difficult to fix. Both were embarrassing.
The Shelly that never stopped broadcasting
The first one came from a Pen Test Partners write-up published in February. The researcher — a self-described Shelly fan, which is the part that made me read it — noticed that his new fourth-generation Shelly 1 behaved differently from the older ones. Every Shelly starts life broadcasting its own open Wi-Fi access point so you can do the initial setup. On the Gen 1 through Gen 3 devices, that setup AP switches itself off once the device joins your network. On the Gen 4, it stays on. Permanently. The only hint is a small icon in the device’s status bar that’s very easy to miss.
That sounds minor until you think about what an open access point on a relay actually means. Anyone in wireless range can connect to it and talk to the device directly — no password, because the setup AP doesn’t have one. The write-up shows a single unauthenticated HTTP request flipping a relay. If that relay happens to be wired to a gate or a garage door — a use case Shelly actively markets — then “anyone within range can open it” stops being abstract. It gets worse: a compromised Gen 4 can be scripted to reach across to other Shellys on your network, most of which people never bother to password-protect because they assumed the network itself was the boundary. And because these APs all advertise SSIDs starting with “Shelly”, they’re trivially findable on Wi-Fi mapping sites like wigle.net — some of them helpfully named things like “Garage”.
Shelly told the researchers a fix would land in firmware 1.8.0 to close the AP outside the commissioning window, then reportedly went quiet on timing. As of the disclosure it was over 120 days since the first report. So this is the awkward bit: the patch may or may not be on your device yet, but the workaround is entirely in your hands and takes about thirty seconds.
The thirty-second fix
On each Gen 4 device, open its web interface or the Shelly app, go to Settings → Access Point, and toggle it off. Do this only after you’ve confirmed you can still reach the device over your normal Wi-Fi, otherwise you’ll lock yourself out of the management interface and have to power-cycle into setup mode again. While you’re in there, set a device password too. I went through every Shelly in the house, not just the Gen 4s, because it turned out I’d been relying on network segmentation to do a job that a five-character password should also have been doing. Two of mine still had the AP enabled. I’d installed them, seen them join the network, and never looked closer.
The thing that stuck with me is the researcher’s point that experienced users are more at risk here, not less. If you’ve set up a dozen older Shellys, you’ve never once had to disable the AP manually — so it’s the last thing you’d think to check on a new one. Familiarity is its own blind spot.
While I was at it: the ESPHome bug I’d skated past
The second one hits closer to the heart of how I build things. I run a fair amount of ESPHome — the little ESP32 Bluetooth proxy I wrote about a few days ago is one of several scattered around the house. Last year a vulnerability tracked as CVE-2025-57808 was reported by ESPHome’s own jesserockz against the framework’s built-in web server. The flaw is almost funny in how blunt it is: the HTTP Basic Auth check on the ESP-IDF platform would accept an empty Authorization header, or one that merely matched the prefix of the correct credential. In other words, the password check could be bypassed by sending no password at all.
The reason that matters more than a leaky relay is what it unlocks. Anyone on your local network could hit an affected device’s web server and, if over-the-air updates were enabled, push their own firmware to it. That’s not toggling a light — that’s replacing the entire brain of the device with something that survives a reboot and can pivot to whatever else it can reach. ESPHome shipped the fix in version 2025.8.1, so anyone who has updated in the last several months is already covered. But “I’ll update it later” is the natural state of a DIY sensor that’s been working fine for a year, and I had two devices that hadn’t been re-flashed since well before that release.
Patching is the easy part: bump ESPHome in the dashboard or with pip install --upgrade esphome, then recompile and flash each device. The more interesting question the bug raised for me was whether I even need the web_server: component on most of those nodes. For anything that only talks to Home Assistant over the native API, the answer is no — disabling it removes the attack surface entirely. So I went through my YAML and turned it off everywhere I wasn’t actively using it for debugging.
What “local-first” actually buys you
Here’s the uncomfortable thread connecting both of these. The cloud platforms I avoid have one genuine advantage: they push security updates automatically, whether you want them or not. My setup updates when I push the update. That control is the entire point — it’s why I run Home Assistant on bare metal and keep my data in my own house. But control and responsibility are the same coin. Nobody is going to silently patch my Shelly or my ESP32 at midnight. If I don’t do it, it doesn’t happen.
The other myth this punctured for me is that the local network is a safe boundary. Both of these attacks assume the adversary is already on your Wi-Fi or within radio range — and a lot of home setups, mine included, were implicitly treating “on the LAN” as “allowed to do anything”. It isn’t. A guest phone, a compromised smart TV, a kid’s laptop with something nasty on it — any of those is now inside your trust boundary. That’s the argument for putting your IoT gear on its own VLAN that I’d nodded along to for years and never fully acted on. I’m acting on it now.
The weekend audit checklist
If you want to do your own pass, here’s roughly what mine looked like, in order of how much it stung: check every Shelly for a still-enabled access point and disable it (Settings → Access Point), and set device passwords while you’re there. Update ESPHome to at least 2025.8.1 and re-flash anything that’s been sitting untouched, then strip the web_server: component from nodes that don’t need it. Confirm your Home Assistant and HAOS installs are current. And if your smart-home devices share a flat network with your laptops and NAS, start planning the VLAN split — it’s the single change that limits the blast radius of everything else.
None of this is glamorous, and none of it produces a satisfying dashboard tile at the end. But it’s the maintenance cost of the thing I keep telling people is better. Local-first genuinely is better — more private, more durable, more mine. It’s just not automatically safe. That part is still my job, and this weekend was overdue rent.
Sources: Pen Test Partners on the Shelly Gen 4 access point issue, and CVE-2025-57808 / the ESPHome 2025.8.1 release for the ESPHome authentication bypass.
Leave a Reply