VicOne identified 28 zero-day findings in less than two days, using AI-assisted research across software and tools that support the physical AI ecosystem. The set includes projects developed or maintained by Google, NVIDIA and Meta, among others. These robotics zero-day vulnerabilities were classed as zero-days on initial validation only.
The count is not final. It may change after review by vendors and vulnerability authorities, and some of the findings do not yet have CVE tracking numbers. Coordinated disclosure is still under way, so details of the individual flaws have not been published.
What the findings cover
Many of the affected tools are used to train, simulate, test and operate robots. That makes them different from a flaw in a single robot's firmware. A weakness in a training or simulation tool can shape the models a team builds, the test results it trusts, and the instructions that eventually reach a machine.
VicOne sorted the findings into three stages of the robotics lifecycle: development and training, simulation and validation, and deployment and runtime. In this research set, 75% of the findings involved development, training, simulation or validation tools. Most of the exposure therefore sits in places a robot passes through before it is deployed.
The speed matters because of what a zero-day is: a flaw that was previously unknown and has no available fix. VicOne says AI can accelerate parts of vulnerability research, including examining code, tracing how systems communicate, and testing whether a suspected weakness can be exploited. It adds that attackers could use similar capabilities. Faster discovery does not mean an attack has occurred, but it can leave teams little time to work out whether they use the affected software and what an attacker could reach or change.
Three stages, three kinds of exposure
VicOne describes a scenario for each stage. None is presented as a demonstrated outcome for every finding. Actual effects depend on the attacker's access, the system's design, and whether other safeguards stop changes from reaching physical behavior.
In development and training, a team might download a pretrained model to adapt for its robot. Loading a malicious file could give an attacker access to the training system, and with it the ability to alter training data or the model. A manipulated model could behave normally in routine testing and then respond incorrectly to a particular object, scene or command after deployment.
In simulation and validation, importing a compromised scene or robot model could give an attacker access to the simulation environment. With enough control, the attacker could change simulated sensor readings, physical conditions or test results. A robot could then pass tests that should have exposed unsafe behavior, and the team would approve it on misleading evidence.
In deployment and runtime, an attacker could change files that influence motion planning, or send malicious map data that crashes an operator's monitoring display. Compromising a remote-operation computer could also put the instructions sent to the robot at risk. Depending on the safeguards in place, these weaknesses could alter movement or leave operators unable to see what is happening.
A remote-stop demonstration and the patch problem
In a separate demonstration, VicOne researchers exploited a vulnerability to stop a robot's remote-stop command from working. The case is narrower than the 28 findings, but it shows a protective function failing because of the software that supports it.
VicOne also argues that a published patch does not end the work. Teams still have to identify affected systems, check compatibility, and verify that the update preserves intended behavior. An earlier successful test remains useful evidence, but a newly found weakness may involve conditions that the test never examined.
The company suggests three questions. Where is the affected software used, including training computers, simulation environments and deployed robots? What could the weakness change, whether models, test results, operator visibility or robot behavior? How is protection verified, meaning both that the fix closes the weakness and that the updated system still works as intended? Where immediate updating is impractical, it says teams may need temporary measures such as restricting access to an affected service while a validated fix is prepared.
What this means for the field, and what is unproven
The most useful point in the findings is where they fall. Robot security is often discussed in terms of the machine on the factory floor or in the field. This set puts most of the reported weaknesses upstream, in the tools that decide what a robot learns and whether it is judged safe. A compromised test environment is a particular problem because it can damage the evidence that safety sign-off relies on, without any visible fault in the robot itself.
The set also touches projects from large, widely used organizations, which suggests the exposure is not limited to obscure software. Teams that build on shared open tooling inherit whatever flaws that tooling carries, and they may not track it as part of their security surface.
Several things remain unproven. The 28 findings are VicOne's own initial validation, published in a piece that also promotes the company's products, and no independent party has confirmed the count. The source does not say how severe each flaw is, how many are exploitable in a typical deployment, or whether any has been used in an attack. The scenarios are potential consequences, not demonstrated ones.
The speed claim also lacks a baseline. Finding 28 candidate zero-days in under two days is a striking figure, but the source gives no comparison with how long conventional manual research would take on the same software. It also does not say how much of the work was done by AI and how much by researchers. The figure supports the narrower claim that AI-assisted research can surface many candidates quickly. It does not show that the same pace holds for confirmed, fixed and disclosed vulnerabilities.
What to watch next is the disclosure process. As vendors review the findings, the final count, the CVE assignments and the patches will show how many of these robotics zero-day vulnerabilities hold up, and how quickly the affected projects can ship fixes that robotics teams are able to validate.
