Root shell on a Samsung TV: what it has to do with Bun

There's a screenshot going around of a terminal with # in the prompt, and the device on the other end is a television. The original post shows a root shell on a Samsung TV. In other words, full access to the operating system of the TV in your living room. Not the Netflix app or the settings menu. It's the Linux sitting underneath all of that, with permission to touch anything.

As soon as I saw it, I thought two things. The first was: "this is a huge security problem". The second, like every JavaScript dev with a problem: "does it run Bun?"

I'll talk about both.

What having a root shell on a Samsung TV means

Samsung TVs run Tizen, a Linux-based system. On top of it sits the interface you know, the app store and Samsung's own services. Underneath there's a kernel, processes, a file system and networking, like on any server.

A regular shell already lets you run commands. A root shell lets you run any command, as the most powerful user on the system. In practice, whoever has this access can:

• read and change system files, including the ones the manufacturer protects;
• see what goes through the TV's network;
• install and run binaries that never went through the official store;
• leave a process running in the background forever.

I won't get into how the access was obtained. First, because the technical details belong to the author and anyone interested should read them at the source. Second, because a step-by-step exploit guide is not what this blog does. What interests me is what this shows to people who write software.

Why this matters if you're not a security researcher

You probably won't jailbreak your TV tonight. Even so, this news is about your work.

A smart TV is a Linux computer that's on 24 hours a day, connected to your home network, with a microphone on some models and updates controlled by a company that will stop supporting it in a few years. Now think about how many of these exist on the same network as your work laptop.

Every "smart" device is a Linux server you don't manage.

That's the uncomfortable part. On your server you control the kernel version, the open ports and the installed packages. On the TV you control nothing. You trust that the manufacturer did it right and will keep doing it right. When a public root shell shows up, that trust takes a punch.

For developers, there are three lessons:

1. The local network is not a safe zone. If your development API listens on 0.0.0.0 without authentication "because it's only on my network", any compromised device on that network can call it.
2. Old firmware is someone else's technical debt landing in your lap. The same goes for the Docker image you haven't updated since 2023.
3. Automatic updates are a security feature. Hating updates that restart your TV is normal. Turning updates off is worse.

The first point is the easiest to fix today. In Bun, for example:

Bun.serve({
  hostname: "127.0.0.1", // only your machine can see it
  port: 3000,
  fetch: () => new Response("ok"),
});

One line changes who can talk to your server.

And where Bun fits into this story

Now the fun part. Imagine the TV is yours, the access is yours and you want to run your own code on it. A home dashboard, a bot that turns off the TV after midnight, a server that exposes metrics. Anything.

The classic path would be compiling C for the TV's architecture. It works, but it's a hassle: cross toolchain, libraries, linking. For people who live in TypeScript, Bun offers a really interesting shortcut: bun build --compile.

This command takes your code, bundles it with the Bun runtime and produces a single executable. No node_modules, nothing to install on the target. And you can build that binary for another architecture straight from your laptop:

bun build ./tv.ts --compile --target=bun-linux-arm64 --outfile tv-server

Then you just copy the file and run it. No npm install on a device with little space and no package manager.

The tv.ts can be very simple:

import { cpus, freemem, uptime } from "node:os";

Bun.serve({
  hostname: "127.0.0.1",
  port: 8080,
  fetch() {
    return Response.json({
      cpus: cpus().length,
      freeMB: Math.round(freemem() / 1024 / 1024),
      uptimeH: Math.round(uptime() / 3600),
    });
  },
});

Since Bun implements a good part of the Node APIs, the node:os, node:fs and node:child_process modules work the way you expect. You write the same TypeScript as always and run it on a device that, ten minutes ago, was just a screen.

The real limits (before you try)

Here comes the honest part, because the nice screenshot hides the boring details.

Architecture. Bun builds binaries for Linux x64 and arm64, with glibc and musl variants. It has no official support for 32-bit ARM. Many TVs have a 64-bit ARM processor but run the system in 32 bits, and then the binary simply won't execute. Before anything else, run this in the TV's shell:

uname -m

If you see aarch64, there's a chance. If you see armv7l, forget Bun and go with C, Go or Rust.

Size. An executable compiled with Bun easily goes past 50 MB, because the whole runtime goes with it. On your SSD that's nothing. On a TV with tight internal storage and read-only partitions, it can be the end of the road. A Go binary would do the same job at a fraction of that.

Memory. JavaScriptCore is efficient, but it isn't magic. A TV already uses a good chunk of its RAM to decode video. Your little server will compete for memory with the player, and the system may kill the process when things get tight.

Persistence. A root shell doesn't guarantee your process survives a reboot or an update. Often the next firmware update closes the hole and wipes what you installed. In other words, the access lasts until Samsung ships a patch.

My strong opinion here: Bun on a TV is a great experiment and a terrible architecture. For weekend hacking, the speed of going from "I have an idea" to "it's running" is unbeatable. For something that needs to stay up for months on a limited device, a language that produces a small native binary is the right choice.

What to do if you got curious

If the news made you want to tinker, a few simple rules:

• Only on your own device. Accessing someone else's device without authorization is a crime, not research.
• Wait for the warranty to expire, or accept losing it. Rooting usually voids the warranty, and the manufacturer won't take pity on you.
• Never expose what you run to the internet. A rooted TV with a port open to the outside becomes the easiest device to break into in your home.
• Read the original source and watch whether Samsung responds with a patch. This kind of discovery usually follows a cycle: disclosure, fix, and then the full technical details.

If you don't want to touch anything, the useful action is different: check that your TV has automatic updates turned on. It's boring, but it's the only defense you have on a device you don't manage.

My take

What strikes me most in this story is how the gap between "appliance" and "server" has disappeared. Your TV, your fridge and your router run the same software base as the servers you deploy to. And the same TypeScript you write for an API can, with one command, become an executable inside one of them.

That is powerful and scary in equal measure. For developers, the practical lesson is to treat the local network with the same distrust as the internet, and to remember that tools like Bun made it very easy to take code to places where only C used to go. Use that to build cool things on hardware that's yours.

I already have an old TV stored away waiting for a free weekend. If it turns into a project, it'll show up along with the others.

I saw a root shell running on a Samsung TV and my first reaction was: does it run Bun?

The second was more serious. Every smart TV is a Linux server running 24/7 on your network, and you are not the one managing it.

That is why your dev API listening on 0.0.0.0 "because it's just my home network" is a real risk. One line with hostname 127.0.0.1 fixes it.

And yes, you can take TypeScript there with bun build --compile. It works well as a weekend experiment, but as architecture it's terrible: a 50 MB binary, RAM shared with the video player and no 32-bit ARM.

I wrote about the real limits and what this story teaches developers. The link is in the comments.

#Bun #TypeScript #CyberSecurity #IoT #Linux