On Sunday night Gamers Nexus published a 135-minute investigation titled 216,000,000 Spy TVs, produced with Level1Techs and a group of independent security researchers. By Monday morning it was top of Hacker News. Wireshark captures taken from retail OLED sets, including the G5, show the televisions continuously sweeping the local network, enumerating phones and smartwatches, and collecting internal IP addresses alongside the names and signal strengths of neighbouring Wi-Fi networks. The researchers also recorded microphone audio captured while the screen appeared to be off, buffered locally when the Ethernet cable was pulled, and uploaded once connectivity returned.
The privacy story writes itself. The engineering story is the one worth your time: a consumer appliance with no legitimate business on your network mapped it successfully, because almost nothing on a local network is built to refuse.
TL;DR
- Researchers found LG TVs scanning the local network and reporting the results to LG Ad Solutions, which claims access to 363 million “secondary addressable devices” in the US alone.
- That number is not built from televisions. It is built from everything else on the network that answers an unauthenticated scan, including devices your team shipped.
- Browsers reached this conclusion first. Chrome 142 put local network requests behind a permission prompt in late 2025, and Chrome 147 extended it to WebSockets and WebTransport.
- The enterprise escape hatch,
LocalNetworkAccessRestrictionsTemporaryOptOut, is removed in Chrome 156, which reaches early stable on 7 October 2026. - If your product talks to a printer, a router, a POS terminal or
localhost, you have four weeks to annotate those calls properly rather than discover them through a support ticket.
What the researchers actually found
Three separate behaviours were documented, and they are worth keeping apart because they carry different weight.
The first is Automated Content Recognition, which fingerprints on-screen audio and video to log what is being watched across every input. ACR is old news and, in most markets, buried in a consent screen somebody clicked through during setup.
The second is the microphone capture in standby, with store-and-forward behaviour when the network was unavailable. That is the finding that will drive the headlines, and rightly so.
The third is the one nobody is discussing, and it is the one that concerns anybody who builds software. The sets actively enumerate the local network: other devices, internal addressing, surrounding wireless environment. That data feeds an advertising business. LG says it has sold roughly 216 million televisions worldwide; its advertising arm claims reach into 363 million secondary devices in the United States alone. The multiplier is not an accident. It is the product. The researchers additionally reported remote code execution vulnerabilities in webOS currently working through responsible disclosure, and LG had not commented publicly at the time of writing.
The local network is now a join key
A television cannot identify your phone by scanning it. What it can do is observe that a device with a particular MAC prefix, hostname and open port profile shares a network with a known TV serial number, and hand that correlation to an advertising graph that already holds identifiers from a dozen other sources. Household resolution is the whole game, and the local network is the cheapest join key available.
Which means the interesting question is not what LG collects. It is what your estate volunteers. Most networks we audit are full of things that answer strangers politely: an internal dashboard on 192.168.x.x with no authentication because “it is only on the LAN”, a NAS admin panel on a default port, a printer advertising itself over mDNS with a firmware version in the service record, a development server bound to 0.0.0.0 instead of 127.0.0.1, an IoT bridge exposing an unauthenticated REST API because pairing was considered sufficient.
Every one of those is a record in somebody’s inventory. We made the same argument about firmware in our piece on the supply chain blind spot below the operating system: the boundary your security model assumes is rarely the boundary that exists.
Browsers already made this call
While the industry has been arguing about cookies, the browser vendors quietly demolished the idea that the LAN is a safe place to be reachable.
Chrome 142 shipped Local Network Access restrictions in late October 2025. Any request from a public website to a local or loopback address now requires an explicit user permission, granted per origin and restricted to secure contexts. The stated goals are blunt: stop cross-site request forgery against routers and local devices, and stop sites fingerprinting the network. It replaced Private Network Access, the earlier design that asked local devices to opt in via CORS preflights, which was put on hold because devices that need protecting are precisely the devices that never get updated.
What counts as local is defined by address space rather than intent: RFC1918 ranges such as 192.168.0.0/16, link-local 169.254.0.0/16, IPv6 unique local fc00::/7 and link-local fe80::/10, plus loopback at 127.0.0.0/8 and ::1/128.
The releases since have tightened it steadily. Chrome 145 split the single permission into local-network and loopback-network, so a site that only needs to reach an agent on localhost no longer asks for the whole subnet. Chrome 146 added enterprise policies for pre-granting and pre-denying. Chrome 147 extended the restrictions to WebSocket and WebTransport connections, which is where a lot of local device integrations actually live. Firefox has shipped its own local network permission. Safari has published no position, which is its own kind of answer.
The date is 7 October
There is one detail that turns this from background reading into a task with a deadline. Chrome shipped an enterprise policy, LocalNetworkAccessRestrictionsTemporaryOptOut, so managed fleets could defer the restrictions while internal tooling was fixed. That policy is removed in Chrome 156, which reaches early stable on 7 October 2026. Stable today is 152.
If a client’s IT team set that policy, nothing in their environment has been failing, and nobody has been counting down. The deferral is not a configuration, it is a countdown that expires in about four weeks, and the systems it has been protecting are the ones least likely to have an owner: hardware setup wizards, local print and scan bridges, POS and payment terminal integrations, digital signage configuration panels, camera and access control consoles, companion desktop agents, and any OAuth flow with a localhost callback.
What to do about it
Six things, in the order we work through them with clients.
Inventory before you annotate. Grep your front end for private IP literals, .local hostnames and localhost ports. Anything that reaches a device rather than a server is in scope, including code you inherited.
Annotate the calls you keep. Chrome exempts permission-gated local requests from mixed content checks when it can tell in advance the destination is local: a private IP literal, a .local hostname, or an explicit annotation.
fetch("http://example.com/ping", { targetAddressSpace: "local" });Trigger the prompt from a document. Local network requests from service workers and shared workers require that the origin already holds the permission, so a background sync that quietly stopped working will not produce a prompt to explain itself. Request it from a page, at a moment the user understands, with your own copy setting up the ask.
Retire “internal, therefore trusted”. If a service on the LAN has no authentication because of where it sits, it has no authentication. Bind development servers to loopback, put real credentials on internal dashboards, and treat mDNS advertisements as public statements, because that is what they are.
Segment consumer and vendor hardware. Televisions, signage players and smart devices belong on a separate VLAN with no route to anything that matters. This is unglamorous work and it is the single highest-value hour in the list.
Write down what your own product does on the network. If you ship a kiosk, an appliance, a signage player or an on-premise deployment, its network behaviour is a documented product characteristic, not an implementation detail. Under the Cyber Resilience Act, whose reporting obligations start this week, a product with digital elements that scans a customer network by default is a design decision you will eventually explain to somebody with statutory powers.
The uncomfortable part
None of the LG behaviour required an exploit. It required a network full of devices that answer questions, and an industry that spent twenty years treating the perimeter as the only place worth defending. The televisions are a symptom. Browsers have already adjusted, on a published schedule, with a hard date attached. Most product teams have not looked.
If you are not sure what your application does on a customer’s local network, or you have an appliance or kiosk product with no answer to that question, that is exactly the kind of audit we do. Get in touch and we will scope it before the browser scopes it for you.
📷 Photo by Scott Rodgerson on Unsplash
