Cybersecurity for robots: The threat landscape nobody is talking about

Six days before this article was written, CISA and Universal Robots published a joint advisory disclosing CVE-2026-8153 — a critical OS command injection vulnerability in UR’s PolyScope 5 robotic control system, rated CVSS 9.8 out of 10. The flaw allows an unauthenticated attacker with network access to the Dashboard Server port to execute arbitrary commands on the robot’s operating system. Remote code execution on an industrial cobot — no credentials required.

Universal Robots has patched the vulnerability in PolyScope 5.25.1. But patches require downtime, downtime requires scheduling, and scheduling depends on operations teams that have no dedicated security function. In the time it takes a typical manufacturing facility to assess, approve, and apply a robot controller patch, an attacker with knowledge of CVE-2026-8153 has a window measured in weeks to months. The average time to patch an OT vulnerability in manufacturing is 180 days.

The IFR named cybersecurity as one of its five top global robotics trends for 2026 — noting “a rise in hacking attempts targeting robot controllers and cloud platforms, enabling unauthorised access and potential system manipulation.” That framing is accurate but incomplete. The threat landscape for connected robot systems in 2026 includes not just controller compromise but AI model poisoning, sensor data exfiltration, adversarial perception attacks, and voice-controlled humanoid hijacking. Most of these are not theoretical research constructs — they have been demonstrated in real systems.

This article maps the complete threat landscape, documents the incidents and research that make each category real, and closes with the defensive architecture that responsible deployment requires.

Why Robot Cybersecurity Is Different From Every Other Security Problem

Every cybersecurity problem involves a tradeoff between the cost of a breach and the cost of prevention. For enterprise IT systems, the cost of a breach is typically financial and reputational — data loss, regulatory fines, business disruption. These are serious but rarely immediately physical.

“A robot cannot be considered safe if it is not secure.” That line — from ECCU’s 2026 cybersecurity in robotics analysis — captures the category distinction. A hacked robot is not just a data breach. It is a 50-kilogram machine that can move at speed in a space occupied by humans. A compromised industrial cobot operating at its maximum force limit alongside a worker is a safety incident, not an IT incident. A VLA model trained to behave incorrectly under specific trigger conditions is not just malware — it is a physical hazard with a delayed fuse.

The IFR identifies the core governance challenge: “deep learning models, which are often described as ‘black boxes,’ can produce results that are difficult or impossible to explain, even to their own developers.” For a text model, an unexplained output is a user experience problem. For a robot executing a motion plan based on that output, it is a potential collision. The opacity that makes AI systems powerful is the same property that makes AI-controlled robot security hardest to assure.

• 9.8  CVSS score — CVE-2026-8153 on Universal Robots PolyScope 5  — patched May 2026; unauthenticated remote code execution on robot controller
• 92.6%  of robot vulnerabilities are software-related  — ScienceDirect survey of 176 robot threats in vulnerability database
• 180 days  average OT vulnerability patch time in manufacturing  — 6x longer than IT — TerraZone, March 2026

The 2026 Robot Threat Landscape

The table below maps the eight primary attack categories targeting robotic systems in 2026 — with target, attack vector, consequence, and current activity status for each:

Sources: CISA / Universal Robots CVE-2026-8153, Interesting Engineering GEEKCon report, arXiv Unitree G1 cybersecurity study, arXiv VLA adversarial attack paper, ScienceDirect robot cybersecurity survey, ITECS Manufacturing Cybersecurity Guide 2026.

Threat 1: Robot Controller Compromise — The Most Immediate Risk

The Universal Robots PolyScope 5 vulnerability is the most recent and most clearly documented example of the controller compromise threat — but it is not the first, and it will not be the last. IOActive researchers identified more than 50 hackable vulnerabilities across six home and industrial robots in 2017, including Universal Robots and Rethink Robotics systems. In one demonstration, they gained access to a robot arm’s operating system and overwrote the file that maintains speed limits, force limits, and proximity response parameters — turning a safety-constrained industrial arm into a machine operating without its protective limits. In another, they demonstrated remote hijacking of an ABB IRB140 industrial arm.

In December 2025 at GEEKCon in Shanghai, Chinese security researchers demonstrated something more alarming: compromised humanoid and quadruped robots spreading attacks to other units. One compromised robot became the vector for compromising its peers — the robot equivalent of a worm. In an environment where a factory deploys 50 or 100 connected humanoid robots sharing a network, a single vulnerable endpoint is not a single machine problem.

The CVE-2026-8153 vulnerability pattern — unauthenticated command injection through an exposed network service — is exactly the class of vulnerability that results from OT systems being designed before network exposure was anticipated. PolyScope 5’s Dashboard Server was a local interface; when the robot was connected to an IT network for remote monitoring and orchestration, that interface became an internet-accessible attack surface. This is not a UR-specific failure. It is the structural consequence of connecting equipment designed for air-gapped operation to enterprise networks without security redesign.

