Your Robot May Pass Every Test. Its Simulator Could Still Be Lying

Last checked: 3 November 2026. Vulnerability identifiers, affected projects and patch information will be updated as coordinated disclosures become public.

A robot that clears every simulated obstacle course has earned a green row in a test report. That row is evidence, and evidence has a source. If the simulator, the scene files or the scripts that score the run have been tampered with, the robot hasn’t proved anything at all.

That’s the uncomfortable question behind VicOne’s announcement on 1 November. The Tokyo-based security company says AI-assisted research turned up 28 zero-day findings in under two days, and that about three-quarters sit in the tools used to develop, train, simulate and validate robots. For robotics cybersecurity, that shifts attention from the machine on the factory floor to the systems that decide it’s safe to put it there.

Key Takeaways

• VicOne reports 28 AI-assisted zero-day findings in under two days. They’re vendor-reported and initially validated by the company, with no affected projects or CVEs published yet.
• About 75% sit in development, training, simulation or validation tools. The exposed surface is the toolchain, not only the robot.
• A compromised simulator can produce passing results for an unsafe robot. Simulation evidence needs integrity controls.
• The remote-stop demo shows a software stop path can fail. It doesn’t show that hardwired emergency stops can be defeated.
• Training artefacts and simulation assets are part of the supply chain. Poisoned models or meshes can carry problems into deployment.
• Robotics cybersecurity covers the whole lifecycle, from repositories to fleet commands.
• Reported, validated, CVE-assigned and patched are different states. None of the 28 has publicly reached the last two.
• Teams should verify assets, repeat critical tests independently and keep a physical stop.

---

Quick Navigation

---

The 28 findings: what VicOne actually reported

The claim appeared in a sponsored post on The Robot Report. It describes “less than two days of AI-assisted research across software and tools that support the ‘Physical AI’ ecosystem,” including projects “developed or maintained by Google, NVIDIA and Meta.” It states: “Based on initial validation, all 28 findings are classified as zero-day vulnerabilities.”

Read that sentence carefully. “Zero-day” here is VicOne’s classification of flaws it believes were previously unknown. “Initial validation” is VicOne’s own. According to AI Weekly’s write-up, the post says the count may change after review, some findings “do not yet have CVE tracking numbers,” and the consequences it describes “are potential consequences and not demonstrated outcomes for every finding.”

The post doesn’t name an AI model or tool. It doesn’t say whether “less than two days” covers discovery alone or discovery plus human triage. It doesn’t identify a single affected repository, which is normal during coordinated disclosure. It also ends with a pitch for VicOne’s upcoming white paper and its products: Radeis, which the company sells for pre-deployment validation of AI robots, and Rthena, for runtime protection. VicOne has a commercial interest in showing that its discovery works. That doesn’t make the findings wrong. It means they should be treated as vendor-reported until maintainers or independent researchers confirm them.

Robotics cybersecurity tracker: the 28 findings

Table: scroll sideways to view all columns when needed.

Tracker field	Information
Research organisation	VicOne
Reported findings	28
Discovery period	Less than two days, as reported
Initial classification	Vendor-reported zero-day findings, based on VicOne’s initial validation
Pre-deployment tool share	About 75% (roughly 21 of 28), as reported
AI tools used	Not disclosed
Affected projects	None publicly identified; the post refers to projects from Google, NVIDIA, Meta and others
CVE status	No CVE publicly linked to the findings; some lack CVE numbers, per the post
Independent confirmation	None found
Patch status	Not disclosed
Last verified	3 November 2026

This article will be updated when there are new CVE assignments, maintainer acknowledgements, published patches, severity scores, independent reproduction or a revised count.

Robotics cybersecurity begins before deployment

The detail worth more than the headline number is where the bugs sit. The post says that 75% of the findings “sit in development, training, simulation or validation tools,” rather than in software running on a deployed robot.

That doesn’t mean 21 vulnerabilities can each reach out and move a robot arm. A flaw in a training tool usually needs an attacker to get malicious input into the pipeline first: a poisoned dataset, a tampered model file, a crafted scene asset or access to a shared build machine. The impact depends on what the tool touches next. Code execution on a workstation is an IT problem. Code execution on a machine that writes the policy file shipped to a fleet is a robot problem, and that’s the gap robotics cybersecurity has to cover.

Where robotics cybersecurity meets the training pipeline

A modern robot’s behaviour is assembled long before it runs. Robot description files define its joints and geometry. Simulation assets define the world it learns in. Training jobs produce policy checkpoints. Validation scripts decide whether those checkpoints pass. Each step consumes files written by someone else, often downloaded from public repositories.

VicOne’s post gives an example of the stakes: a manipulated model could make a robot “respond incorrectly to a particular object, scene, or command after deployment.” That’s a description of a possible outcome, not a reported exploit. But the mechanism isn’t speculative. Pickle-based model files can execute code when loaded, which is why our guide on how to verify model weights before loading them treats format and provenance as separate checks.

