A Security Vendor Found 28 Zero-Days in Two Days. It Won\u0027t Tell You Which Ones.

A Security Vendor Found 28 Zero-Days in Two Days. It Won’t Tell You Which Ones.

On November 1, 2026, a cybersecurity company called VicOne announced it had found 28 zero-day vulnerabilities in software that supports the physical AI ecosystem — the tools that train, simulate, test and run robots. It took them less than two days. AI-assisted research did the heavy lifting.

The count is the headline. The absence of detail is the story.

Not one of the 28 findings carries a public CVE. Not one affected product is named. The affected projects are described as “developed or maintained by Google, NVIDIA, and Meta, among others” — which is a way of borrowing three of the largest company names in technology to establish seriousness, while telling the reader nothing they can act on.

And it was published as sponsored content. The company telling you robots are insecure sells robot security.

That does not make the findings false. It makes them unverifiable, and it means the first thing a business owner should do with this story is read it correctly — as a sales document that happens to contain a real technical claim.

What VicOne Actually Claimed

The The Robot Report piece is direct about the limits. All 28 findings are classified as zero-days “based on initial validation.” The count may change after vendor and vulnerability-authority review. Some findings do not yet have CVE tracking numbers.

That last sentence is doing a lot of work. A CVE number is how a vulnerability becomes a fact the industry can reference, patch against, scan for and audit. Without one, a finding is a claim in a blog post. It may be entirely correct. It may also be three findings counted twenty-eight ways, or a class of weakness logged once per affected project.

VicOne’s own language acknowledges the gap between a weakness existing and an attack having happened: “that exposure does not necessarily mean an attack has occurred.” Credit where it is due — that is an honest caveat, and a lot of security marketing skips it.

What the piece does give you is a framework. The 28 findings span three stages of the robotics lifecycle, and the distribution is the genuinely alarming part.

Three quarters of the findings are in the tools companies use before a robot goes anywhere near a customer. That is the part worth sitting with.

The 75% Number Is the Real Finding

Most people reading a robotics security story picture an attacker taking over a robot on a factory floor. Cameras capture the hijacked machine, the arm swinging wrong, the thing rolling into a wall. It makes for a good visual and it is the least likely version of this.

The likelier version is quieter and much worse operationally — a compromised tool in the pipeline upstream, where nobody is watching for it because it is a developer utility, not a product.

VicOne describes the mechanism plainly. A team downloads a pretrained model to adapt for its robot. Loading a malicious file gives an attacker access to the training system, which lets them alter the training data or the model itself. The manipulated model then behaves perfectly during routine testing and responds incorrectly to one particular object, scene or command after deployment.

Read that sequence again. The failure happens in the one place your quality process is designed to catch it — and passes.

The simulation variant is worse for anyone who thinks testing is the safety net. Import a compromised scene or robot model, and an attacker has access to the simulation environment. From there they can alter simulated sensor readings or physical conditions or test results, so a robot appears to pass tests that should have exposed unsafe behaviour. The team approves it for real-world use on misleading evidence.

There is a hard implication in there for anyone whose AI governance is a sign-off checklist. Simulation testing is the check. If the check can be manipulated upstream, the check is evidence of a process, not evidence of safety.

That last row is not a smear. Security vendors publish research as marketing because it works, and the practice has produced genuinely valuable work for decades. But it changes what the document is. This is a demand-generation asset with a technical payload attached, and you should weigh it the way you weigh any vendor claim about your own industry.

The Sector Underneath Is Still Unprepared

The reason this story has teeth is not VicOne. It is the state of robotics software in 2026.

Robotics has spent the last three years absorbing a stack of open-source and vendor-supplied machine-learning components — model checkpoints, simulation frameworks, perception libraries — at a pace that security review could not match. A robot team of eight people does not have a vulnerability management programme for its dependencies. It has a container registry and a prayer.

