When Your Smart Home Gets Hacked Through a Lightbulb Name

Picture this: you're sitting comfortably at home, and someone halfway across the city just gained complete access to your smart locks, security cameras, and every connected device in your house. No phishing. No malware. No brute force. Just by picking a creative name for their radio node.

This isn't science fiction. This is exactly what security researcher Sasha demonstrated with a vulnerability in MeshCore, an open-source mesh networking protocol that runs over LoRa radio—the same long-range, low-power wireless technology many IoT devices use for communication.

The Setup: How Your "Smart" Home Became Vulnerable

Home Assistant is the darling of the home automation world. It's powerful, flexible, and runs everything from your thermostat to your automated coffee maker. To visualize all this connected goodness, users install cards on their dashboards—components that display device status and controls.

One such component, designed to show MeshCore network status, had a critical flaw: it rendered device names directly into the web interface without sanitization. In web security terms, this is a classic cross-site scripting (XSS) vulnerability—specifically, stored XSS, where the malicious code lives permanently in the system until cleaned up.

Here's what made this particularly concerning: the attacker didn't need to be in the same room. LoRa radios can reach several kilometers, and MeshCore uses repeater nodes to relay signals further. In the Netherlands alone, there are nearly 1,800 repeaters stretching across the country. The attacker just needed to reach any node in the mesh—anywhere in that network—and their malicious advertisement would propagate to every Home Assistant instance viewing the compromised dashboard.

The Attack Mechanics

The vulnerability lived in how MeshCore advertisement packets handle device names. Each packet contains an adv_name field—a 32-byte string where any node can set any value they want. The protocol itself doesn't validate or restrict what characters can appear in that name.

When Home Assistant displayed its mesh networking card, it would render every device name in the contact list directly into the HTML of the dashboard. No encoding. No escaping. Just raw text dumped into the page structure.

The attack payload was elegantly simple: a tracking pixel injected via an image tag. At just 23 bytes, it fit comfortably within the 32-byte limit. This tiny payload demonstrated that arbitrary HTML could be injected—and with it, any JavaScript the attacker wanted to execute.

But here's where it gets interesting. The researcher had to get creative to deliver a full JavaScript payload within severe size constraints. Their solution used three separate broadcasts that, when rendered together, opened an iframe, loaded the malicious script, and closed the iframe—each piece fitting within the character limits. The iframe's srcdoc attribute created a fresh document context where the code executed with full access to the Home Assistant frontend.

The impact? Full compromise. With typical Home Assistant OS settings, an attacker gaining access through an add-on could control everything the system touches—lights, locks, cameras, sensors, the works.

Why This Matters Beyond This Specific Bug

This disclosure teaches several crucial lessons that resonate far beyond LoRa networks and Home Assistant:

Trust nothing from the network. Any data arriving from external sources—whether it's a device name over radio, a username from a database, or user-generated content in an application—must be treated as potentially malicious until proven otherwise. The MeshCore protocol itself was fine; the flaw was in how applications rendered its output.

Context matters for security. The same payload technique wouldn't work everywhere. When the card rendered into a shadow DOM (a contained sub-document within the web component), the researcher had to adapt their approach because the DOM shortcuts they'd relied on didn't work across the shadow boundary.

Long-range doesn't mean safe. We often assume wireless attacks require proximity. LoRa's kilometers-long range, combined with mesh networking's relay architecture, turns that assumption on its head. An attacker can be geographically distant yet still reach your devices through the network.

What Got Patched (and What Didn't)

The affected component received a fix relatively quickly once responsibly disclosed. The maintainer pushed an update that properly sanitizes device names before rendering them in the dashboard.

However, a related project—the MeshCore-Home-Assistant-Panel-v2—remained unpatched at publication time. The researcher noted multiple attempts to contact the maintainer since March went unanswered.

This is a sobering reminder: the security of your stack often depends on third-party maintainers who may not have the resources or responsiveness you need. Regularly auditing your add-ons and understanding their maintenance status is part of responsible IoT deployment.

Protecting Your Own Projects

How can developers avoid similar pitfalls?

First, always sanitize output. Any time you display data that originated from external sources—whether from a network, database, or user input—apply appropriate encoding for the context. HTML output needs HTML encoding. URL parameters need URL encoding. The specifics matter.

Second, implement Content Security Policy (CSP) headers. CSP can significantly limit the damage from XSS vulnerabilities by restricting what scripts can execute and where they can load resources from. It's not a silver bullet, but it's a strong defense layer.

Third, assume compromise. Design your systems as if an attacker could execute arbitrary JavaScript in your application's context. This means minimizing privilege, using HTTP-only cookies where appropriate, and implementing proper CORS policies.

Fourth, keep dependencies updated and monitor for vulnerabilities. The open-source ecosystem's strength is also its Achilles heel—thousands of packages, many with varying maintenance quality. Tools like Dependabot, Snyk, and GitHub's vulnerability alerts help, but they don't replace active maintenance.

The Bigger Picture

As our homes and businesses fill with increasingly connected devices, the attack surface expands in ways we're still understanding. A temperature sensor in a greenhouse, a soil moisture monitor in a garden, a parking spot sensor in a lot—these all become potential vectors when they're networked together.

The security community's work in finding and responsibly disclosing these vulnerabilities makes our connected world incrementally safer. But it's a collective effort. Whether you're building IoT devices, writing software for home automation, or just running a smart home setup, understanding these risks helps everyone make better decisions.

Your smart home should make life more convenient, not more dangerous. Stay vigilant, keep systems updated, and remember: sometimes the most innocuous feature—a device name, a username field, a display string—is exactly where attackers look for an opening.