When the simulator lies, the safety case breaks

Simulation is where most modern robots earn their first approval. Teams run thousands of scenarios they could never stage physically, record pass rates and use those numbers in design reviews and safety arguments. The post’s own warning is blunt: a robot “could then appear to pass tests that should have exposed unsafe behavior.”

The chain is longer than most security reviews cover. Robot software is trained on data, tested in a simulator, scored by validation scripts and summarised as safety evidence. Engineers and auditors then make deployment decisions from that evidence. A compromise at any earlier link can be invisible at the last one, because the evidence looks exactly like a pass.

An illustrative robotics cybersecurity failure in simulation

This scenario is illustrative. It isn’t an incident VicOne or anyone else has reported.

A warehouse robotics team tests whether a mobile manipulator stops for a person stepping into an aisle. An attacker has altered a shared scene package so the simulated lidar returns are slightly delayed only when a human model enters from the left. Alternatively, the attacker has patched the scoring script to log a stop when the robot only slowed down. The robot “passes” 2,000 runs. The report goes to the safety review with a clean result, and nobody asks whether the simulator itself was the thing under test.

Published research shows how quiet this can be. In September, researchers described collision mesh poisoning. A 3D asset has a visual mesh for rendering and a collision mesh for physics. Altering only the collision mesh can produce policies that look normal in simulation and fail after deployment. The authors note that current asset reviews check for malware, licensing and format, not whether the two meshes agree.

This is where robotics cybersecurity parts ways with conventional IT security: the output is a decision about physical risk. A stolen password gets reset. A safety sign-off based on corrupted evidence can put a machine next to people. The principle is simple: a safety test is only as trustworthy as the system producing its evidence.

UniverseBlend made a similar point about AI model testing in Four Labs, One Evaluator, arguing that “the evaluator’s infrastructure needs the same scrutiny the industry currently applies to model behaviour.” The cases aren’t technically alike. One was about network containment during evaluations, the other is about simulation integrity. The shared lesson is that the system producing the evidence must itself be trustworthy.

What the remote-stop demo means for robotics cybersecurity

The one concrete artefact in the announcement is a video. VicOne’s post says “the researchers exploited a vulnerability to prevent a robot’s remote-stop command from working.” A VicOne video titled Robot Keeps Moving After STOP Is Pressed, credited to its LAB R7 research group, was posted on 11 October, three weeks before the 28-finding announcement. Its description doesn’t name the robot, the software stack or the vulnerability. VicOne hasn’t said whether the demo is one of the 28 findings.

The word that matters is “remote.” A remote-stop command is usually a software message sent over a network to the robot’s controller, through middleware, an API or a fleet manager. If an attacker can block, delay or spoof that message, the command never arrives. That’s serious, and it’s a cybersecurity failure.

A safety-rated emergency stop is a different thing. Under IEC 60204-1 and ISO 13850, an emergency stop must take priority over all other functions in every operating mode. It’s typically implemented through safety-rated hardware that cuts or controls drive power independently of the application software. UniverseBlend’s analysis of Isaac ROS 5.0 and the robotics agent boundary made the same point: e-stops sit below the ROS layer.

Nothing public suggests VicOne defeated a hardwired emergency stop, and the demo shouldn’t be read as showing that all emergency stops can be disabled. It does show something that matters: some deployments rely on software stop paths as a practical safety measure, and those paths need to be authenticated, monitored and backed by an independent physical stop.

Shared tools turn robotics cybersecurity into a supply-chain problem

Robotics runs on a small number of shared foundations: ROS 2 for middleware, simulators such as Gazebo and NVIDIA Isaac Sim, NVIDIA’s Isaac ROS packages, open training frameworks and public repositories of robot models and assets. VicOne hasn’t named any affected project, and being part of this ecosystem doesn’t make a project vulnerable. But when a shared tool has a flaw, every team that uses it inherits the exposure, so robotics cybersecurity depends partly on code nobody on the team wrote.

Independent records show the toolchain is a real target. CVE-2026-25874, published in April and unrelated to VicOne, covers Hugging Face’s LeRobot through version 0.5.1. Its policy server and robot client used pickle.loads() on data received over unauthenticated gRPC without TLS, allowing remote code execution. It’s rated 9.3 (critical) under CVSS 4.0.

Configuration matters as much as code. ROS 2’s security layer, SROS 2, is off by default. Even when enabled, its default “permissive” strategy launches a node without security if its security files are missing. Teams that want enforcement must set the “Enforce” strategy explicitly. A 2018 scan of the internet for ROS found robots reachable from the public internet. With consent, the researchers read camera data from a university robot and moved it.

AI-assisted discovery: faster robotics cybersecurity research, harder response

