AMR Cybersecurity: How a CVSS 9.8 Flaw and 20 MiR Bugs Exposed Warehouse Robots in 2026

Diagram showing a warehouse AMR connected to the factory network with an exposed vulnerability at the connection point, illustrating how an autonomous mobile robot functions as just another networked industrial asset with a real attack surface.

AMR cybersecurity vulnerabilities are no longer a theoretical risk: in 2026, Universal Robots disclosed CVE-2026-8153, a CVSS 9.8 unauthenticated command-injection flaw in its PolyScope 5 controller software, while Mobile Industrial Robots (MiR)'s own security advisories page lists 20 disclosed vulnerabilities across two rounds — a newer batch of six from 2025, plus an earlier, already-public batch of 14 that Alias Robotics first disclosed back in 2020-2021. Both disclosures point to the same underlying problem — an AMR is functionally an industrial PC on wheels, with a web dashboard, a network stack, and often default credentials, riding on a mobile chassis that nobody thinks to patch the way they'd patch a server. This article walks through what was actually disclosed, why the standards landscape still doesn't fully cover AMR-specific network security, and how to apply the same zone-and-inventory discipline OT security teams already use on fixed plant-floor assets.

By The Whitepaper Skeptic — AMR fleet evaluation plus OT security architecture review experience

Quick Facts

Question	Answer
Most severe 2026 AMR-adjacent CVE	CVE-2026-8153 — Universal Robots PolyScope 5, CVSS 9.8, unauthenticated OS command injection via the Dashboard Server port, patched in 5.25.1, discovered by Vera Mens of Claroty Team82, advisory published by CISA as ICSA-26-134-17
MiR disclosure batch size	20 disclosed vulnerabilities across two rounds on Mobile Industrial Robots AMRs and downstream resellers of the same platform: 6 new CVEs in 2025 (open redirect, information disclosure, path traversal, XSS, insufficient authorization, command injection) plus a 14-CVE legacy batch Alias Robotics disclosed in 2020-2021 (default/hardcoded credentials, unauthenticated interfaces, kernel flaws)
Regulatory driver already in force	EU RED Directive cybersecurity requirements (Delegated Regulation (EU) 2022/30, Articles 3.3(d)(e)(f)) became mandatory 1 August 2025 for any wirelessly-connected AMR sold in the EU
Standards gap	ISO 3691-4:2023 is a functional-safety standard and does not substantively address cybersecurity; a separate draft standard, EN 50742 ("Safety of machinery — Protection against corruption"), is in CENELEC DIS ballot as of late 2025/early 2026, expected to publish around October 2026, and is targeted for harmonization under the Machinery Regulation ahead of the January 2027 deadline
Machinery-side compliance deadline	Machinery Regulation (EU) 2023/1230 applies from 20 January 2027 — with no transition period — and introduces binding cybersecurity-inclusive essential requirements for machinery placed on the EU market from that date

Why an AMR Is a Cybersecurity Target, Not Just a Safety Concern

Every AMR spoke on this blog up to now — sensor fusion, ROI, fleet management software, VDA 5050 interoperability, ANSI/ITSDF B56.5, RaaS pricing — has treated the robot as an operations and physical-safety problem: can it navigate, does it pay back its cost, will it stop before it hits someone. None of them treat it as a network endpoint. That's the gap this article fills.

Strip away the mobility and an AMR is a Linux or Windows-based industrial PC with a web-based control dashboard, Wi-Fi or 5G connectivity, a cloud fleet-management link, and — per both 2026 disclosures — the exact class of flaws (default credentials, unauthenticated command execution, insufficient authorization) that industrial cybersecurity frameworks like IEC 62443 were written to prevent in fixed OT assets such as PLCs and HMIs. The difference is that a PLC sits in one cabinet behind (ideally) a defined conduit, while an AMR moves between zones by design — crossing from a picking aisle to a charging dock to a loading bay, potentially bridging network segments a fixed asset never would.

The CVE-2026-8153 Universal Robots Flaw, Explained

Universal Robots disclosed CVE-2026-8153 in its PolyScope 5 controller software: an unauthenticated OS command injection vulnerability reachable through the Dashboard Server port, carrying a CVSS score of 9.8. The flaw was discovered by Vera Mens of Claroty Team82 and patched in PolyScope version 5.25.1. CISA published its own advisory for the flaw (ICSA-26-134-17), independently corroborated by SecurityWeek, SC Media, TechRadar, and Manufacturing Business Technology. Exploitation requires the Dashboard Server to be network-reachable — meaning a properly segmented network with the robot's management interface kept off any internet-facing or flat production network meaningfully reduces exposure even before the patch is applied. CISA notes no known public exploitation had been reported as of the advisory date.

Universal Robots builds cobot arms rather than mobile AMR chassis, so this specific CVE isn't a warehouse-robot vulnerability in the strictest sense — but it's the sharpest illustration available of the underlying pattern: a robot controller's web dashboard, left reachable on the network, becomes a full command-execution path into whatever the robot is connected to. The same dashboard-exposure pattern is exactly what shows up in the MiR disclosures below, this time on platforms that are warehouse AMRs.

