VicOne finds 28 zero-days in robotics in less than 48 hours: AI accelerates the hunt for vulnerabilities (and masks them)

VicOne Finds 28 Zero-Days in Robotics in Under 48 Hours: AI Accelerates Vulnerability Hunting (and Masks It)

🔎 Two Days, 28 Flaws: Vulnerability Research Just Changed Scale

VicOne, the mobility-focused cybersecurity company born from Trend Micro, announced that it discovered 28 zero-day vulnerabilities in robotics and physical AI software — including projects tied to the Google, NVIDIA and Meta ecosystems — in under 48 hours, using AI-assisted fuzzing. A pace that experienced teams traditionally take several months to achieve.

Why does this matter now? Because two curves are crossing. On one side, robotics is entering its industrialization phase: more than 4 million industrial robots in operation worldwide (IFR, 2024) and a humanoid market projected at 38 billion dollars by 2035 (Goldman Sachs, 2024). On the other, agentic models are compressing vulnerability discovery time from several weeks down to a few hours.

The figure of 28 isn't the most interesting part. The breakdown is: 75% of these flaws don't affect deployed robots, but rather the development, training and simulation tools used to build them. In other words, the robot factory is more exposed than the robots themselves.

The essentials

• 28 zero-days in less than 48 hours, discovered by VicOne through AI-assisted fuzzing in robotics and physical AI software tied to Google, NVIDIA, and Meta, as reported by The Robot Report.
• 75% of the vulnerabilities affect dev, training, and simulation tools, not production robots.
• Demonstrated impacts: a remote stop command rendered ineffective, training pipelines vulnerable to poisoning, and simulators capable of returning falsified results.
• Some vulnerabilities had no CVE at the time of publication: coordinated disclosure is no longer keeping up with the pace of discovery.
• VicOne's central advice: re-verify patches against expected behavior, not just against a version number.

Recommended Tools

If you develop or operate robotic systems, these tools allow you to reproduce this type of hunt — strictly in an isolated environment.

28 zero-days in two days: what VicOne actually did

VicOne didn't find "a" vulnerability: it found 28 of them, using LLMs to guide fuzzing — the technique of bombarding a program with malformed inputs until it crashes — against robotics and physical AI software.

The difference from classic fuzzing comes down to one sentence: traditional fuzzing mutates inputs randomly or based on code coverage, blind to meaning. An LLM, on the other hand, understands formats, reads documentation, generates structured inputs, and targets the most promising parsers. Less noise, more genuinely exploitable crashes. The result: 28 unique vulnerabilities in under two days, as detailed by AI Weekly.

The scope matters as much as the number. The flaws affect components tied to the Google, NVIDIA, and Meta ecosystems: simulators, training frameworks, development tools. The software stack that gives rise to robots, not just the one that runs them.

My take: this result says less about robotics than about the economics of vulnerability research. Yesterday, the scarce resource was expertise — knowing where to look, how to write a relevant test case. Today, the scarce resource becomes patch time. And that, no vendor has compressed.

75% of vulnerabilities don't affect the robots, but the factory that builds them

The central takeaway from this research is that the critical attack surface of robotics has shifted upstream: toward simulators, training frameworks, and development tools.

A quick reminder of how things work today: robot motor policies are learned in simulation, then deployed on real hardware — the famous sim-to-real. Two security consequences follow directly from this.

A simulator capable of returning falsified results is a rigged certification: you validate a behavior on manipulated data, and that behavior ships out into the field. A training pipeline that can be poisoned is worse: the model learns the wrong lesson without your knowledge, and no one sees it in the final metrics.

This shift in the attack surface comes at the worst possible time. Physical AI is going full-stack — Genesis AI is following up its GENE-26.5 foundation model with humanoid robotic hands, as we saw in our analysis of the Genesis AI announcement — and every layer added to the stack mechanically widens the attack surface.

For years, the robotics security question boiled down to "can the robot be hacked?". The right question now is: "who can corrupt what taught the robot?". Frankly, almost no one has an answer ready.

Neutralized emergency stop, poisoned training, falsified simulation: the three impacts that matter