Active vulnerability:  CVE-2026-8153 — CVSS 9.8 on Universal Robots PolyScope 5. Unauthenticated OS command injection via Dashboard Server. Affects PolyScope 5 before 5.25.1. Published May 2026. Patch available — check your deployed version immediately.

Threat 2: AI Model Poisoning — The Attack That Has No Analogue in Traditional Robotics

AI model poisoning is the threat category that has no equivalent in the security history of classical programmed robots — and it is the one receiving the least attention from the robotics security community. The attack premise: corrupt the training data that a VLA model learns from, embedding a backdoor that causes the robot to behave incorrectly under specific trigger conditions while performing normally in standard testing.

The research basis is well-established. Carnegie Mellon researchers demonstrated that mixing 0.1% malicious data into a training set is sufficient to produce backdoor behaviour in a language model — and that the poisoned model matches the performance of clean models on standard benchmarks, making the poisoning virtually undetectable through normal evaluation. A separate Nature Medicine study showed that 0.001% poisoning of medical training data produced harmful model behaviour. The implication for VLA training data: the Open X-Embodiment dataset (970,000 robot episodes across 22 embodiments) and similar large open training repositories are candidate targets.

For VLA models specifically, academic research published in late 2024 demonstrated adversarial patch attacks against OpenVLA — physical patches placed in the robot’s operating environment that cause the model to misidentify objects and execute incorrect manipulation trajectories. The study found that “OpenVLA exhibited almost no resistance to such attacks.” The attacker does not need to access the model weights, the training infrastructure, or the deployment network. They need to place a small physical patch — a sticker, a printed pattern, a modified object surface — within the robot’s camera view.

The supply chain dimension is equally concerning. Lakera’s 2026 data poisoning analysis documents backdoors planted in GitHub repositories that propagated through fine-tuned models — discovered months after deployment, activated by a specific phrase, and invisible on standard evaluation. In January 2025, researchers found a poisoned backdoor in DeepThink-R1 via contaminated GitHub repositories. For robot manufacturers fine-tuning open-source VLA models on custom deployment data, the security of that fine-tuning pipeline — and the provenance of the base model — is now a safety question, not just a quality question.

“A model trained to write secure code normally but to insert vulnerabilities when told the year is 2024 is a perfect metaphor for the robot security problem: the weapon is invisible until triggered.” — Anthropic Sleeper Agents research, adapted

Threat 3: The ROS Security Debt

The Robot Operating System (ROS) is the most widely used robot middleware in both research and industrial deployment. It is also a system that was never designed with security in mind — its architecture assumes a trusted network, which is the opposite of what a factory floor connected to an enterprise IT network provides.

A 2025 peer-reviewed study on the SlowROS attack demonstrated a novel slow denial-of-service attack against the ROS Master — the central coordination node that every ROS system depends on. Exploitation causes systemwide and potentially dangerous disruption of ROS operations. The attack exploits a fundamental architectural property of ROS (an excessively high idle connection timeout) rather than a patched software bug — meaning it cannot be closed by a software update without redesigning the ROS architecture.

Red-teaming research on ROS in industrial settings has demonstrated four attack classes: remote code execution on a ROS endpoint; disruption of the ROS computational graph; impersonation of a ROS control station through a person-in-the-middle attack; and using an unprotected robot endpoint to pivot into the broader ROS network. All four were achieved against a realistic industrial test environment using internationally recognised ICS cybersecurity standards as the reference architecture.

ROS 1 reached end-of-life (Noetic Ninjemys) in mid-2025. The successor, ROS 2, has significantly improved security — using the Data Distribution Service (DDS) standard with configurable authentication and encryption. But the transition from ROS 1 to ROS 2 is moving slowly due to the inertia of industrial equipment with long commissioning cycles. Many facilities that purchased ROS 1-based robots between 2018 and 2023 are operating systems that will not receive security updates, on networks that did not exist when those systems were designed.

Threat 4: Covert Data Exfiltration — What Your Robot Is Transmitting

In September 2025, cybersecurity researchers at the University of Nottingham published a technical study of the Unitree G1 humanoid robot — one of the most widely deployed commercial humanoid platforms globally — and documented 40+ active data streams being aggregated and transmitted to external servers without explicit user disclosure. The research found MQTT connections transmitting sensor fusion data at 1.03 Mbps and 0.39 Mbps to servers with IP addresses geolocating to Chinese cloud infrastructure. Data types included: robot joint positions, velocities and torques; camera frames; IMU data; battery status; and full environmental sensor streams.

