The Robot on Your Floor Might Be Listening — and It Can Be Hijacked

Aug 5
4 min read

Zac Bogart

President, Productive Robotics

Automation is supposed to make your shop safer and more productive. But a decade of security research on collaborative robots has surfaced an uncomfortable truth: some of the most widely deployed cobots on factory floors can be hacked over the network — and once they're compromised, the very safety features meant to protect your people can be switched off remotely.

If you run welding cells, machine tending, or any application where a person works within arm's reach of a robot, this is worth your attention.

What the researchers actually found

Security firms have been probing popular collaborative robot platforms since at least 2017, and the findings have been consistent and serious.

In one landmark study, researchers at IOActive documented nearly 50 vulnerabilities across a leading line of cobots. The headline result: by chaining a handful of flaws, an attacker on the network could gain root-level control of the robot's controller and then rewrite the robot's safety configuration — disabling emergency stops, defeating safety sensors, and overriding the force and speed limits that keep the arm from hurting a nearby worker. In their demonstration they modified the robot's safety settings and moved the joints remotely, with the operator none the wiser.

The physical stakes are not abstract. The researchers noted that even a mid-size cobot, running at reduced speed, can generate enough force to fracture a human skull. Strip away the safety limits and a machine designed to work safely beside people becomes an uncontrolled hazard.

The problem hasn't stayed in 2017. In May 2026, a critical new flaw (CVE-2026-8153, rated 9.8 out of 10 on the CVSS severity scale) was disclosed in the control software of a major cobot family. It's an OS command-injection bug in the robot's "dashboard" network service: an unauthenticated attacker with network access can send crafted commands that execute directly on the robot's operating system — full remote code execution, no password required. Both CISA and the manufacturer issued advisories, and a patch was released.

Why "it's not connected to the internet" isn't the reassurance you think

The common defense is that these robots aren't meant to be exposed to the public internet — and that's true. But as the researcher who reported the 2026 flaw pointed out, industrial networks are often flat: once an attacker gets a foothold anywhere on the plant network — a phishing email, an infected laptop, a poorly secured vendor connection, a compromised IoT sensor — they can often reach the robot controllers directly, because nothing inside the network is segmented off from anything else.

And a single compromise rarely stays single. A successful attack on one controller can cascade to an entire fleet of robots and the peripherals wired to them.

The pattern that should concern you

Read across a decade of this research and a pattern emerges: weak or missing authentication on control interfaces, unencrypted communications, and safety configuration files protected only by reversible checksums that an attacker can forge. In several cases the safety system — the part that's supposed to be the last line of defense — was itself the thing that got rewritten.

This matters because cobot safety is marketed as a hardware property ("it's inherently safe, it stops when it touches you"). In reality, those force limits, speed caps, and stop functions are enforced in software. And software can be attacked.

What to do about it

You don't need to be a security engineer to lower your risk. A few practical steps:

Patch, and know your version. If your robots run vendor software with a published advisory, apply the update. Ask your integrator which firmware/software version you're on and whether it's current.
Segment your network. Don't let robot controllers sit on the same flat network as email, office PCs, and guest Wi-Fi. Put automation equipment on its own isolated VLAN with a firewall between it and everything else. This single step defeats most remote attacks.
Lock down the control ports. The dashboard and control interfaces should never be reachable from the general network — let alone the internet. Restrict access to a short list of known machines.
Change defaults and limit remote access. Disable services you don't use. Treat any remote-access or vendor-support connection as a door that must be locked when not in use.
Ask the vendor hard questions. How is the control interface authenticated? Is communication encrypted? How are safety configuration files protected against tampering? How quickly are security patches issued when a flaw is found, and how are you notified?

A track record worth asking about

Security is also a matter of engineering discipline and design choices, and not every platform carries the same history. To date, no security vulnerabilities have been found or publicly disclosed in Productive Robotics' OB7 cobots — no CVEs, no security advisories, and no reported exploits. The OB7 has never been the subject of the kind of remote-hijacking research described above. When you're putting a robot next to your people, that clean record is exactly the kind of question worth asking about any machine you're considering.

Bottom line:

A collaborative robot is a networked computer that can move heavy metal fast enough to injure or kill. Treat it like the critical, attackable system it is — not like an appliance. The manufacturers that take this seriously will answer security questions directly, ship patches promptly, and design their safety systems to resist tampering. The ones that don't are asking you to bet your people's safety on the hope that no one on your network is paying attention.

Ask the questions before you buy, and secure the robots you already own.