28 Zero-Day Findings in Less Than Two Days: What AI-Speed Discovery Means for Robotics

VicOne identified an initial set of 28 zero-day findings in less than two days using AI-assisted research across software and tools supporting the Physical AI ecosystem. These include projects developed or maintained by Google, NVIDIA, and Meta, among others.

Based on initial validation, all 28 findings are classified as zero-day vulnerabilities. The count may change following vendor and vulnerability-authority review, and some findings do not yet have CVE tracking numbers.

Many of these tools help teams train, simulate, test, and operate robots. Weaknesses in them could influence the models teams build, the test results they trust, and the instructions sent to robots.

These findings create two demands for robotics teams: responding as AI helps uncover weaknesses faster , and assessing how each one could affect robot safety and operations .

What AI changes about vulnerability discovery

Vulnerability discovery involves examining code, tracing how systems communicate, and testing whether a suspected weakness can actually be exploited. AI can accelerate parts of this work, helping researchers analyze more software in less time. Attackers could use similar capabilities.

When the weakness is a zero-day — previously unknown and without an available fix — faster discovery can leave teams with little time to respond. While that exposure does not necessarily mean an attack has occurred, teams still need to determine whether they use the affected software and what an attacker could access or change.

Where the findings sit across the robot lifecycle

VicOne’s findings span three stages of the robotics lifecycle: development and training, simulation and validation, and deployment and runtime. Weaknesses at each stage could affect what a robot learns, how it is tested, and how it is controlled.

Figure 1. In this research set, 75% of findings involved development, training, simulation, or validation tools, highlighting risks that can arise before a robot is deployed.

The following scenarios show how a compromised component could influence the robot at each stage.

Development and training: Hidden changes can reach the finished robot

A team downloads a pretrained model to adapt for its robot. Loading a malicious file could give an attacker access to the training system, allowing changes to training data or the model itself. A manipulated model could behave normally during routine testing but respond incorrectly to a particular object, scene, or command after deployment. The risk can enter through a tool the team trusts, before anyone attacks the robot directly.

Simulation and validation: A passing test could give false confidence

Importing a compromised scene or robot model could give an attacker access to the simulation environment. With sufficient control, the attacker could alter simulated sensor readings, physical conditions, or test results. A robot could then appear to pass tests that should have exposed unsafe behavior, leading the team to approve it for real-world use on the basis of misleading evidence.

Deployment and runtime: Operators could lose visibility or control

An attacker could exploit weaknesses to change files that influence motion planning or send malicious map data that crashes the operator’s monitoring display. Compromising a remote-operation computer could also put the instructions sent to the robot at risk. Depending on the system and its safeguards, these weaknesses could alter robot movement or leave operators unable to see what is happening and respond promptly.

These are potential consequences and not demonstrated outcomes for every finding. Actual effects depend on the attacker’s access, the system’s design, and whether other safeguards prevent the changes from reaching physical behavior.

In a separate demonstration, VicOne researchers provide a concrete example of a weakness affecting a protective function. The researchers exploited a vulnerability to prevent a robot’s remote-stop command from working. The case shows why teams need to test whether safeguards remain effective when the software supporting them is compromised.

Video 1. VicOne researchers demonstrate a vulnerability that prevents a robot’s remote-stop command from working.

A published patch still needs to be proven safe

AI can shorten the search for weaknesses, but a robotics team still needs to determine whether a fix is safe to deploy. Even after a software maintainer releases a patch, teams must identify affected systems, check compatibility, and verify that the update preserves intended behavior.

An earlier successful test remains useful evidence. However, a newly discovered weakness may reveal conditions that test never examined.

Three questions can help teams respond:

Where do we use the affected software? Include training computers, simulation environments, and deployed robots.

What could the weakness change? Assess whether it could affect models, test results, operator visibility, or robot behavior.

How do we verify protection? Confirm that the fix addresses the weakness and that the updated system still operates as intended.

When immediate updating is impractical, teams may need temporary safeguards, such as restricting access to an affected service, while a validated fix is prepared.

From discovery to safer deployment

As details from the 28 findings become available through coordinated disclosure, the next step is for robotics manufacturers is to connect each finding to its potential effect on development, deployment, and robot behavior.

That work also requires understanding how threats could affect robot behavior and how to protect systems already in operation. VicOne Radeis helps teams identify potential zero-day vulnerabilities, assess AI model and system security, and use simulation to evaluate how these risks could affect robot behavior before deployment. VicOne Rthena supports threat detection and responses within approved policies during operation.

Figure 2.…

News is gathered automatically from public robotics & AI feeds on a schedule.