Some figures people cite in this area are worth flagging carefully. One widely circulated 2023 study of the ROS ecosystem reported that 46% of the 11,227 ROS and ROS 2 packages it examined carried at least one known vulnerability, with the numbers climbing since 2020. That study is now several years old and the ecosystem has changed. Treat it as directional, not current.

What has definitively changed is who is looking now. VicOne’s entire premise is that AI has made discovery fast on both sides: researchers can analyze more software in less time, and “attackers could use similar capabilities.” If vulnerability discovery drops from weeks to hours, the window between a weakness existing and a weakness being exploited collapses. Every team that relied on discovery being slow — that counted on nobody bothering to read their dependency tree — loses that assumption.

That applies far outside robotics. Any business running agents, any business whose operations depend on a model it did not train, inherits the same shape of risk.

Who This Actually Costs

There is a tidy irony in a vendor naming Google, NVIDIA and Meta as affected parties without naming a single affected product. Those three companies have the engineering staff to audit a dependency tree in a week. The people who get hurt are one tier down.

Consider a systems integrator with 40 employees building warehouse automation. It assembles its stack from NVIDIA’s simulation tooling, an open-source perception model, a motion planning library, and a couple of vendor SDKs. It sells that integration to a regional logistics customer who has contractually required a security attestation. The integrator cannot produce one that means anything, because it cannot answer the only question that matters: are any of the 28 findings in my stack?

VicOne’s own three-question framework is, to be fair, the correct one. Where do we use the affected software, including training computers, simulation environments and deployed robots. What could the weakness change. How do we verify protection. The framework is sound. It is just impossible to execute against a list that has no product names on it.

So the integrator does what every stretched team does with an unactionable threat advisory: it notes the risk in a spreadsheet, promises to look into it, and goes back to shipping. Which is exactly the behaviour an attacker wants, and exactly the behaviour this disclosure format encourages.

The uncomfortable question is whether that is a bug in the disclosure or the point of it. Publish the count, keep the list behind the sales meeting. Concern converts to pipeline.

And there is one demonstration in the piece that deserves to be taken at face value. VicOne researchers exploited a vulnerability to prevent a robot’s remote-stop command from working. The company is the one selling a fix, so hold the framing loosely — but if that demonstration replicates independently, it is the most significant line in the entire release. A robot whose emergency stop has been disabled is not a security incident. It is a workplace safety event waiting for a date.

The AI Discovery Argument Cuts Where?

The intellectual case in the release is straightforward. Vulnerability discovery means examining code, tracing how systems communicate, and testing whether a suspected weakness can be exploited. AI accelerates the first two substantially. So the argument runs: defenders get faster, so exposure windows shrink, and the industry should be grateful.

Except the acceleration is symmetrical. An attacker with the same AI capability looks at the same open-source models and the same published simulation frameworks. The defender’s advantage in security has never been speed — it has been structure: patch pipelines, signed artifacts, protected build environments, someone whose job is to care.

Speed does not help a team with no process. It drowns them. Twenty-eight findings in two days, multiplied across the ecosystem, delivered to organisations that cannot triage one, is not an improvement in posture. It is a firehose pointed at a paper cup.

The teams that gain from faster discovery are the ones that already had a way to turn a finding into an action. Everyone else gets an extra line item in the risk register.

The Uncomfortable Counter-Argument

Here is the case against everything above.

VicOne followed the process it is supposed to follow. It validated findings, it is running coordinated disclosure with the affected maintainers, and it says outright that the count may change after vendor and authority review. Publishing a count without CVE numbers is not unusual when disclosure is in progress — that gap is the normal state of the world for weeks at a time, and the alternative on November 1 would have been to say nothing at all until some undetermined later date.

And a security company announcing where a category of software is weak is the mechanism that gets the category fixed. If VicOne had stayed silent, three quarters of a newly discovered vulnerability class would sit undiscovered-in-public while the affected tools shipped into more robots. The sponsor label changes who profits. It does not change whether the underlying finding is true.

