Robot Cybersecurity: The Problem Nobody Budgeted For

In October 2024, a team of researchers at the University of Pennsylvania jailbroke a commercial robot dog and got it to do things its manufacturer’s guardrails were supposed to prevent. They published the method. Robot cybersecurity is the branch of engineering concerned with an attacker deliberately making a machine misbehave, and it is structurally different from robot safety, which assumes the machine is doing what it was told and asks whether that’s dangerous. Most robots sold today, including the ones showing up in schools and homes, were engineered for the second problem and not the first.

Key Takeaways

• Safety asks “what if the robot does its job near a person?” Security asks “what if someone else is giving the orders?” The engineering answers are different and the second one is newer.
• The strongest independently verifiable result is RoboPAIR (Robey et al., 2024): the team reported jailbreak attacks “often achieving 100% attack success rates” across three robot systems, including what they call the first successful jailbreak of a deployed commercial robotic system.
• A September 16, 2026 IEEE Spectrum piece organized the threat into three layers: corrupting the model, exploiting the system, and manipulating the robot at runtime. Note the provenance: that article is sponsored content from a security vendor, VicOne, so treat its urgency as interested and its cited research as checkable.
• The vulnerabilities are mundane engineering failures, not science fiction. Hardcoded cryptographic keys. Unauthenticated message topics. Bluetooth pairing with no real authentication.
• For a family, the actionable surface is small and boring: network segmentation, firmware updates, and knowing whether a remote human can take control.

Safety and security are two different standards

OSHA’s Technical Manual chapter on industrial robot systems defines the robot system as including “not only the industrial robot but also the end-effector attached to the robot manipulator; computers, processors, and programs (i.e., the control system); power sources; sensors; and, sequencing or monitoring communication interfaces.” Read that list again. Every item on it is an attack surface.

The industrial safety framework is mature. OSHA’s chapter names ANSI/RIA R15.06, ISO 10218-1 and ISO 10218-2, ISO/TS 15066, and a family of RIA technical reports, and it defines four safeguarding methods for collaborative work: safety-rated monitored stop, hand-guided control, speed and separation monitoring, and power and force limiting. Those methods are good engineering. They are also, with one exception, assumptions about what the robot’s own controller will do.

Power and force limiting is the exception, and it’s worth understanding why. A power-and-force-limited robot cannot hurt you much even if its software goes completely wrong, because the actuators physically can’t produce enough force. That’s a mechanical guarantee, which no software attack can remove. Speed and separation monitoring, by contrast, depends on a sensor and a controller behaving correctly, and both are software.

The lesson transfers directly: in robotics, security that lives in hardware survives attacks that security living in software does not.

What the attack research actually demonstrated

Here’s the layered picture, with the independently checkable work separated from the vendor framing.

Layer one: corrupt the model before it ships. The founding result here is BadNets (2017), which showed that a neural network can be trained with a hidden trigger (a specific sticker, say) that makes it misclassify on demand. The canonical demonstration was a stop sign read as a speed limit sign. More recent work extends this to robot policies specifically: BadVLA (NeurIPS 2025) targets vision-language-action models, and GoBA (2025) reportedly uses ordinary objects, including a coffee mug, as the trigger, with a reported 97 percent attack success rate.

Layer two: exploit the plumbing. UniPwn, disclosed in September 2025, is a Bluetooth exploit affecting quadruped and humanoid robots using hardcoded cryptographic keys, bypassing authentication and achieving root-level command injection. It was described as wormable, meaning a compromised robot could infect another. Separately, ROS 2 and its underlying DDS middleware have carried vulnerabilities permitting arbitrary code execution and unauthenticated abuse of message topics. ROS is the dominant software framework in robotics research and in a lot of products.

Layer three: manipulate the robot while it’s running. This is where RoboPAIR sits, and it’s the result I’d put most weight on because the paper is public and the method is specified. Alexander Robey, Zachary Ravichandran, Vijay Kumar, Hamed Hassani and George Pappas evaluated three systems: NVIDIA’s Dolphins self-driving LLM with white-box access, a Clearpath Robotics Jackal ground vehicle running a GPT-4o planner with gray-box access, and a Unitree Go2 robot dog with GPT-3.5 integration under black-box access. They report that RoboPAIR and several simpler baselines found jailbreaks “quickly and effectively, often achieving 100% attack success rates,” and describe the Go2 result as the first successful jailbreak of a deployed commercial robotic system.

