LG·삼성 스마트 TV 절반에서 프록시 악용코드 발견

Everyone worries about the apps on their phone. Almost no one looks at the ones on their TV. We scanned 6,038 of them across LG and Samsung; 2,058 were selling your IP address. On screen, it's a relaxing fish tank. Or a clock. Or solitaire. Or puppies. Under the hood, it is a residential proxy : software that can send other people's internet traffic out through your living room. And we found it everywhere. Why TVs are different Smart TVs are almost ideal proxy hosts. They sit on the same home network as everything else, but they do not feel like computers, so people rarely audit them like computers. There is no battery drain to notice, no cellular bill to spike, no app switcher full of suspicious background activity. A TV can stay plugged in, signed in, and online for years while the user thinks of it as furniture. That changes the consent equation too. Most people do not have a working mental model for what it means to sell access to their residential IP address, no matter what device they are using. On a TV, the gap is even wider: a one-time prompt navigated with a remote can disappear into the setup flow, while the app keeps monetizing the connection long after anyone remembers what they accepted. How proxy SDKs end up in apps The answer is money. Ads need attention, but when you insert ads it degrades the user experience. These apps are designed for the opposite: a clock, a fish tank, a quiet screen that doesn’t bother you with constant ads. Add a proxy SDK and the app can keep looking calm while the TV's internet connection makes money in the background. What each SDK considers consent Below are what these companies consider consent for their proxy SDKs. They ask once, and then never again. The background clause is the part that matters: all three prompts say the proxy can keep running after the app is closed. The app goes away. The proxy does not. Some apps make the trade-off even more explicit. Pac-Man on Tizen frames Bright Data as the ad-free option: decline and you keep the ad-supported game, accept and the app gets to use the TV's connection for web indexing. That is a clean little monetization fork: watch ads or become part of the proxy network. Who is making these apps? This is not just a story about proxy companies convincing random app developers to embed a monetization SDK. In a lot of cases, the proxy company, or something wearing its name, appears to be the publisher too. Bright Data, Bright Data Ltd, and Bright SDK account for 367 proxy-flagged apps in the dataset. Honeygain UAB (subsidiary of Oxylabs) shows up as the publisher on another 16. That changes the shape of the problem. Some of these are not normal apps that happen to have a proxy SDK inside them. They look more like first-party proxy inventory: thin shovelware games, screensavers, and utility shells shipped at scale so the SDK has somewhere to run. The app is the wrapper. The residential IP is the product. The platform gap Other TV platforms have already drawn a line. Amazon makes it explicit: its Device and System Abuse Policy prohibits apps that facilitate proxy services for third parties. Roku has reportedly shut the door too: Lowpass, syndicated at The Verge, reported that Roku bars developers from using Bright SDK and similar proxy services, and that Roku apps using the SDK disappeared after the company was contacted. LG and Samsung have not drawn an equivalent public line. That is the gap these apps are living in. The same business model that Amazon bans and Roku reportedly blocks is still showing up at scale on webOS and Tizen. Why this is dangerous Once a TV app can act as a proxy, the risk is not limited to someone borrowing your public IP address. The app is running inside your home network. If the proxy provider decides to allow requests to private or local addresses, or if their filtering fails, that TV becomes a foothold for reaching things that were never meant to be exposed to the internet: router admin panels, NAS devices, printers, cameras, developer machines, and other apps listening on local ports. This is not theoretical. In January 2026, KrebsOnSecurity reported on Kimwolf , a botnet that abused residential proxy networks to tunnel back into the local networks behind proxy endpoints. The report describes attackers using proxy access not just for public-web traffic, but to reach devices on the same LAN as the proxy node and spread further from there. The SDKs make that boundary visible. The Bright Data sample ships with an explicit private/local blocklist: `127.0.0.0/8`, `10.0.0.0/8`, `172.16.0.0/12`, `169.254.0.0/16`, `192.168.0.0/16`, and `255.255.255.255`. That is good to see, but it also proves the point: the TV can make the connection; the boundary is the SDK's policy code. In the Massive sample, the proxy session parses a server-supplied `host:port` value and opens a `net.Socket` to it. In the Honeygain/Oxylabs sample, a server message with `messageType: "connect"` supplies `address.host` and `address.port`, and later chunk messages write bytes into that connection. In the local Massive and Honeygain/Oxylabs samples, we did not find a comparable private-range blocklist. That makes the provider's policy and enforcement the real boundary. The boundary is not technical; it is enforced by the proxy company's customer vetting, traffic filters, internal rules, and whatever platform review LG or Samsung choose to apply. Proxy providers can say the traffic is limited to approved public-web use cases, but the device owner has no practical way to verify that from the TV. If that boundary changes, breaks, or is abused, the same SDK that was framed as "web indexing" can become a cybercriminal's personal VPN connection into your home network. Methodology We did not rely on store descriptions or permission prompts. We downloaded the actual LG webOS and Samsung Tizen app packages, unpacked them, and scanned the files inside. The fingerprints looked for confirmed SDK artifacts: Bright Data `brd_api.js` and `brd_sdk` services, Massive clients and `.massivesdk` services, Honeygain/Oxylabs SDK files and service names, and related tokens or package names. Every app counted there had a confirmed proxy SDK fingerprint. Proxy Vendor Responses Prior to publication, Spur Intelligence Labs shared its findings with Bright Data, Massive, and Oxylabs and invited each company to comment. All three organizations responded. Their responses are summarized below. Bright Data "Consent separates a legitimate network from a nefarious one, and is provable across a tested framework that outlines transparent and compliant sourcing, vetting, governance, and accountability. Bright Data built this framework for consented networks that are intentionally discoverable and therefore accountable. Our practices are scrutinized by independent auditors and security companies. Use is only approved for legitimate and verified business, research, and journalistic purposes. Our intent is to protect our network, our customers, and the internet as a whole. We encourage the entire industry to follow.” Massive “We pride ourselves on being privacy- and security-focused from the consumer side. While it's true that the device owner has no practical way to verify this, that is in part by design: the endpoint is intended to have minimal impact and a minimal interface to the user, for their own peace of mind. We previously included sliding controls that let users enable additional resource utilization, but in practice these effectively performed a self-inflicted denial of service, which users then attributed to the product. So, for user safety and stability, participation is now a simple enable/disable choice. “Users of our network go through a Know Your Customer (KYC) process to validate that they have a legitimate business purpose. Technical controls are primarily server-side, as we do not perform man-in-the-middle traffic decryption or monitoring, which would