Dashboard Server OS command injection

1. Summary

The Dashboard Server network interface of Universal Robots PolyScope 5 improperly neutralizes special elements in user-supplied input before passing it to the underlying operating system, resulting in OS command injection (CWE-78) [1][2]. A remote, unauthenticated attacker with network reachability to the Dashboard Server can execute arbitrary commands on the cobot controller’s general-purpose Linux control box [1][2]. The attack requires no credentials, no user interaction, and is of low complexity (CVSS 3.1 base 9.8; CVSS 4.0 base 9.3) [1][2]. All PolyScope 5 versions prior to 5.25.1 are affected; the fix ships in 5.25.1 [1][2].

2. Affected products & versions

Scope note (read before citing a version): the affected-version threshold was widened from 5.21.1 to 5.25.1 in a later NVD update [1]. The correct affected scope is all versions prior to 5.25.1 — do not cite the earlier 5.21.1 figure, which is stale.

3. The vulnerability in detail

The flaw lives in the Dashboard Server, a network service that runs on the PolyScope 5 controller — the “control box” that drives a Universal Robots collaborative arm. The Dashboard Server is a legitimate, first-party interface: it exists so that operators, HMIs, and integration scripts can send simple text commands to query and control the robot (for example, loading and running programs, powering the arm on/off, or reading state) over the factory network [2][5]. It is a designed-in operational convenience — a text-command control channel — not a hidden or debug surface. That framing matters, because the defect is not that this control channel exists; it is how the channel handles the text it receives.

The root cause is a textbook OS command injection defect (CWE-78). The Dashboard Server accepts user-controlled input over its communication protocol and incorporates that input into a command that is handed to the underlying operating system, without proper neutralization of special elements [2]. In other words, the code that services a Dashboard command builds an OS-level command string (or otherwise passes attacker-influenced text to a shell/interpreter) and trusts the input to be benign. When an attacker embeds injection syntax into a Dashboard request, that syntax escapes the intended command context and is interpreted by the OS as additional, attacker-chosen commands that then run on the robot’s Linux control box [2].

The underlying weakness (CWE-78). OS command injection occurs when a program constructs a command for the operating system’s shell (or a similar command interpreter) by concatenating fixed program text with data that came from an untrusted source, and fails to sanitize or safely quote that data. Command interpreters treat certain characters as control syntax rather than as literal data — a classic illustrative set (for a POSIX shell) includes ;, |, &, backtick, $, and newlines, though the exact metacharacters accepted here are undocumented. If control characters reach the interpreter unescaped, the attacker is no longer supplying an argument — they are supplying code. The defect is not that the Dashboard Server exposes commands (that is by design); it is that it fails to enforce the boundary between the data a caller provides and the command the OS ultimately executes.

The data/code boundary, and the safe-vs-unsafe handler contrast. A correctly written Dashboard handler treats everything after the command keyword as an opaque parameter — a program name to load, a state to query — and passes it to the OS only through an interface that keeps data and code separate: parameterized exec-style calls that hand the argument to the target process directly (no intervening shell), strict allow-lists of permitted values, or rigorous safe-quoting/escaping. Under any of those disciplines, an argument containing shell punctuation is simply a weird-looking value; it never becomes syntax. The vulnerable handler instead lets the parameter bleed into a command string that a shell (or shell-like interpreter) parses, collapsing the data/code boundary. Once that boundary is gone, a payload shaped like a legitimate-looking argument followed by an injection sequence (conceptually, <benign arg>; <attacker command> or $(<attacker command>)) causes the interpreter to run the attacker’s command in addition to, or instead of, the intended one. The vendor’s own description — unsanitized user input reaching an OS command — is precisely this boundary failure [2].

Why this class is easy to reach and hard to accidentally mitigate. Unlike memory-corruption bugs, command injection needs no precise offsets, no defeating of ASLR/stack canaries, and no probabilistic grooming. The interpreter does the attacker’s work: it faithfully parses whatever crosses the boundary. There is nothing to “get lucky” on — a syntactically valid payload deterministically executes. That determinism is what makes a single request sufficient, and it is why partial input filtering (blocking one or two characters) tends to fail: the interpreter offers many equivalent injection forms, and any one that survives filtering re-collapses the boundary. Only structural fixes — never handing attacker-influenced text to a shell, or constraining it to an allow-list — actually close the class. This is why the vendor’s remediation is a code fix in 5.25.1 (§7), not a filter.

What is and is not documented about the code. The specific vulnerable file, function, source path, and the exact injectable Dashboard command field are not documented in the available sources, and it is likewise undocumented which command interpreter is invoked, what the exact injection syntax is, and whether the injected commands execute as root or as a limited service account. What is firmly established by the vendor is the class and location of the defect: unsanitized, user-controlled Dashboard input reaching an OS command on the controller [2].

