On July 13, Shelly quietly started rolling out firmware 2.0.0 for its Gen2+ devices. Not 1.8, which is what everyone was expecting after 1.7.5 — a full major version jump, delivered in phases, which means your devices may not have seen it yet even if you’ve been mashing the update button. I noticed because one of my relays offered it to me last week, and I did what I always do before letting firmware touch anything wired into my walls: I read the changelog.
And the changelog is interesting, because the Security section at the top reads less like release notes and more like the findings summary of a penetration test report. Which, given the six months Shelly has had, is probably exactly what it is.
How we got here: the access point that wouldn’t die
Quick recap for anyone who missed the spring drama. In February, Pen Test Partners published a disclosure showing that Shelly’s Gen4 devices left their open setup access point running even after the device had joined your home network. Earlier generations disabled that AP automatically after commissioning; Gen4 didn’t. Anyone within Wi-Fi range could connect to it and fire a single unauthenticated HTTP request at the relay. When that relay drives a light, that’s a prank. When it drives a garage door — a use case Shelly actively markets — that’s a burglary tool. The researchers even showed you could geolocate thousands of default Shelly APs at scale through wigle.net, some with “Garage” helpfully in the network name.
The disclosure timeline stung too: reported in October 2025, published 125 days later after Shelly went quiet. Shelly’s first real answer shipped in March as firmware 1.7.5, which introduced secure provisioning — the open AP and BLE RPC now shut themselves off once the device is set up. That was the patch. Firmware 2.0.0 looks like the postmortem.
What 2.0.0 actually fixes
The headline items, straight from the changelog: an authentication bypass on the /ota endpoint after reboot has been fixed. Sit with that one for a second — the endpoint that accepts new firmware had a window after reboot where it didn’t properly check who was asking. There’s now brute-force protection on authentication, and nonce handling has been rewritten to be RFC 7616-compliant. RPC over Bluetooth now requires pairing instead of accepting commands from any phone in range. Encrypted BTHome sensor advertisements got replay-attack protection. And the secure provisioning flow from 1.7.5 has been extended to cover Matter and Zigbee commissioning, so the “open door during setup” problem is closed on every radio the device speaks, not just Wi-Fi.
There’s also proper TLS certificate date validation and an HTTP-to-HTTPS redirect when the new enhanced_security flag is enabled. Each of these is genuinely good news. Collectively, they’re also an inventory of what wasn’t there before — which is worth remembering next time a spec sheet tells you a device is secure.
The parts that can bite a Home Assistant setup
Big version numbers come with breaking changes, and this one has a few that matter if your Shellys talk to Home Assistant.
The one flagged as breaking: the global BLE enable flag is gone from the config. Scanning now activates and deactivates automatically. If you have scripts or automations that toggled ble.enable — I had one that switched Bluetooth off on relays I use as BLU gateways during backups — they’ll need attention.
Subtler: devices now report their configured name as their network hostname, falling back to the device ID only if no name is set. If anything in your setup keys on the old hostname — DHCP reservations by hostname, DNS entries, a monitoring dashboard — it may quietly break when the device re-registers under “kitchen-ceiling” instead of a MAC-derived ID. My reservations are by MAC address, so I escaped, but I know plenty of setups that aren’t.
On the pleasant side for MQTT users: the message queue got bumped to 30, and a long-standing bug where devices missed status updates after a reboot or power loss is fixed. If you’ve ever had a Shelly show a stale state in Home Assistant after a power cut — that one.
How I’m rolling it out
The rollout is phased, so patience is part of the plan whether you like it or not. Here’s my order of operations, documented honestly because I’ve botched fleet updates before.
First, one sacrificial device: the relay behind my office lamp, the least consequential Shelly I own. Update, then check three things — the integration reconnects in Home Assistant, the access point is off under Settings → Access Point, and authentication is enabled with an actual password. That last one is on you regardless of firmware version; the brute-force protection in 2.0.0 only helps if there’s a password to brute-force.
Then it sits for a week. Firmware that survives seven days of mundane toggling earns the right to touch the rest of the fleet, one device per evening, never the ones controlling anything I’d regret at 2 a.m. And if you’re still on an older version: go disable that default AP manually today. It’s two taps in the web UI, and it’s the single highest-value thing a Shelly owner can do while waiting for the phased rollout to arrive.
The local-first tradeoff, again
Every time I write about a security patch, someone points out that this is the cost of my no-cloud setup: nobody patches my house for me. True. But the Wemo shutdown taught us what the alternative costs — and my Shellys accepted this update relay by relay, on my schedule, verified by me, with no vendor account involved. That’s not a burden. That’s the arrangement working exactly as advertised. I just wish the changelog hadn’t needed to be this good.
Leave a Reply