The researchers wrote: “Given the covert nature of the robot data collection, we argue that the channels described above could be used to conduct surveillance on the robot’s surroundings, including audio, visual, and spatial data.” The data was transmitted using TLS 1.3 encryption — but the researchers intercepted the plaintext payload before encryption using an SSL_write probe, revealing the full scope of collection. The ota_boxed process managing over-the-air updates created a bidirectional channel for both surveillance and control.

The IFR’s January 2026 security trend explicitly flags this category: “concerns are mounting over the sensitive data robots collect — including video, audio, and sensor streams.” For a factory deploying humanoid robots from vendors whose data governance practices are unclear, the robot’s camera feed is a continuous industrial surveillance stream covering production processes, product designs, worker behaviour, and facility layouts. The competitive intelligence value of that data stream — to a competitor, to a state actor, or to a ransomware operator conducting reconnaissance — is substantial.

Supply chain intelligence risk:  A humanoid robot operating in an automotive or electronics factory observes production processes, assembly sequences, quality control methods, and facility layouts. If that robot’s sensor streams are transmitted to external servers without controls, the competitive intelligence exposure is equivalent to installing a network of cameras and microphones connected to an uncontrolled external destination.

Threat 5: Adversarial Perception — Attacking the Robot’s Eyes

The most conceptually novel threat category in 2026 requires no network access, no malware, and no software vulnerability. It requires a physical object placed within the robot’s field of view.

Adversarial perception attacks exploit the known vulnerabilities of neural network vision systems to cause systematic misclassification. A small adversarial patch — an image pattern imperceptible to humans as anomalous — causes a VLA model to misidentify the objects in its environment, producing incorrect motion plans that can result in dropped components, mis-assembled products, or collisions.

The model-agnostic adversarial attack paper (arXiv 2025) demonstrates this against OpenVLA controlling a 7-degree-of-freedom robotic arm: adversarial patches in the camera view caused the robot to execute incorrect manipulation trajectories. The study also demonstrates untargeted attacks — patches that cause general task failure without requiring the attacker to know the specific model or its parameters, making the attack practical for an adversary with physical access to the environment but no access to the robot’s software systems.

The Eva-VLA robustness evaluation (arXiv 2025) tested multiple leading VLA models — OpenVLA, UniVLA, π0.5 — under real-world physical variations and found “severe vulnerabilities across leading VLA models” under distribution shifts. Environmental conditions that a human worker handles without thought — altered lighting, an unusual object orientation, a minor change to a workpiece colour — can cause a VLA-equipped robot to fail in ways that a classically programmed robot, operating within its designed envelope, would not.

The Robot Security Defensive Architecture

Responsible defence against the 2026 robot threat landscape requires measures at four distinct layers. Each is necessary; none is sufficient alone.

Layer 1: Network Segmentation and Zero Trust at the Robot Controller

Every robot controller — whether a UR cobot, a FANUC CNC, or a humanoid running VLA inference — must be in a dedicated network segment with strict controls on which systems can initiate connections to it. The lesson from CVE-2026-8153 is that a Dashboard Server accessible from the enterprise network is an attack surface regardless of how good the robot’s other security controls are. IEC 62443 zone-and-conduit architecture applied to robot networks means the robot controller zone has a single controlled conduit to the orchestration layer, with protocol inspection, authentication, and logging on every connection.

Layer 2: AI Model Provenance and Integrity Verification

Every VLA model deployed to a production robot must have a documented provenance trail: training data sources, validation methodology, known failure modes, and an authenticated signature that can be verified at deployment time. Model updates pushed from cloud infrastructure to edge controllers must be cryptographically signed and integrity-verified before execution. NCSC’s guidance on adversarial attacks against machine learning recommends: document the training data, validate against adversarial scenarios before deployment, and monitor model behaviour for distributional shifts that might indicate backdoor activation. For VLA models specifically, adversarial robustness testing must include physical adversarial patches in the test environment — not just digital input perturbations.

Layer 3: Data Governance for Robot Sensor Streams

Every data stream leaving a robot — whether via OTA update channels, telemetry pipelines, or cloud analytics integrations — must be documented, audited, and controlled. The Unitree G1 research demonstrates that vendor-provided connectivity can be a surveillance channel operating outside the buyer’s awareness. Before deployment, operators should: audit all active network connections from the robot platform (using the same SSL inspection techniques the Unitree researchers used); review vendor data collection practices and contractual data governance terms; and implement egress filtering that blocks transmissions to undocumented destinations. For robots collecting audio and video data in industrial environments, GDPR and sectoral data protection obligations apply to worker biometric data regardless of whether the primary deployment purpose is industrial automation.

Layer 4: Incident Response Planning for Physical Systems