The MiR Disclosure Batch: 20 Vulnerabilities Across Two Rounds on a Warehouse Robotics Platform

Mobile Industrial Robots' own security advisories page lists 20 disclosed vulnerabilities across two distinct rounds, and treating them as a single batch understates how long some of these issues have been known. The newer round — six vulnerabilities disclosed in 2025 — is:

CVE-2025-13819 — open redirect
CVE-2025-9229 — information disclosure (verbose error pages)
CVE-2025-8749 — path traversal
CVE-2025-9225 — cross-site scripting (XSS)
CVE-2025-9228 — insufficient authorization (note creation)
CVE-2025-8748 — command injection

That's on top of an earlier, already-public batch: Alias Robotics disclosed 14 vulnerabilities affecting MiR robots and downstream resellers of the same platform back in 2020-2021, publicized as "The Week of Mobile Industrial Robots's Bugs" and covered in CISA's advisory ICSA-21-280-02. That batch — default/hardcoded credentials on wireless access points and the web interface, unauthenticated interfaces, unencrypted artifacts, insecure BIOS/boot configuration, and two Linux kernel vulnerabilities (CVE-2017-7184, CVE-2017-18255) — is still listed on MiR's own advisories page today, meaning any fleet that hasn't been patched or reconfigured since 2021 remains exposed to it. MiR's advisories separately reference CVE-2021-44228 (Log4Shell) as an additional legacy issue tied to the platform's software stack.

None of these 20 individually rivals CVE-2026-8153's 9.8 severity, but the pattern across the newer six — open redirect, path traversal, XSS, insufficient authorization, command injection — maps almost one-to-one onto the OWASP Top 10 web-application vulnerability classes, applied to a robot's own web management interface rather than a conventional web app. That's a meaningful reframe for buyers: evaluating AMR fleet software increasingly means asking the same questions a web-application security review would ask, not just the mechanical/navigation questions this blog's other AMR spokes cover. And the older batch is a reminder that fleet cybersecurity debt doesn't expire on its own — a five-year-old default-credential flaw is exactly as exploitable today as it was in 2020 if the firmware and configuration were never updated.

ISO 3691-4, EN 50742, and IEC 62443: Who Actually Governs AMR Network Security?

Buyers researching "which standard covers AMR cybersecurity" run into a scope confusion that's worth clearing up directly, because the three most commonly cited standards answer different questions:

Standard	What it actually covers	Cybersecurity scope
ISO 3691-4:2023	AGV/AMR functional safety — physical safe operation, obstacle detection, multi-vendor interoperability	A functional-safety standard; it does not substantively address cybersecurity, and no corroborated primary-source wording supports treating it as containing a cybersecurity provision. Applus+ Laboratories' own ISO 3691-4 compliance-testing page, for example, describes documentary/risk-assessment conformity work under the Machinery Directive and mentions cybersecurity only separately, in the context of RED Directive certification
EN 50742 (draft)	"Safety of machinery — Protection against corruption" — a general machine cybersecurity standard intended to satisfy the Machinery Regulation's cybersecurity-inclusive essential requirements (not AMR-specific, but applicable to AMRs as a class of machinery)	In CENELEC DIS ballot as of late 2025/early 2026 (public-comment draft published by Austrian Standards 15 January 2026); publication targeted around October 2026, with harmonization under the Machinery Regulation expected ahead of the 20 January 2027 application deadline
IEC 62443	Industrial automation and control systems (IACS) cybersecurity — zones, conduits, security levels, applies to any networked industrial asset including AMRs	Comprehensive cybersecurity framework; not AMR-specific, but its zones-and-conduits segmentation model applies directly once an AMR is treated as a networked OT asset

Our ANSI/ITSDF B56.5 explainer covers the physical-safety certification side of AMR standards in depth — that standard, like ISO 3691-4, is about safe mechanical operation, not network security, and shouldn't be confused with a cybersecurity certification when a vendor cites it in a sales conversation. The practical takeaway: no single standard currently gives an AMR buyer the equivalent of a cybersecurity certification the way IEC 62443 conformance does for a fixed OT asset. Until EN 50742 publishes and is formally harmonized (targeted for around October 2026, ahead of the Machinery Regulation's January 2027 deadline), applying IEC 62443's zones-and-conduits logic to the AMR fleet directly is the closest thing to a comprehensive framework available today.

Treat the AMR Fleet Like Any Other OT Asset: Inventory, Then Segment

The practical fix mirrors what OT security teams already do for PLCs and HMIs, applied to a mobile asset class most OT programs don't yet inventory at all.

Start with inventory, not a network diagram. You cannot segment what you haven't counted. Our OT asset management guide walks through building an industrial asset inventory when you don't already know what's on the network — the same passive-discovery-first approach applies directly to an AMR fleet, since fleet management dashboards and charging infrastructure often sit on the network with default credentials nobody audited after commissioning. In the OT security architecture reviews I ran across live production networks, the inventory handed to me was always built around fixed equipment — PLCs, HMIs, engineering workstations — and mobile robots, their charging docks, and the fleet-management server were routinely missing from it. Not because anyone decided to exclude them, but because the inventory came from the control-systems side while the robots had been bought as material-handling equipment. A zone diagram drawn from that inventory is already wrong the first time a robot crosses a boundary the diagram shows as closed.