Related runtime work in the same family: BadRobot, in which a robot verbally refuses an unsafe instruction while physically carrying it out; VLAttack, using adversarial patches to drive task success to zero; and FreezeVLA, where a single adversarial image locks the decision loop.

One honest caveat on the September 2026 IEEE Spectrum article that assembles this picture: it is sponsored content from VicOne, a vehicle-cybersecurity company, and it reports a 60-second exploitation demonstration in the company’s own lab. Vendor labs have an incentive to produce alarming numbers. The underlying academic citations are real and checkable, which is why I’ve named them individually rather than relying on the summary.

How to Teach Your Kid About Robot Cybersecurity

The concepts here are unusually teachable because they’re all about trust.

Ages 5–8: The secret-word game

Set up a rule: your kid only follows an instruction if you say a secret word first. Then have a sibling or other parent give instructions without the word. The kid has to refuse. That’s authentication, and a surprising number of real robots skip it. Then flip it: whisper the secret word loudly enough for the other person to hear. Now they can give orders too. That’s a hardcoded key.

Ages 9–12: Sticker attack on an image classifier

Use any free image-recognition app or website. Have your kid photograph an object and confirm the app identifies it. Then put a bright sticker or a piece of patterned tape on it and try again. Many classifiers break, visibly. They just reproduced the core idea behind BadNets and adversarial patches with a roll of washi tape. Ask what would happen if the object were a stop sign and the viewer were a car.

Ages 13+: Map a device’s attack surface

Pick one connected device at home: a smart speaker, a printer, a robot vacuum. Have them write down every way information gets in or out: Wi-Fi, Bluetooth, USB, a microphone, a camera, a cloud account, a phone app, a firmware update channel. Then, for each one, who’s allowed to use it and how the device checks. The output is a one-page threat model, which is a genuine professional artifact. If they want more, the RoboPAIR paper is readable by a motivated high-schooler.

The question to ask: “If a robot can’t tell the difference between you and a stranger giving it orders, what should it refuse to be able to do at all?”

Robot safety and robot security, side by side

	Safety engineering	Security engineering
Core assumption	The controller is working as designed	The controller may be under someone else’s control
Typical threat	A person enters the robot’s reach	An attacker injects commands or corrupts the model
Mature standards	ISO 10218-1/-2, ISO/TS 15066, ANSI/RIA R15.06	Thin for robots specifically; borrows from OT security
Main tools	Guarding, force limits, separation monitoring, e-stops	Authentication, signed firmware, segmentation, code review
Who certifies it	Established third-party process	Largely self-asserted
Survives a software compromise?	Only the mechanical measures do	Depends entirely on design
Where it’s weakest in 2026	Dynamically balancing legged robots	Consumer and education robots at low price points

The standards asymmetry in that table is the real story. Industrial robot safety has decades of codified practice. Robot-specific cybersecurity has almost none; practitioners borrow from operational technology security, like NIST’s Guide to Operational Technology (OT) Security (SP 800-82 Rev. 3, September 2023), which covers industrial control systems in depth but does not call out robots specifically. CISA’s Secure by Design guidance, published October 25, 2023 with 17 international partners, lays out three principles (“Take Ownership of Customer Security Outcomes,” “Embrace Radical Transparency and Accountability,” and “Lead From the Top”) that apply well to robot vendors and are, so far, voluntary.

What to actually do at home and at school

Put the robot on its own network

Most home routers support a guest network. A robot, a vacuum, a 3D printer and a smart TV belong on it; your laptop and your kid’s school account do not. This single step contains the damage from a compromised device and takes about ten minutes. It’s the highest-value step on this list.

Ask three questions before any robot enters a classroom

Does it receive signed firmware updates, and for how many years? Can a remote operator take manual control, and who is authorized? What data leaves the building, and where does it go? A vendor who can’t answer in writing has told you something. Schools negotiating device purchases have far more bargaining power here than families do, and should use it.

Treat voice and app control as an open door

If a robot accepts commands from a phone app with a shared household account, then anyone with the account can drive it. Kids share passwords; that’s a developmental reality, not a character flaw. Use separate accounts where the product allows, and assume a shared one is public.

Prefer robots that physically cannot do much harm

This is the parent-level version of power and force limiting. A small, low-torque educational robot that has been fully compromised is still a small, low-torque robot. A 60-kilogram machine with strong actuators is a different risk class regardless of its software. Weight and torque are specs you can read on a box; code quality isn’t.

What not to do