Mechanism and trigger / preconditions. The preconditions are minimal, which is what makes this defect easy to reach. The Dashboard Server must be enabled/operational and its network port must be reachable by the attacker [4]. Beyond that: no authentication is required (PR:N), no user interaction is required (UI:N), and attack complexity is low (AC:L) [1]. The attack vector is the network (AV:N) — no physical or RF adjacency is needed [1]. UR robots are not designed for direct Internet exposure, but the defect is fully reachable across internal and factory LANs, which Claroty’s researcher notes are often flat and unsegmented [2][5].

Step-by-step trigger chain [2][4][5]:

1. The attacker gains a foothold on the internal/OT network reachable to the PolyScope 5 controller. Per Claroty, because such networks are frequently flat and lack segmentation, obtaining this initial foothold may not be difficult [5].
2. The attacker locates a PolyScope 5 controller with the Dashboard Server enabled and its network port reachable [4].
3. The attacker sends a crafted Dashboard Server command containing an OS-command-injection payload (special interpreter elements) over the Dashboard Server communication protocol — with no credentials [2].
4. The Dashboard Server passes the unsanitized input to the underlying OS, executing the attacker’s commands on the robot’s general-purpose Linux control box [2].
5. The attacker obtains arbitrary command execution on the controller OS.

At that point the injected input has crossed from data into executed code, and the trigger is complete. What that command-execution primitive can then be used to do — influence robot motion, pivot across a fleet, its human-safety implications — is consequence analysis and is treated in §6, not here.

A security engineer reading this should take away: this is not a memory-safety puzzle or a multi-stage chain requiring luck. It is a single, unauthenticated, low-complexity network request against a legitimate robot-control interface that collapses the data/code boundary and yields arbitrary command execution on the controller OS. It is deterministic — a valid payload runs, every time, with no probabilistic step.

4. Discovery & timeline

The vulnerability was discovered and reported by Vera Mens of Claroty Team82 [2][3]. Disclosure was coordinated through CISA and CERT/CC VINCE, and CISA published the official ICS advisory as ICSA-26-134-17 [3]. The NVD/vendor advisories were published in 2026, and NVD notes that the affected-version threshold was updated from 5.21.1 to 5.25.1, widening the reported scope [1]. Universal Robots delivered the fix in PolyScope 5.25.1 [2].

Exact publication/disclosure dates conflict across public advisories and are not reliably established: the reported dates for the version-threshold update and the advisory publication span May 8–11, 2026 and June 17, 2026. No single date is asserted here; the authoritative NVD/CISA records give the definitive timeline.

5. Technical reference

This section is a neutral metrics reference only; cross-boundary and consequence reasoning is in §6.

• CVE: CVE-2026-8153 [1]
• CWE: CWE-78 — Improper Neutralization of Special Elements used in an OS Command (OS Command Injection) [1]
• CISA ICS advisory: ICSA-26-134-17 [3]
• CVSS 3.1 base: 9.8 — vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H [1]
• CVSS 4.0 base: 9.3 [2]
• What the key CVSS metrics mean here (definitions only): AV:N — reachable over the network (no adjacency); AC:L — a single crafted request suffices, no special conditions; PR:N — no credentials needed; UI:N — no operator action needed; S:U — CVSS “scope” is unchanged, meaning the score is computed within the vulnerable component’s own security authority; C:H/I:H/A:H — full loss of confidentiality, integrity, and availability of the controller OS.
• Default service port: the specific default listener port for the Dashboard Server is not documented in any available source (not documented in public advisories); the Tenable and vendor pages do not state a port. Exploitation requires only that the Dashboard Server be enabled and its port reachable [4].
• Code/commit refs: not documented — no vulnerable file, function, or commit was surfaced in the reviewed sources.

6. Consequence & CFSE path analysis

Real-world consequence: an attacker on the factory network who can reach an unpatched PolyScope 5 controller can run arbitrary commands on that robot’s Linux control box, change its programs and configuration, and thereby influence the physical motion of a collaborative arm that works alongside people — creating a credible collision/injury hazard — and can repeat that same deterministic request across every reachable controller of the same version [1][2][5]. Because the control box is a general-purpose Linux computer connected via Ethernet and serial to other equipment and legacy field protocols (MODBUS, EtherNet/IP), plus central management/remote-control features, a single compromised unit can be leveraged to reach an entire fleet of cobots and their peripherals [5]. The single-request determinism established in §3 is precisely what makes this fleet-scriptable: there is no per-target luck, so the same payload replays against every same-version controller.

Why the CFSE Path Score differs from CVSS. CVSS 3.1 caps this at 9.8 with S:U (scope unchanged) and scores impact as generic confidentiality/integrity/availability loss on a single component. CFSE path analysis instead decomposes the consequence along the actual authority the flaw confers and follows it across real trust boundaries — network → controller → physical/safety, and one controller → fleet — which CVSS’s single-component, S:U model does not capture. The S:U metric therefore undersells the cross-boundary reality, which is exactly why the CFSE decomposition exists. The result is three co-dominant paths rather than one number.

Carried CFSE bands/verdict from the analysis:

verdict: EMERGENCY. The analysis decomposes CVE-2026-8153 into three co-dominant consequence paths, each scored at the EMERGENCY band.