AI-assisted vulnerability research usually means models reading code, spotting dangerous patterns, tracing how untrusted data flows into risky functions and drafting proof-of-concept inputs. Humans still decide whether a crash is exploitable, rate severity, write the report and handle disclosure.

The approach has a track record, with caveats. Google’s Big Sleep agent found an exploitable flaw in SQLite before it reached a release in 2024. Its team called the results “highly experimental” and said a target-specific fuzzer was likely at least as effective. In May 2026, Google’s threat intelligence group reported that attackers had used AI to find and exploit a zero-day for a planned mass-exploitation campaign.

That second case is the uncomfortable symmetry. If a defender can surface 28 candidate flaws in two days, an attacker with similar tools can too. Discovery speeds up; patching doesn’t. Many robotics tools are maintained by small teams or research groups. Fixes then have to travel through pinned versions, container images and robot fleets that update slowly. The bottleneck moves from finding bugs to absorbing them.

What Robotics Teams Should Check Now

These are practical robotics cybersecurity checks, not a certified safety standard. They don’t replace functional-safety requirements such as ISO 10218, ISO 13849 or IEC 61508 where they apply.

1. Development environment

• Protect repositories with signed commits and branch protection.
• Pin dependencies and record where each one came from.
• Limit who and what can trigger builds.
• Validate model files before loading them.
• Restrict access to training machines.

2. Training pipeline

• Record dataset provenance.
• Hash model checkpoints and other training artefacts, and verify them at each handoff.
• Separate access between data, training and release.
• Make runs reproducible enough to repeat when results look wrong.

3. Simulation environment

• Version-control scenes, robot descriptions and simulator configurations.
• Hash simulation assets and check that visual and collision geometry agree.
• Treat simulator plugins and dependencies as code that needs review.
• Protect test logs and results from modification.

4. Validation process

• Keep known-good baselines and run safety regression tests against them.
• Repeat key scenarios on a second, independently built environment.
• Confirm critical behaviours physically, not only in simulation.
• Have a person review anomalies rather than only pass rates.

5. Deployment and operation

• Segment robot networks.
• Authenticate commands; for ROS 2, enable SROS 2 in Enforce mode.
• Give fleet tools least-privilege access.
• Monitor command and telemetry paths.
• Verify that a physically independent emergency stop works.
• Confirm patches actually landed on every robot.

Robotics cybersecurity questions VicOne hasn’t answered yet

Several questions decide whether this is a significant disclosure or a strong marketing demonstration:

• Which Google, NVIDIA and Meta projects are affected, and at what severity?
• Which AI tools did the work, and how much human validation followed?
• Does “less than two days” include triage?
• Is the remote-stop demo one of the 28, and has it been fixed?
• Will maintainers confirm the reports, and will independent researchers reproduce them?

Until advisories or CVE records appear, the honest position is that 28 findings have been reported and none has been publicly confirmed. The checks above don’t depend on the answer, though. For robotics cybersecurity teams, they’re worth doing either way.

Frequently asked questions

What is robotics cybersecurity?

Robotics cybersecurity protects robots and the systems around them, including development tools, training pipelines, simulators, networks and command paths, from attacks that could affect data or physical behaviour.

What did VicOne’s robotics cybersecurity research find?

VicOne says AI-assisted research found 28 zero-day findings in under two days, mostly in development, training, simulation and validation tools. The findings are vendor-reported and not yet publicly confirmed.

Why are development tools a robotics cybersecurity risk?

They produce the code, models and test results that determine how a robot behaves. A compromised tool can pass tampered output downstream without any change to the robot itself.

How can a compromised simulator affect robot safety?

It can alter scenes, sensor data or scoring so an unsafe robot appears to pass. Teams may then approve deployment based on misleading evidence.

How does physical AI security differ from robotics cybersecurity?

Physical AI security focuses on AI systems that sense and act in the physical world, including model and perception attacks. It overlaps heavily with robotics cybersecurity, which also covers conventional software, networks and hardware.

How does AI help researchers discover software vulnerabilities?

AI models can read code, flag risky patterns, trace data flows and draft test inputs quickly. Humans still confirm exploitability, assess severity and handle disclosure.

Why are robotics training pipelines vulnerable to attacks?

They consume datasets, model files and assets from many sources, often with little integrity checking. Poisoned inputs can change learned behaviour in ways tests may not reveal.

What should teams do to improve robotics cybersecurity now?

Verify dependencies, models and simulation assets, protect test evidence, repeat critical tests independently, authenticate robot commands and keep a physical emergency stop.

Are the 28 VicOne findings assigned CVE numbers?

Not publicly, as of 3 November 2026. VicOne says some findings don’t yet have CVE numbers, and none of the 28 has been publicly linked to a CVE record.ntainer with no credentials, no network and resource limits, while watching what it does.

---

Keep reading

Here are the latest posts from the blog.