Don’t let this become a reason to avoid robots altogether. The research in this article exists because security researchers are doing their jobs: publishing attacks is how defenses get built, and the same pattern played out with cars, routers and medical devices. A kid who understands that attacks get published and then fixed has a more accurate model of technology than one who’s just been told robots are scary.

What to Watch For Over the Next 3 Months

• Week 4: Check whether any robot in your house or your kid’s school has a published firmware update policy with an end-of-support date. Most consumer robotics products don’t. Absence is the finding.
• Month 2 red flags: A robot product that pairs over Bluetooth with no PIN, exposes an open network port, or ships with a default password printed in the manual. Also: any vendor claiming its robot is “unhackable,” which is a phrase serious security engineers do not use.
• Month 3 self-check: Ask your kid to explain the difference between a robot that’s broken and a robot that’s been taken over. If they can describe how the two would look different from the outside, a broken robot fails randomly, a compromised one does something coherent that nobody asked for, they’ve understood the whole field.

Frequently Asked Questions

Has a home robot actually been hacked in the wild?

The published record is mostly research demonstrations rather than confirmed attacks on consumers. RoboPAIR’s Unitree Go2 jailbreak was performed by researchers on a commercially available product. UniPwn was disclosed as a vulnerability affecting shipped robots. Demonstrated vulnerability and documented in-the-wild exploitation are different things, and the honest position is that the first is established and the second is not well documented.

Should I avoid buying my kid a robot kit because of this?

No. An educational kit with a small motor and a microcontroller has a tiny harm ceiling regardless of its security. The concern scales with mass, torque, mobility and network exposure: a tabletop robot arm is a different conversation from a 50-kilogram humanoid. Our comparison of robotics kits and what they actually teach is a better guide to the purchase decision.

Why is ROS insecure if everyone uses it?

ROS was built as research software, where the threat model was “my own lab network.” Security was added later, which is almost always harder than designing it in. This is the same history as the early internet. ROS 2 improved substantially, but deployments often disable the security features because they add configuration work.

What does “wormable” mean?

That a compromised machine can automatically compromise others without a human involved. In the UniPwn disclosure, that meant one infected robot could reach another over Bluetooth. Wormable bugs matter disproportionately because the damage scales on its own.

Is a teleoperated robot more or less secure?

Different, not clearly better. Teleoperation means a trusted human is in the loop, which catches nonsense an autonomous policy might execute. It also means a live remote control channel exists, which is itself a target. The honest answer depends on how that channel is authenticated and encrypted. We cover what teleoperation means in practice in the human behind an “autonomous” home robot.

Is there a career in this for my kid?

Yes, and it’s an unusual one: it needs both embedded systems knowledge and security knowledge, and few people have both. The entry path runs through either side: learn microcontrollers and add security, or learn security and add hardware. Our breakdown of robotics engineer versus robotics technician covers the adjacent routes.

---

About the author

Ricky Flores is the founder of HiWave Makers and an electrical engineer with 15+ years of experience building consumer technology at Apple, Samsung, and Texas Instruments. He writes about how kids learn to build, think, and create in a tech-saturated world. Read more at hiwavemakers.com.

---

Sources

1. Robey, A., Ravichandran, Z., Kumar, V., Hassani, H., & Pappas, G. J. (2024). “Jailbreaking LLM-Controlled Robots.” https://arxiv.org/abs/2410.13691
2. VicOne (sponsored). (2026, September 16). “Rethinking Robot Safety in the Age of AI.” IEEE Spectrum. https://spectrum.ieee.org/physical-ai-robot-cybersecurity-vicone
3. Occupational Safety and Health Administration. “Industrial Robot Systems and Industrial Robot System Safety.” OSHA Technical Manual, Section 4, Chapter 4. https://www.osha.gov/otm/section-4-safety-hazards/chapter-4
4. Stouffer, K., Pease, M., Tang, C., Zimmerman, T., Pillitteri, V., Lightman, S., et al. (2023, September). Guide to Operational Technology (OT) Security. NIST Special Publication 800-82 Rev. 3. https://csrc.nist.gov/pubs/sp/800/82/r3/final
5. Cybersecurity and Infrastructure Security Agency. (2023, October 25). “Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design.” https://www.cisa.gov/resources-tools/resources/secure-by-design
6. Occupational Safety and Health Administration. “Robotics — Hazard Recognition.” https://www.osha.gov/robotics/hazards
7. Ackerman, E. (2026, September 15). “Digit 5 May Be the First Humanoid Robot Worker That’s Truly Safe.” IEEE Spectrum. https://spectrum.ieee.org/humanoid-robot-safety