That counter-argument is strong, and it does not overturn the core problem. Both things are true: the research may be valuable, and the disclosure is unactionable by design. A reader can hold both without accusing anyone of fraud.

What to Do If You Run Any AI Pilot

You cannot act on the 28 findings. You can act on the gap they expose, and that gap is present whether or not VicOne’s count survives review.

Run the three questions on your own stack this week. Then add the one VicOne did not have to answer because it would have cost them a sale.

First, map where the software actually lives. Training machines are the forgotten ones. Most companies treat their laptops and servers as administrative, not industrial, and no one has ever asked whether a compromise there could change the model that directs the thing on the floor.

Second, stop treating simulation as evidence. A passing simulation test proves your test ran. It does not prove your pipeline was intact when it ran. If you cannot demonstrate that your simulation inputs were integrity-checked, you cannot present a passing test as safety evidence to a customer, an insurer or a regulator. That is a change in what you are permitted to say, not just a change in what you do.

Third, pin and verify what you download. Every pretrained model and every open-source simulation asset should arrive with a hash you check. This is a low-cost control that eliminates the specific attack path VicOne describes — a malicious file in a trusted download — and almost nobody in robotics does it.

Fourth, when a fix lands, test the fix. A patch existing is not a system being safe. VicOne’s own line on this is the most useful sentence in the release: a newly discovered weakness may reveal conditions that your earlier successful test never examined. Your old test passing means nothing about a class of behaviour it was never designed to look at.

Fifth, decide how much of an emergency stop depends on software you do not control. That is the question the remote-stop demonstration asks, and it is answerable without knowing whether any of the 28 are in your stack. If the answer is “all of it,” you have found a risk that was yours before VicOne published anything.

The count will be revised. The CVEs will appear or they will not. Some number of these findings will turn out to be genuine and serious, and some will turn out to be one weakness counted repeatedly. None of that changes the structural problem: the tools that build your robot are outside your audit boundary, and the industry is only now noticing.

Frequently Asked Questions

Are the 28 zero-days real? VicOne classifies all 28 as zero-days based on initial validation and says the count may change after vendor and vulnerability-authority review. Independent confirmation is pending, and several of the affected projects are maintained by companies with the resources to review quickly. Treat the findings as credible-but-unconfirmed until CVEs appear.

Which products are affected? VicOne has not named them. The release says the findings involve projects “developed or maintained by Google, NVIDIA, and Meta, among others” without specifying which products or versions. The company describes three lifecycle stages — development and training, simulation and validation, deployment and runtime — and says 75% of findings fall in the pre-deployment tools. Specific names are expected through coordinated disclosure.

Were any of these vulnerabilities exploited in an attack? No. VicOne states explicitly that exposure does not necessarily mean an attack has occurred. These are found weaknesses, not confirmed incidents. The one demonstrated exploit in the release is the company’s own research demonstration showing a remote-stop command being disabled.

Why does it matter that it was sponsored content? Because the publisher, VicOne, sells robotics security products — Radeis and Rthena — and the article links to both with promotional tracking. That does not invalidate the findings, but it means the release’s framing serves a commercial purpose, and the decision to publish a dramatic count before a detailed, actionable list is worth weighing in that context.

Should I stop an AI or robotics pilot because of this? No. Cancel nothing on the strength of a count you cannot check against your stack. Do the mapping work instead — inventory where pretrained models and simulation assets enter your environment, verify their integrity, and stop treating a passing simulation test as proof of safety. The action is in your pipeline, not in VicOne’s list.

If my business does not use robots, does this affect me? Possibly. The three lifecycle stages — untrusted downloads, manipulated test environments, upstream tooling you do not audit — describe how most businesses now consume AI, not just robotics. Any workflow that pulls a model or a template from outside and trusts the output inherits the same structure of risk.