PolyScope 5's 9.8 Bug Hits 6 of 9 UR Cobots We Track
CVE-2026-8153 is a 9.8-severity flaw in Universal Robots' PolyScope 5. Our database shows 6 of 9 UR cobots run the exposed software.
On May 19, 2026, Universal Robots disclosed CVE-2026-8153, a critical OS command injection vulnerability in PolyScope 5’s Dashboard Server interface. CVSS 3.1 score: 9.8. CVSS 4.0 score: 9.3. An unauthenticated attacker with network access to the Dashboard Server port can execute arbitrary commands on the robot controller, no login required. We checked our own database. Of the 9 Universal Robots cobots we track, 6 run PolyScope 5, the exposed software line. The other 3 run PolyScope X, a different architecture that wasn’t exposed to this particular flaw.
That’s 66.7% of the UR lineup sitting on the vulnerable generation as of the disclosure date. If you run a mixed UR fleet, and most integrators do, this isn’t an abstract advisory. It’s a per-robot patch checklist.
What exactly is CVE-2026-8153?
The vulnerability lives in the Dashboard Server, the network interface PolyScope 5 uses to accept remote commands like load program, play, stop, and power on/off. The flaw lets an attacker on the same network send a specially crafted command that gets passed to the underlying OS shell instead of being handled safely, full remote code execution on the controller, no credentials needed. It was discovered and reported by Vera Mens of Claroty Team82, and covered independently by SecurityWeek. Universal Robots patched it in PolyScope 5.25.1, and the flaw is also tracked as an official ICS advisory by CISA.
If your robot has network access to anything, and controllers on a manufacturing line usually do, “unauthenticated” is the word that should get your attention. This isn’t a phishing-your-operator scenario. It’s a plug-into-the-network-and-go scenario.
Which UR cobots are actually exposed?
Here’s the full lineup, cross-referenced against our spec database:
| Robot | Payload | Reach | Software | Exposed to CVE-2026-8153? |
|---|---|---|---|---|
| UR3e | 3 kg | 500 mm | PolyScope 5 (e-Series) | Yes, versions before 5.25.1 |
| UR5e | 5 kg | 850 mm | PolyScope 5 (e-Series) | Yes, versions before 5.25.1 |
| UR7e | 7.5 kg | 850 mm | PolyScope 5 (e-Series) | Yes, versions before 5.25.1 |
| UR10e | 12.5 kg | 1,300 mm | PolyScope 5 (e-Series) | Yes, versions before 5.25.1 |
| UR12e | 12.5 kg | 1,300 mm | PolyScope 5 (e-Series) | Yes, versions before 5.25.1 |
| UR16e | 16 kg | 900 mm | PolyScope 5 (e-Series) | Yes, versions before 5.25.1 |
| UR15 | 17.5 kg | 1,300 mm | PolyScope X | No, different Dashboard Server architecture |
| UR20 | 20 kg | 1,750 mm | PolyScope X | No, different Dashboard Server architecture |
| UR30 | 35 kg | 1,300 mm | PolyScope X | No, different Dashboard Server architecture |
Six of nine. Every e-Series arm in the current lineup, from the 3 kg UR3e up through the 16 kg UR16e, runs PolyScope 5 and needed the patch. The three newest arms, UR15, UR20, and UR30, run PolyScope X and sidestep this specific bug.
Source: our analysis of 9 robots in the Industrial Robotics Hub database, cross-referenced against Universal Robots’ CVE-2026-8153 advisory.
Why isn’t PolyScope X affected by this specific CVE?
Careful with the framing here, because it’s easy to overclaim. PolyScope X isn’t affected by CVE-2026-8153 specifically because it didn’t inherit the vulnerable code path, not because it’s been proven more secure in some general sense.
Per Universal Robots’ own ROS 2 driver documentation, PolyScope X (versions 10.x.y, running on the newer CB5.6 controller) did not support the Dashboard Server interface at all, the exact attack surface named in the CVE, until it got its first Robot API implementation in version 10.11.0. That implementation replaces the old Dashboard Server model rather than reintroducing it. PolyScope 5 (versions 5.x.y, running on CB5.5 or earlier) is the classic e-Series software line and the one directly named in the advisory.
This is an architectural difference, not a maturity difference. PolyScope X is a newer platform that happened not to carry the vulnerable interface forward. Whether it has its own undiscovered issues is a separate question nobody can answer yet. Don’t read “not exposed to this CVE” as “inherently safer.”
What should a buyer or integrator do?
Universal Robots and CISA both point to the same set of mitigations:
- Upgrade to PolyScope 5.25.1 or later on every e-Series arm still running an older build.
- Place the robot and other control-system devices behind firewalls, and minimize network exposure generally.
- Disable the Dashboard Server interface entirely if your cell doesn’t actually use it.
- Restrict access to specific trusted hosts or a dedicated subnet rather than leaving the port open to the whole plant network.
None of that is exotic. It’s the same OT network hygiene that’s been standard advice for years. What’s new is that this CVE gives it a hard number attached: a named researcher, a CVSS score, a fixed version. It’s no longer “you should probably segment your OT network.” It’s “here is the exact bug that walks through an unsegmented one.”
Why this matters beyond one patch
IFR named cybersecurity, specifically a rise in hacking attempts against robot controllers and cloud platforms, as one of its Top 5 Global Robotics Trends 2026. That release didn’t publish a single hard number to back the claim. CVE-2026-8153 is the first concretely quantified instance behind that trend: a named CVE, a CVSS score, a fixed version, a named researcher. The industry has spent a year saying “robot cybersecurity risk is rising” without receipts. This is a receipt.
We mapped the PolyScope 5 vs PolyScope X split three days ago in Robot Controllers: One Brand Doesn’t Mean One Platform, where Universal Robots showed up as “mid-transition,” 6 e-Series arms on the old platform, 3 newer arms on the new one. That post framed the split as a compatibility and feature question: which programs run where, which features ship first on which platform. This post is the same 6/3 split viewed through a security lens, and the lens changes the answer. A fleet with mixed UR generations, which is the common case given the split we found, means different robots in the same cell need different patch and network-segmentation postures. Same brand, same reseller relationship, different exposure.
A buyer or integrator running a security audit can no longer just ask “is this a UR cobot.” They need the specific PolyScope version on the specific arm. The software generation on the controller is now a line item in your OT security posture, not just a feature-parity checkbox on a spec sheet.
FAQ
Is my UR cobot affected by CVE-2026-8153? If it runs PolyScope 5 (any e-Series arm: UR3e, UR5e, UR7e, UR10e, UR12e, UR16e) and hasn’t been updated to version 5.25.1 or later, yes. If it runs PolyScope X (UR15, UR20, UR30), it’s not exposed to this particular vulnerability.
Does upgrading to PolyScope X fix the vulnerability? There’s no in-place upgrade path from e-Series hardware to PolyScope X, they run on different controller generations (CB5.5 vs CB5.6). The fix for existing e-Series arms is the 5.25.1 software patch, not a platform switch.
Was this vulnerability exploited in the wild? The public advisories describe a disclosed and patched flaw, not a confirmed in-the-wild exploitation campaign. Treat it as a real, high-severity risk regardless: a 9.8 CVSS score on an unauthenticated remote-code-execution path is serious whether or not an attack has been publicly attributed yet.
Compare these robots