Three impact scenarios were demonstrated by VicOne, and each one hits a different control point in the robotic chain.

The remotely commanded emergency stop neutralized. An attacker capable of interfering with an emergency stop isn't stealing data: they are creating a physical risk. In a warehouse or a factory, this isn't a compliance issue, it's a matter of human safety.

The poisoned training pipeline. Injecting malicious data into training produces a model that behaves normally 99% of the time and dangerously in the remaining 1%. Detecting this kind of backdoor after the fact is extremely costly.

The simulator that lies. A simulator that returns falsified results turns validation into theater: tests pass, metrics are green, and nothing guarantees that the real robot will behave as validated.

These upstream flaws don't make deployed robots harmless, though — far from it. The command injection discovered in the Unitree Go2 charging module (CVE-2026-115995), on port 9610, proves it: commercial robots carry their own direct flaws. VicOne simply adds a second front: the chain that manufactures the behaviors is just as attackable as the robot itself.

On the e-stop, let's be direct: a software path that commands an emergency stop should be treated with the level of rigor applied to avionics. Treating it as a secondary component is organized negligence.

Is AI Really Changing Vulnerability Research? Yes, on Three Fronts — Not All of Them

Yes, AI is changing vulnerability research: on speed, on the cost of entry, and on scaling exploitation. No, it does not solve exploitability validation or disclosure coordination.

1. Speed, first

Temporal compression is now documented everywhere. AI agent red teaming has gone from several weeks to a few hours, and VicOne is applying the same compression to bug hunting: 28 zero-days in 48 hours. This is not an incremental improvement, it's a regime change.

2. The cost of entry, next

An LLM reads code, reads documentation, generates structured inputs, and triages crashes. Teams of two or three people are now doing what used to require a dozen specialists. State-of-the-art agentic models — OpenAI's GPT-5.5, Anthropic's Claude Opus 4.7 (Adaptive), Google's Gemini 3 Pro Deep Think — are pushing up the ceiling of what can be found automatically. And self-hosted models like Kimi K2.6 (Moonshot AI) or GLM-5 (Z.AI) allow labs to work on sensitive code without sending it to third-party APIs.

3. Scaling exploitation, finally

Discovery is only half the equation. GreyNoise has documented the first worldwide campaign of exploits generated by AI agents: Codex was driving a DeepSeek model to deploy PaperCut zero-day exploits against 395 organizations. Discovery and exploitation are industrializing at the same time. It's this combination that should worry us, not either one in isolation.

What isn't changing (yet)

Validating that a crash is exploitable, coordinating with vendors, writing and deploying a patch: all of this remains human, slow, and sequential. AI finds faster than we can patch — and the gap between the two speeds is only widening.

AI doesn't invent vulnerabilities; it eliminates dead time. And until now, that dead time was your margin for maneuver.

Flaws Without CVEs: The Hidden Link in the Disclosure Chain

Several of the 28 vulnerabilities reported by VicOne had no CVE assigned at the time of publication. This may be the most underestimated detail of the entire announcement.

The CVE process — request, assignment, coordination with the vendor, publication — takes weeks, sometimes months. AI compresses discovery, not administration. The result is a growing class of real, demonstrated flaws that remain invisible to your scanners, your compliance dashboards, and your SOCs.

The "masking" mentioned in the title has three concrete faces.

First face: administrative invisibility. Without a CVE, the flaw doesn't exist for your vulnerability management tools — even though it exists just fine for a motivated attacker.

Second face: the superficial patch. A patch can remove the symptom without fixing the cause, especially when it's produced on an assembly line. VicOne heavily stresses this point: re-verify patches against expected behavior. A patch validated "blindly" proves nothing.

Third face: false confidence. "We fuzzed with AI, so we're good" — no. Fuzzing finds crashes; it never demonstrates the absence of flaws. Confusing the two means replacing acknowledged ignorance with certified ignorance.

A patch that doesn't restore expected behavior isn't a fix, it's a band-aid. And AI, by accelerating the entire cycle, multiplies the opportunities to apply them.

Securing your robotics stack: five measures to take this week