• DEVICE_CONTROL_SAFETY — reasons that unauthenticated OS command injection on the PolyScope controller can alter the motion of a collaborative arm working near people, creating credible collision/injury risk (PH high, CH crosses network-to-controller-to-physical/safety boundaries).
• FLEET_CONTROL_PLANE — captures the same command authority being scriptable across every reachable controller of the same PolyScope version on flat factory networks, requiring fleet-wide patching/segmentation to recover.
• ACCOUNT_AUTHORITY — the direct terminal of the flaw: full unauthenticated compromise (C:H/I:H/A:H) of the controller OS, granting arbitrary command/service-admin authority to modify programs and configuration, though not the vendor firmware-signing root.

All three share RE:4/EC:4/EX:4 exposure (network-default-exposed, single low-complexity unauthenticated request) and a PATCH_AVAILABLE lifecycle (5.25.1), with EV kept at report-backed because no public weaponized PoC exists. The overall path_verdict is EMERGENCY, driven by the safety-relevant actuation influence.

7. Remediation & mitigations

Grounded, bug-specific actions [1][2][4][5]:

• Upgrade PolyScope 5 to 5.25.1 or later — this is the vendor fix that neutralizes the injection at the code level. Because command injection is a data/code-boundary defect (§3), only a structural fix that stops handing attacker-influenced Dashboard input to an OS command interpreter (or constrains it to an allow-list) actually closes the CWE-78 class; input filtering alone does not. This upgrade is the only action that removes the underlying defect rather than merely limiting reachability [1][2].
• Disable the Dashboard Server if it is not used — exploitation requires the service enabled/operational [4]; if you do not rely on it, turning it off removes this specific attack surface entirely [2][4].
• Restrict Dashboard Server access to trusted hosts/subnets via the PolyScope General tab, so only known integration endpoints (HMIs, integration scripts) can reach the service [2][4].
• Segment and firewall robots off from business/IT networks, and do not expose robot controllers directly to the Internet — this directly counters the flat-network foothold-and-reach path the Dashboard Server sits behind [2][5].
• Treat remediation as fleet-wide: because the same deterministic request reaches every same-version controller, inventory all PolyScope 5 controllers, patch/segment all of them, and verify none remain reachable on flat OT segments [5].

8. Sources

[1] NVD - CVE-2026-8153 — NIST NVD — https://nvd.nist.gov/vuln/detail/CVE-2026-8153 — Canonical CVE record: OS command injection in the Dashboard Server, unauthenticated RCE, CWE-78, CVSS 3.1 9.8 vector, affected versions < 5.25.1, threshold updated from 5.21.1. Credibility: primary advisory.

[2] CVE-2026-8153: Command Injection in the PolyScope 5 Dashboard Server — Universal Robots — https://www.universal-robots.com/articles/ur/cybersecurity/cve-2026-8153-command-injection-in-the-polyscope-5-dashboard-server/ — Vendor advisory: root cause (unsanitized input to OS), fix 5.25.1, CVSS 3.1 9.8 / 4.0 9.3, credit to Vera Mens (Claroty Team82), mitigations, no public exploitation at publication. Credibility: primary advisory.

[3] Universal Robots Polyscope 5 (ICSA-26-134-17) — CISA (ICS-CERT) — https://www.cisa.gov/news-events/ics-advisories/icsa-26-134-17 — Official ICS advisory: government confirmation of vuln, affected versions, CVSS, mitigations, researcher attribution, coordinated via CISA and CERT/CC VINCE. Credibility: primary advisory.

[4] CVE-2026-8153 — Tenable — https://www.tenable.com/cve/CVE-2026-8153 — Operational detail: remote exploitation requires the Dashboard Server enabled and its port reachable; reiterates CVSS scores and remediation to 5.25.1. Does not state a default port. Credibility: reputable press / vuln intel.

[5] Critical Vulnerability Exposes Industrial Robot Fleets to Hacking — SecurityWeek — https://www.securityweek.com/critical-vulnerability-exposes-industrial-robot-fleets-to-hacking/ — Direct Claroty researcher quotes: control box is a general-purpose Linux computer; single-unit-to-fleet escalation; Ethernet/serial, MODBUS/EtherNet-IP, central management widen the surface on flat unsegmented networks. Supports fleet and safety reasoning. Credibility: reputable press.

[6] Patch Now: Critical Flaw in OT Robot OS Gives Attackers Control — Dark Reading — https://www.darkreading.com/ics-ot-security/patch-now-critical-flaw-ot-robot-os — ICS/OT trade coverage framing the flaw as critical OT robot-OS RCE with fleet-takeover risk; corroborates researcher attribution and OT context. Credibility: reputable press.

[7] Critical vulnerability in Universal Robots PolyScope OS allows remote command execution — SC Media (SC World) — https://www.scworld.com/brief/critical-vulnerability-in-universal-robots-polyscope-os-allows-remote-command-execution — Independent press brief corroborating unauthenticated RCE characterization, affected/fixed versions, and criticality. Credibility: reputable press.