Then apply zones and conduits, not a flat network. An AMR fleet crosses physical zones by design — picking floor, charging dock, staging area — which makes flat, unsegmented network access the default failure mode rather than an edge case. Our IEC 62443 zones and conduits explainer covers the design process in detail: the same logic that keeps a PLC's control-zone traffic off the enterprise network applies to keeping an AMR fleet's dashboard and cloud fleet-management traffic on a defined, monitored conduit rather than bridging every zone the robot physically passes through.

Segmentation, not the robot's own firmware, is the practical near-term control. Patch cadence on robot firmware lags behind conventional IT infrastructure for the same reasons PLC patch cycles lag — vendor certification requirements, uptime pressure, and the operational cost of taking a production robot offline. Until a patch ships and gets validated for the specific fleet, network-level containment (keeping the Dashboard Server and management interfaces off any internet-facing or flat production segment) is the control that actually reduces exposure in the interim, exactly as CISA's own advisory language for CVE-2026-8153 implies.

Where This Overlaps With Your Existing OT Security Vendor Stack

If your organization already runs an OT security monitoring platform, there's a reasonable chance it's already relevant to AMR fleets and you haven't checked. Claroty Team82 — the research team that disclosed CVE-2026-8153 — is the same Claroty compared alongside Dragos and Nozomi Networks in our OT security vendor comparison. That's not a forced link: OT-focused asset-visibility and network-monitoring platforms increasingly extend coverage to converged environments where mobile robots, IoT sensors, and traditional ICS assets share the same network fabric, which is exactly the deployment model that guide walks through. Before assuming AMR fleet security requires a new, separate tool purchase, it's worth confirming whether the platform you already evaluated (or already run) covers wireless/mobile industrial assets in its asset-discovery scope.

FAQ

Q: What is CVE-2026-8153 and how severe is it?
A: CVE-2026-8153 is a CVSS 9.8 unauthenticated OS command injection vulnerability in Universal Robots' PolyScope 5 controller software, reachable through the Dashboard Server port. It was discovered by Vera Mens of Claroty Team82, patched in PolyScope 5.25.1, and CISA published its own advisory (ICSA-26-134-17). Exploitation requires the Dashboard Server to be network-reachable, so proper network segmentation reduces exposure even before patching.

Q: How many vulnerabilities have been found in MiR robots?
A: Mobile Industrial Robots' own security advisories page lists 20 disclosed vulnerabilities across two rounds. Alias Robotics first disclosed 14 of them in 2020-2021 — default/hardcoded credentials, unauthenticated interfaces, unencrypted data, insecure BIOS/boot configuration, and kernel flaws — publicized as "The Week of Mobile Industrial Robots's Bugs" (CISA advisory ICSA-21-280-02). A separate, newer batch of six vulnerabilities — open redirect, path traversal, cross-site scripting, insufficient authorization, command injection, and information disclosure — was disclosed in 2025. MiR's advisories also separately reference CVE-2021-44228 (Log4Shell) as an additional legacy issue.

Q: Is ISO 3691-4 a cybersecurity standard for AMRs?
A: No. ISO 3691-4:2023 is a functional-safety standard covering safe mechanical operation and multi-vendor interoperability; it does not substantively address cybersecurity. A separate draft standard, EN 50742 ("Safety of machinery — Protection against corruption"), is intended to satisfy the Machinery Regulation's cybersecurity-inclusive requirements; as of early 2026 it's in CENELEC DIS ballot, with publication targeted around October 2026 and harmonization expected ahead of the Machinery Regulation's 20 January 2027 deadline.

Q: How do you segment an AMR fleet on the network?
A: Apply the same zones-and-conduits approach used for fixed OT assets: start with a full asset inventory of every robot, dashboard, and charging station on the network, then define zones by function (picking floor, charging, staging) with controlled conduits between them rather than flat network access. See our IEC 62443 zones and conduits guide for the full design process.

Q: Do warehouse robots need to comply with EU cybersecurity regulations?
A: Yes, if wirelessly connected and sold in the EU. The RED Directive's cybersecurity requirements (Delegated Regulation (EU) 2022/30) became mandatory on 1 August 2025 for wirelessly-connected radio equipment, which includes most AMRs. Separately, the EU Machinery Regulation (EU) 2023/1230 applies from 20 January 2027 — with no transition period — and adds binding, cybersecurity-inclusive essential requirements for machinery placed on the EU market from that date.

Sources

Author Bio

The Whitepaper Skeptic led AMR vendor evaluation and fleet strategy work at The Won — assessing multi-vendor AMR platforms on integration risk, not just navigation performance — and separately has direct experience with OT cybersecurity in industrial and smart-factory environments, including customer-facing security architecture reviews that mapped zone boundaries and conduit placement across live production networks. This article is the point where those two experiences intersect: an AMR fleet is exactly the kind of networked industrial asset that OT security architecture review methodology was built to cover, even though most AMR buying guides never mention it.

Search This Blog

Beyond the Whitepaper