A robot security incident is a physical operations event, not an IT event. Incident response plans that isolate compromised endpoints and restore from backup are appropriate for file servers. A compromised robot in a production environment requires: immediate physical isolation (network disconnection and powered-down state); safety assessment of any actions taken while compromised; firmware rollback to a known-good baseline; and investigation of whether the compromise was used as a pivot point into broader OT networks. Resonance Security recommends building tabletop exercises that simulate robot ransomware and remote hijack scenarios specifically — not just generic IT incident response. The people who need to respond to a robot security incident are operations engineers, not SOC analysts. Both groups need to know their roles before the incident, not during it.

The 2026 Robot Security Checklist

Before deploying or expanding a connected robot fleet, manufacturers, integrators, and enterprise operators should be able to confirm the following:

1. Every robot controller is in a network segment with explicit inbound and outbound controls. No Dashboard Server, ROS Master, or management interface is accessible from the enterprise IT network without authentication and protocol restriction.
2. All deployed VLA and AI models have documented training data provenance and have been validated against adversarial patch attacks in the deployment environment, not just simulation benchmarks.
3. All network connections initiated by robot platforms have been audited. Data destinations are documented, contractually governed, and egress-filtered at the network boundary.
4. Robot controller patch management has an SLA shorter than 30 days for critical vulnerabilities — not 180 days. This requires a patching workflow that includes safety validation and minimal-downtime procedures.
5. ROS 1-based systems have a documented migration plan to ROS 2 or a compensating control that addresses the unauthenticated ROS Master vulnerability. ROS 1 is end-of-life — operating it on a production network requires a specific risk acceptance decision, not a default.
6. The incident response plan for a robot security event is documented, tested, and includes operations engineering personnel alongside security analysts. The plan includes physical isolation procedures, safety assessment protocols, and OT-side forensic capabilities.
7. Vendor contracts for cloud-connected robot platforms include explicit terms on data collection, data destination, retention, and deletion. The absence of those terms is itself a data governance gap.

The Bottom Line

The robot cybersecurity threat landscape in 2026 is active, documented, and underdiscussed relative to its consequence severity. CVE-2026-8153 is a 9.8-rated vulnerability on one of the world’s most deployed cobot platforms, patched last week. Chinese researchers demonstrated at a public competition that a compromised humanoid can propagate its compromise to fleet peers. A published academic study documented 40+ covert data streams from a widely deployed commercial humanoid. VLA models have been shown to have near-zero resistance to adversarial patch attacks in physical environments.

What makes robot cybersecurity uniquely important is not the number of incidents or even their frequency — it is the consequence class. A compromised enterprise server costs money. A compromised robot operating at full speed and maximum force in a shared workspace costs lives. The cybersecurity investment required for robot deployments is not a line item in the IT budget. It is a prerequisite for responsible deployment — and the gap between current practice and that standard is wider, and more consequential, than the industry is currently acknowledging.

Key Sources

• Manufacturing Business Technology — CVE-2026-8153: Universal Robots PolyScope 5 Vulnerability (May 2026)
• Interesting Engineering — GEEKCon Shanghai: Humanoid Robot Hijacking Demo (Dec 2025)
• arXiv — Cybersecurity of the Unitree G1 Humanoid Robot (Sep 2025)
• ZME Science — Humanoid Robots Secretly Send Data to China (Sep 2025)
• arXiv — Model-Agnostic Adversarial Attacks on VLA Models (Oct 2025)
• arXiv — Eva-VLA: Evaluating VLA Robustness Under Real-World Variations (Sep 2025)
• Frontiers in IoT — SlowROS Attack on Robot Operating System (Apr 2025)
• CyberSecurity Robotics — Red Teaming the ROS in Industry
• ScienceDirect — Addressing Cybersecurity Challenges in Robotics (2024)
• ECCU — Cybersecurity in Robotics (2026)
• Resonance Security — Robotics Cybersecurity 101: Risks, Incidents, and Advice (2025)
• Lakera — Introduction to Data Poisoning: A 2026 Perspective
• CMU CyLab — Poisoned Datasets Put AI Models at Risk (Jun 2025)
• NCSC — Understanding Adversarial Attacks Against Machine Learning and AI (2026)
• Silver Cloud — What Is AI Data Poisoning? 2026 Threats and Defences (May 2026)
• IFR — Top 5 Global Robotics Trends 2026: Safety and Security
• ITECS — Cybersecurity for Manufacturing: OT/IT Convergence Guide 2026
• US Cybersecurity Magazine — Robots and Cybersecurity (IOActive research)
• Dark Reading — Cybersecurity Risks in Humanoid Robots (Dec 2025)
• CyberPractices — IT and OT Convergence Security Best Practices