Three priorities emerge from this research: map the dev/sim/training chain, segment it, and verify patches by behavior — not by version number.

1. Inventory your simulation and training tools as production assets. They produce your robots' behavior; a compromised tool means a compromised robot by proxy. If they're not in your CMDB, then no one is managing them.

2. Segment. Lab network and production network must be separated, with explicit rules. The software paths of the emergency stop must be isolated from the rest and tested regularly.

3. Verify patches functionally. Write regression test suites for safety behaviors — the e-stop works, simulator outputs stay plausible — and run them after every update. This is exactly the verification VicOne is calling for.

4. Automate fuzzing in CI. OSS-Fuzz or AFL++ on your parsers, your communication interfaces, and your data entry points. Better to find the crash before a hostile AI agent does.

5. Physically isolate your test environments. A dedicated VPS — for example at Hostinger — rather than shared infrastructure, and never a fuzzing target on the production network. The cost of separation is trivial compared to that of an incident.

The sim-to-real reflex

What you certify in simulation ends up in the real world. Protect the integrity of your simulator the way you protect your production data: access control, logs, output integrity verification. An unprotected simulator isn't a dev tool, it's a Trojan horse on borrowed time.

❌ Common Mistakes

Mistake 1: "Our robots aren't connected to the Internet, so this doesn't concern us"

The 75% figure dismantles this argument: attackers no longer target just the robot — they target what built it. A model trained on poisoned data arrives at your facility "clean," certified by a falsified simulator. The solution: map the behavior supply chain — models, data, simulators — not just the hardware supply chain.

Mistake 2: Mistaking the patch for the fix

A deployed patch is not a fixed vulnerability. VicOne repeats it: verify the expected behavior, because a patch can mask the symptom without addressing the cause. The solution: functional security tests after every update, with criteria written before the patch is applied, not after.

Mistake 3: Confusing "no CVE" with "no risk"

CVE assignment follows an administrative schedule, not technical reality. Demonstrated vulnerabilities can remain invisible to scanners for weeks. Follow vendor advisories and research like VicOne's directly, as a complement to — never a replacement for — your vulnerability databases.

Mistake 4: Believing that AI on your side can catch up with the attacker's AI

Your tools find things faster, but your organization fixes at the same pace as before. If you process findings in order of arrival, you drown your teams in volume. Prioritize by exploitability and security impact: the e-stop before the log leak, always.

❓ Frequently Asked Questions

What is a zero-day, concretely?

A vulnerability unknown to the vendor at the time of its discovery or exploitation, meaning no patch is available. VicOne reported 28 flaws of this type to their respective vendors. The term says nothing about severity: a zero-day can be as trivial as it can be critical, and everything depends on actual exploitability.

Which software is affected by the 28 flaws?

Robotics and physical AI software tied to the Google, NVIDIA, and Meta ecosystems, according to reports from The Robot Report and AI Weekly. The bulk — 75% — concerns development, training, and simulation tools, rather than software stacks embedded in production robots.

Do these flaws allow taking control of deployed robots?

Not directly, for the most part: they affect upstream tooling. But the demonstrated impacts — neutralized emergency stop, poisoned training, falsified simulation — trace an indirect path to the real world. Deployed robots also have their own flaws, such as command injection on the Unitree Go2.

Why do some flaws have no CVE?

Because assigning a CVE identifier depends on a manual coordination process between researchers, vendors, and numbering authorities. When discovery happens within 48 hours, the administration can no longer keep up. The absence of a CVE absolutely does not mean the absence of a vulnerability.

Will AI replace security researchers?

No, it changes their productivity and the balance of power. AI accelerates input generation, crash triage, and code exploration, but validating exploitability, disclosure ethics, and remediation remain human. The real risk is not replacement: it's the asymmetry between equipped attackers and defenders who are not equipped.

✅ Conclusion

In 48 hours, VicOne demonstrated that the question is no longer whether your robotics stack contains vulnerabilities, but how much time is left before an AI agent finds them — and possibly exploits them — before you do. Audit your simulators and training pipelines this week: that's where your robots' security is now at stake.