Products Lemma APIProof issuance & verification platformTrust402Delegate to agents, and transactSealSign-in for the agent era — no keys handed over
Use cases Manufacturing & Critical InfraInspection Record AssuranceFinance & FinTechCounterparty Record VerificationPublic SectorCertificate-less ProceduresHealthcareQualified Worker AssuranceProcurement & Supply ChainSupplier Credential MonitoringMedia & ContentContent AuthenticityService & RetailCross-group IdentityAI Adoption (cross-industry)AI Run GovernanceDevelopers & Agent OpsAgent Authority Control ▸ Browse the use-case index
Pricing
Resources Critical BriefThe frontier of AI × trustBlogThinking and implementation notesDocumentationAPI & specsVerification CenterReal verification & issuance countsAbout usFRAME00, Inc.ContactSales & press inquiriesGlossaryDefinitionsFAQFrequently asked questions
Dashboard ↗ JA
Home / Critical Brief / No. 068
No. 068 Critical Brief · Agent Authority Proof

Universal Robots PolyScope: unauthenticated network access alone allowed arbitrary code to run on the cobot's OS (CVE-2026-8153, CISA)

9.8CVSS 3.1
Severity (Critical). 9.3 on CVSS 4.0. No authentication needed
29999TCP
Default listening port of the Dashboard Server. Reaching it over the network was enough
5.25.1
The fixed PolyScope 5 release. Earlier versions are affected
CountryGlobal
Incident date2026-05-14
Published2026-06-19
AuthorsLemma Critical Team
Contents
  1. 01Summary
  2. 02What got through
  3. 03Pre-execution check
  4. 04What Lemma does
  5. 05Facts and timeline
  6. 06Sources

Summary

CISA warned that PolyScope 5 (before 5.25.1), the control software for collaborative robots, carries a flaw (CVE-2026-8153) by which an unauthenticated attacker can run arbitrary code on the robot’s OS. No exploitation in the wild had been reported at the time of writing. Even so, on robots that had not been patched, reaching the listening port over the network was enough to run commands on the OS. A command arriving over the network and its sender being allowed to operate the machine are separate facts; on a device where arrival counts as authority, a hole at the entry becomes control.

Exhibit 1Detection vs pre-execution check

A pre-execution check means checking, before a command that leads to physical motion runs, that the sender is allowed to operate the machine, and keeping a record. Detection means noticing after a flaw or anomaly surfaces. The date below is when CISA published its advisory, not necessarily when the flaw became exploitable.

Pre-execution check · not known from the disclosuresCheck that the sender is allowed to operate the machine before a command runs
What was confirmedWith no authentication, network reach alone
could run commands on the OS
Detection · workedThe flaw was found, and CISA and the vendor issued advisories
BEFORE
A flaw passing input to the OS unneutralised
05-14
CISA publishes its advisory
AFTER
Update to 5.25.1 and segment
AT WRITING
No exploitation in the wild reported

What got through

What got through
Crafted input that reached the Dashboard Server port (TCP 29999 by default), and the arbitrary commands it ran on the robot’s OS. The input was passed to the OS without neutralising special characters. All the attack needed was network reachability; no authentication was demanded (per CISA and Universal Robots).
What reached the receiving side
In general, a command that reaches control software carries no information on whether its sender holds authority to operate the machine. From the receiving side, you cannot tell whether a command that arrived over the network comes from someone allowed to operate it.
What was stopped
On robots running the fixed release (PolyScope 5.25.1), the flaw is fixed (per Universal Robots). Network segmentation and blocking exposure of the Dashboard Server port were also given as mitigations.
Not disclosed
Exploitation in the wild (none reported at the time of writing). Altered control logic or disrupted operation after code execution on the robot OS are plausible impacts, not confirmed harm.

Pre-execution check

Whatever the route, the condition for telling them apart is that whoever carries out a command that leads to physical motion checks, before it runs, that the sender is allowed to operate the machine, wherever on the network the command came from.

The core of this case
A command arriving over the network and its sender being allowed to operate the machine are separate facts; on a device where arrival counts as authority, a hole at the entry becomes control.
Who approves
Whoever decides who may operate the robot, such as the person responsible for its operation. Who may start it, run it or load a program, and within what scope, is decided outside the robot.
Where it is checked
One point just before a command that leads to physical motion runs. A command from the internal network and one from outside pass the same check. A command that does not match a permission is stopped, not run.
What is recorded
Which permission allowed whose command to run as which motion, kept apart from the record of network reach.

The advisory and the fixed release address the flaw that was found; they are not a mechanism that checks the sender of a command that arrives. Another case where an entry point with no authentication led to actions on a business platform is ServiceNow’s unauthenticated API (the requester’s authorisation was not checked before the action ran).

What Lemma does

Lemma builds the pre-execution check into the side that carries out commands leading to physical motion. It does not look for flaws or intrusions; it checks, before a command runs and whatever the network path, whether its sender is allowed to operate the machine.

Industries and operations to watch

IndustryManufacturing
Organisations that run collaborative robots on manufacturing and logistics floors. The robot’s control software has an entry point reachable over the network.
OperationStarting, running and loading programs on robots
Commands that lead to physical motion. That a sender reached the network does not show it is allowed to operate the machine.

Current controls vs Lemma

The route in this case is a command that leads to physical motion, arriving over the network.

ControlCommand leading to physical motion, arriving over the network
Applying the fixed release (PolyScope 5.25.1 or later)Partial
Network segmentation and blocking exposurePartial
Anomaly detection (after the motion)Not effective
Lemma (pre-execution check)Effective

Applying the fixed release closes this flaw, but it is not a mechanism that checks the sender of a command that arrives. Segmentation narrows who can reach the robot, but the robot does not thereby check whether the party that reached it is allowed to operate it. Anomaly detection comes after the command has run and the motion has happened, and the result cannot be undone. Lemma checks commands that lead to physical motion, before they run, against whether the sender is allowed to operate the machine. A record of what ran is also kept, so which motion happened under which permission can be confirmed without relying on a record of network reach alone.

Note: Lemma’s check works only when it is built in just before commands such as start, run and load-program, and the record of permissions is managed outside the robot. A party running code on the robot’s OS may be able to cause motion without passing this check. The table compares what each control checks; it does not show whether this incident would have been stopped. Lemma does not detect or prevent intrusions.

CheckChecklist

Three things to confirm in your organisation about control devices (robots)

  • Are your PolyScope 5 robots on 5.25.1 or later?
  • Do you know from where on the network the Dashboard Server port can be reached, and have you closed the ranges you do not need?
  • Is there a step that checks, before a command runs, that its sender is allowed to operate the robot, even for commands from the internal network?

Facts and timeline

Target
PolyScope 5 (versions before 5.25.1), the control software for Universal Robots’ collaborative robots (cobots), the control foundation of industrial robots widely deployed on manufacturing and logistics floors.
Disclosing party
CISA (industrial control systems advisory ICSA-26-134-17, 2026-05-14). Universal Robots also published an advisory for the same vulnerability. The finder is Vera Mens of Claroty Team82.
Vulnerability
CVE-2026-8153 (OS command injection, CWE-78). CVSS v3.1 base score 9.8 (Critical); CVSS v4.0 base score 9.3.
Core of the technique
PolyScope’s Dashboard Server interface passed user-supplied input to the OS without neutralising special characters. An unauthenticated attacker who can reach the Dashboard Server port over the network (the default listener is TCP 29999) could run arbitrary commands on the robot’s OS via crafted input.
What it required
Not authority to operate the robot, but only network reachability to the Dashboard Server port. No authentication is demanded.
Plausible impact
Arbitrary code execution on the robot OS can lead to altered control logic, disrupted operation and a foothold for lateral movement. It opens room for a robot on a manufacturing line to act on an attacker’s instruction.
Fix
Universal Robots released the fix in PolyScope 5.25.1.

Glossary
Collaborative robot (cobot) — An industrial robot designed to work in the same space as people. Universal Robots' products are widely deployed on manufacturing and logistics floors.
OS command injection — A flaw where input received from outside is run as part of an OS command without being neutralised.
Dashboard Server — PolyScope 5's network-facing interface. It listens on TCP 29999 by default.

Timeline

(Before)
A flaw existed in PolyScope 5’s Dashboard Server, passing input to the OS without neutralising it.
2026-05-14
CISA publishes industrial control systems advisory ICSA-26-134-17, warning of CVE-2026-8153 (CVSS 9.8). Universal Robots also publishes an advisory for the same vulnerability and points to the fix in PolyScope 5.25.1.
After
Operators are advised to update to 5.25.1 and to block or segment network exposure of the Dashboard Server port.

This Brief covers the CVE-2026-8153 vulnerability and its structure; no exploitation in the wild had been reported at the time of writing. The CISA advisory and Universal Robots’ advisory are the dated anchors, and scale and technique are described from the primary sources. What has not been disclosed does not mean there were no controls.

Response after disclosure

Universal Robots
Published a security advisory for CVE-2026-8153 and released the fix in PolyScope 5.25.1. Pointed operators to the update.
CISA
Issued ICS advisory ICSA-26-134-17, publicising the risk of unauthenticated code execution and the mitigations (update, network segmentation, minimising exposure).
Recommendations for OT and industrial-robot operators
Update to PolyScope 5.25.1 or later, block or segment network exposure of the Dashboard Server port, and apply least privilege on the control network.

Sources

References: “The last layer left for cyber defense in the age of AI”

This Brief sets out, from disclosed facts, what organisations in a similar position can check. It is not guidance on individual losses or procedures.

This material is a structured analysis of public information; it is not an audit, diagnosis, or recommendation for any specific organization.

Cite this Brief

Lemma Critical Team. (2026).
"Universal Robots PolyScope: unauthenticated network access alone allowed arbitrary code to run on the cobot's OS (CVE-2026-8153, CISA)".
Lemma Critical Brief No.068. Lemma / FRAME00, Inc.
https://lemma.frame00.com/critical/briefs/068-universal-robots-polyscope-command-injection/
Read nextNext
Same control Good Smile Company: A rogue program on the payment page, and card numbers and security codes may have been exposed Code Provenance Same control LiteLLM: v1.107.0, built from an attacker's fork, was distributed with a genuine signature Code Provenance Latest Binance: Unauthorised withdrawal transactions went through, and crypto was taken Agent Infrastructure
All Briefs →
Lemma

If it can't be verified,
it doesn't enter your operation.

Lemma is a pre-execution check: logins, payments, records and publishing that look genuine are checked before they run, with cryptographic proofs the receiving side verifies without asking the issuer. Detection stays; the check sits in front of it.

Talk to enterprise See the verification center