[Robotics](https://rankshieldrobotics.com/) / [Blog](https://rankshieldrobotics.com/blog/) Blog / Threat analysis # Why One Credential Can Reach Your Entire Robot Fleet In February 2026 a software engineer trying to drive his own robot vacuum with a game controller ended up holding the cameras, microphones, and floor plans of roughly 7,000 homes across 24 countries [1](#ref-1). He exploited nothing. His own device's token was accepted by the vendor's servers as authority over every other unit [1](#ref-1)[2](#ref-2). That is not a hacking story. It is an authorization story, and the same shape appeared twice more in 2026 at two other layers of the stack. By RankShield Robotics, Robot Security Research | Published August 23, 2026 ## Key takeaways - A single valid token was treated as a master key over ~7,000 robots in 24 countries , exposing live cameras, microphones, and 2D floor plans of private homes [1](#ref-1) . - The root cause was a backend permission validation issue , not a compromised robot [2](#ref-2) . Every device behaved correctly; the control plane granted authority it should not have. - The same failure appeared at the device layer (hard-coded keys shared across a model line [5](#ref-5) ) and the network layer ( CVE-2026-8153 , CVSS 9.8, unauthenticated command execution on Universal Robots controllers [3](#ref-3) ). - The common defect: authority is granted by possession of a credential , never re-checked against this robot and this action. - Bind identity to the individual unit and check every command against a deny-by-default policy, and one compromised credential reaches one robot instead of the fleet. ## What happened when one token reached 7,000 robots? In February 2026 Sammy Azdoufal, who works in AI strategy at a vacation rental company in Spain, bought a DJI Romo robot vacuum and used an AI coding assistant to build an app that would let him steer it with a game controller [1](#ref-1). To do that he had to authenticate to the vendor's cloud. When his app presented the token that identified his own device, the servers did not scope him to his own device. They scoped him to roughly 7,000 Romo units across 24 countries [1](#ref-1). What that reached was not telemetry. Reporting on the incident describes that he "discovered he could tap into live camera feeds, activate microphones, and even compile 2D floor plans of strangers' private homes" [1](#ref-1). A robot vacuum is a mobile sensor platform with a camera, a microphone, and a map of the building it lives in, and the control plane handed all three to a person who was trying to play with a gamepad. He reported it rather than using it, and the story reached the vendor through the press [1](#ref-1). DJI says it "identified a backend validation issue involving the DJI Home app in late January during a routine internal security review," that updates were deployed to fix it, and that it "did not identify evidence that user data was misused" [2](#ref-2). The company paid a $30,000 bug bounty, and noted that two independent researchers later reported the same flaw through its program [2](#ref-2). ## Was that a hack, or the system working as designed? It was the system working as designed, and that is the uncomfortable part. No exploit chain was executed, no malware ran, no zero-day was burned. A legitimate credential was presented to a legitimate endpoint and the endpoint answered the wrong question. It asked whether the token was valid. It never asked whether the holder of that token had authority over the specific robot being addressed [1](#ref-1)[2](#ref-2). This distinction decides what fixes the problem. If it were an exploit, the answer would be a patch and a scanner. Because it is an authorization design, the answer is a structural change to how commands are evaluated. A vendor can patch this particular endpoint, and the next endpoint, and the one after that, and the underlying model stays the same: possession of a credential equals authority over everything that credential can name. It also lowers the bar for who finds these. Azdoufal was not a security researcher hunting for bugs. He was a hobbyist with a coding assistant and a game controller who wanted his vacuum to do something fun, and he tripped over a fleet-wide authorization gap on the way [1](#ref-1). The interesting question for any operator is not whether a determined attacker could find the equivalent in their stack. It is what an accident would surface. ## Where does a robot fleet actually grant authority? In three places, and 2026 produced a public failure at each one. The cloud control plane decides who may send a command. The device credential decides which software the robot will trust. The controller's own network services decide who may talk to the machine directly. Each of these is an authorization boundary, and each of them defaulted to trusting possession of something rather than verifying a specific principal. Layer | 2026 case | What was accepted as authority | Reach from one credential | Cloud control plane | DJI Romo backend validation issue [1](#ref-1)[2](#ref-2) | A valid device token | ~7,000 robots, 24 countries [1](#ref-1) | Device credential | Unitree BLE and Wi-Fi provisioning [5](#ref-5) | A key hard-coded into the product line | Every unit of the affected models [5](#ref-5) | Controller network service | CVE-2026-8153, PolyScope 5 [3](#ref-3)[4](#ref-4) | Network reachability, no authentication at all [3](#ref-3) | Every cobot on a flat network [4](#ref-4) | The device-layer case is instructive because it needed no server at all. Security research on embodied AI describes flaws combining "hard-coded cryptographic keys, trivial authentication bypass, and command injection in the Wi-Fi setup process," where an attacker in radio range gains root and the compromise spreads wirelessly between units [5](#ref-5). A key shared across a model line is a fleet-wide credential whether or not anyone calls it one. Three authorization layers, three 2026 failures, one shared defect: authority granted by possession rather than verified per robot and per action. ## Why does the blast radius default to the whole fleet? Because fleets are built for operational convenience first, and convenience means one credential that works everywhere. A single key ships in the firmware image so manufacturing does not have to personalize each unit. A single service account drives the whole tenant so the orchestration layer does not have to manage thousands of identities. Each choice is reasonable in isolation, and together they make the fleet a single security domain. The network layer compounds it. Universal Robots states that its cobots "are not designed to be accessible directly from the Internet," which is true and is not the point [4](#ref-4). Claroty researcher Vera Mens observed that "the control box powering the cobot's application layer is a general-purpose Linux computer connected via Ethernet and serial ports to a variety of other equipment," deployed on networks that are frequently "flat and lack proper segmentation" [4](#ref-4). One foothold on that network reaches every controller on it. So the default answer to "how many robots does one compromised credential reach" is "all of them," and it takes deliberate engineering to make that answer smaller. The calculator below lets you put your own numbers against it. Our guide to [security for robot fleet operators](https://rankshieldrobotics.com/industries/robot-fleet-operator-security/) covers the operational side in more depth. ## What does a single compromised credential cost you? More than the hardware, which is the point people miss when they price robot security against unit cost. The Romo line launched at CNY 4,699, roughly $654, for the S and A models and CNY 6,799, roughly $947, for the flagship P [7](#ref-7). Multiply the lower figure by the number of units one token reached and the installed hardware behind that single credential is on the order of four and a half million dollars, spread across 24 countries and inside private homes [1](#ref-1)[7](#ref-7). Item | Cost | What it bounded | One Romo unit, launch pricing | ~$654 to ~$947 [7](#ref-7) | One home | The credential that reached ~7,000 of them | $0, it was his own device's token [1](#ref-1) | Nothing | Bug bounty paid for the report | $30,000 [2](#ref-2) | The disclosure, not the design | Per-device identity plus a pre-actuation gate | A control-layer project, not a capital purchase | One robot per credential | For an industrial fleet the exposure is not privacy, it is production and safety. A compromised PolyScope controller yields "high impact to confidentiality, integrity, and availability" on a machine with a physical envelope [3](#ref-3). The cost of the credential is still zero. The cost of what it reaches is the line, the cell, and whatever a robot arm can touch. ## Does patching the vendor close the gap? It closes that instance and leaves the class open. All three 2026 cases have patches. DJI deployed backend updates that required nothing from users [2](#ref-2). Universal Robots shipped PolyScope 5.25.1 and recommends that operators "minimize network exposure of the robot," place controllers behind firewalls, disable the Dashboard Server interface if unused, and "restrict access to specific trusted hosts or subnet" [3](#ref-3). That is good advice and it should be followed. The limits are worth stating plainly. Patching depends on a vendor finding, fixing, and shipping, and on every operator applying it, and the fix is scoped to the endpoint that failed. Network segmentation is the strongest of the three recommendations and it is also the one most often absent in practice, which is exactly the gap Mens described [4](#ref-4). None of it changes what happens when a valid credential is presented for a robot the holder should not command. You should still patch. You should also stop treating patch currency as the security model, because it makes your exposure a function of how quickly other people ship. See our [firmware attestation](https://rankshieldrobotics.com/solutions/firmware-attestation-rats/) approach for the half of this that is about knowing what is actually running. ## What does per-robot, per-action authorization look like? It replaces one question with three. Instead of asking whether a credential is valid, the control path asks whether this principal is who it claims to be, whether it holds authority over this specific robot, and whether policy permits this specific action on this robot right now. Each check is cheap. Together they turn a fleet-wide credential into a single-robot credential. The first piece is [per-robot identity](https://rankshieldrobotics.com/solutions/robot-identity-attestation/) rooted in hardware, unique to the unit rather than the model line. That alone removes the class of failure where recovering one key compromises every peer, which is the device-layer case above [5](#ref-5). Revocation becomes a per-unit action instead of a firmware campaign, which is what makes seconds-scale containment possible at all. The second is a [pre-actuation authorization gate](https://rankshieldrobotics.com/solutions/pre-actuation-authorization-gate/). Commands are evaluated before they reach an actuator, high-consequence actions are deny by default and must be explicitly allow-listed, and an instruction from an unrecognized principal is refused rather than logged after the fact. This is the control that would have been standing between Azdoufal's token and 6,999 robots that were not his. To be clear about the boundary: none of this makes a robot unhackable, and it does not remove the need to patch, segment networks, or run physical safety systems. It bounds consequence. A compromised credential behind a per-robot gate is still a compromised credential. What it can no longer do is command machines it was never issued for. ## How do you verify a fix you were told was deployed? This is the quiet problem in all three cases, and it is the one operators have the least tooling for. In the Romo incident, reporting noted that the vendor's confirmation that the flaw was fixed arrived shortly before thousands of robots, including a journalist's own review unit, were observed still reporting in [1](#ref-1). DJI's own account is that remediation began in late January after an internal review and that updates were deployed [2](#ref-2). Both things are in the public record, and an operator on the outside had no way to settle it. That is not primarily a question of who was right. It is that "the vendor says it is fixed" and "I can demonstrate it is fixed" are different epistemic states, and most fleet operators only ever have the first. When the asset is a machine with a camera in someone's home or an arm on a production line, the difference matters to your liability, your insurer, and your regulator. The answer is a record neither party can quietly edit. [Tamper-evident action provenance](https://rankshieldrobotics.com/solutions/robot-action-provenance/) produces evidence of which attested robot was authorized to do what and when, so a remediation claim becomes checkable rather than a statement you accept. It is also the evidence the [EU Machinery Regulation](https://rankshieldrobotics.com/compliance/eu-machinery-regulation-2023-1230-cybersecurity/) technical file will expect from 2027. ## What should a fleet operator check this week? Three things, in order. First, find out whether any credential in your fleet is shared across more than one robot, including keys baked into a firmware image, service accounts used by orchestration, and API tokens issued per tenant rather than per device. Second, ask your vendor in writing what their control plane validates before it accepts a command, and specifically whether a token is bound to an individual robot. Third, measure how long a fleet-wide revocation actually takes you today, by trying it on one unit. The calculator below turns those answers into a number. Set your fleet size, your credential model, what your control plane checks, and your revocation speed, and it shows how many robots one compromised credential reaches and how fast you could contain it. It is a planning estimate rather than an audit, and everything runs in your browser. Interactive tool ### Credential Blast Radius Calculator How many robots does one compromised credential reach in your fleet, and how fast could you contain it? Nothing you enter leaves your browser. Fleet size 7000 How is the robot's credential issued? One credential shared across a model line or product familyOne credential per site or per tenantA hardware-rooted credential unique to each robot What does the control plane verify before it accepts a command? The control plane checks that the token is validThe control plane checks the token is bound to that specific robotEvery command is checked against the robot and an action policy, deny by default How fast can you revoke a suspect robot, fleet wide? Days, via a vendor firmware campaignHours, via a manual consoleSeconds, via a revocation list the gate reads BLAST RADIUS OF ONE COMPROMISED CREDENTIAL 7000robots reachable Download your blast radius assessment ## Frequently asked questions about robot fleet credentials and blast radius **What actually caused the DJI Romo robot vacuum incident?** A backend authorization failure, not a device compromise. An engineer building a game-controller app for his own Romo authenticated to the vendor cloud, and the servers accepted his single device token as authority over roughly 7,000 units in 24 countries, exposing live cameras, microphones, and 2D floor plans of private homes [1](#ref-1). DJI describes it as a backend validation issue involving the DJI Home app, identified internally in late January 2026 during a routine security review, fixed by updates that required no user action, with no evidence found of user data misuse [2](#ref-2). A $30,000 bounty was paid [2](#ref-2). **Is a robot vacuum really a security concern for a business?** It is a mobile platform with a camera, a microphone, network connectivity, and a stored map of your building, which is the same sensor package that makes any autonomous mobile robot useful. It is also treated that way in regulation: under the FCC Covered List definition adopted on 28 July 2026, a networked robot vacuum over 4.4 lb meets every element of an advanced robotic device [6](#ref-6). See our guide to [what the FCC rule means for robots you already own](https://rankshieldrobotics.com/blog/fcc-robot-ban-robots-you-already-own/). **What is a credential blast radius?** The number of robots one compromised credential can command. If a key is shared across a model line, the blast radius is every unit of that model. If a control plane validates only that a token is well formed, the blast radius is every robot in the tenant. If the credential is unique to one robot and each command is checked against a policy for that robot, the blast radius is one. The calculator in this article estimates yours from your fleet size, credential model, control plane checks, and revocation speed. **Does network segmentation solve this?** It helps substantially at the network layer and does not address the other two. Universal Robots recommends placing robots behind firewalls, disabling the Dashboard Server interface where unused, and restricting access to trusted hosts or subnets [3](#ref-3). Claroty researcher Vera Mens noted that cobot control boxes are general-purpose Linux computers on networks that are often flat and unsegmented, which is what makes CVE-2026-8153 a fleet problem [4](#ref-4). Segmentation cannot help when the command arrives through the vendor cloud that is supposed to reach the robot. **Is CVE-2026-8153 still a risk if my robots are not on the internet?** Potentially yes. The vulnerability allows an unauthenticated attacker who can reach the Dashboard Server network port to execute commands on the robot operating system, with high impact to confidentiality, integrity, and availability, and it affects PolyScope 5 versions before 5.25.1 [3](#ref-3). Universal Robots notes its cobots are not designed for direct internet access, but researchers observed that flat internal networks let one foothold reach many controllers [4](#ref-4). Update to 5.25.1 or newer, then segment. **How would per-robot authorization have changed the Romo outcome?** The token would have named one robot. A control plane that binds a credential to a specific device and checks each command against that binding cannot return 6,999 other people’s robots, because the request would fail the binding check before any camera or microphone was addressable. Adding a deny-by-default policy on high-consequence actions bounds it further: even a correctly bound principal has to be explicitly permitted to stream a camera or drive the unit. **What does RankShield Robotics actually provide here?** We do not build robots, robot hardware, or ROS integrations, and we do not patch vendor firmware. We build the attestation and authorization layer over robot command and telemetry streams: hardware-rooted identity unique to each unit rather than the model line, a deny-by-default pre-actuation gate that evaluates each command against the robot and an action policy before an actuator moves, revocation that is read on the next command rather than the next firmware campaign, and tamper-evident provenance that makes a remediation claim checkable instead of something you take on faith. ## References - Fortune. One man accidentally gained access to thousands of robot vacuums, exposing the AI cyber nightmare risk facing millions of Americans . 25 February 2026. [fortune.com/2026/02/25/who-is-sammy-azdoufal-robot-vacuum-cl](https://fortune.com/2026/02/25/who-is-sammy-azdoufal-robot-vacuum-cleaner-access-to-thousands-cyber-ai-agent-risk/) - DroneDJ. DJI fixes ROMO security bug that exposed thousands of homes . 10 March 2026. [dronedj.com/2026/03/10/dji-romo-security-bug-bounty/](https://dronedj.com/2026/03/10/dji-romo-security-bug-bounty/) - Universal Robots. CVE-2026-8153: Command Injection in the PolyScope 5 Dashboard Server . 11 May 2026. [www.universal-robots.com/articles/ur/cybersecurity/cve-2026-](https://www.universal-robots.com/articles/ur/cybersecurity/cve-2026-8153-command-injection-in-the-polyscope-5-dashboard-server/) - SecurityWeek. Critical Vulnerability Exposes Industrial Robot Fleets to Hacking . 2026. [www.securityweek.com/critical-vulnerability-exposes-industri](https://www.securityweek.com/critical-vulnerability-exposes-industrial-robot-fleets-to-hacking/) - Recorded Future. Hacking Embodied AI . 2026. [www.recordedfuture.com/research/hacking-embodied-ai](https://www.recordedfuture.com/research/hacking-embodied-ai) - Federal Communications Commission. FAQs on Recent Updates to FCC Covered List Regarding Foreign-Produced Advanced Robotic Devices and Power Inverters . Updated 28 July 2026. [www.fcc.gov/covered-list-faqs-robots-inverters](https://www.fcc.gov/covered-list-faqs-robots-inverters) - Vacuum Wars. DJI Enters the Robot Vacuum Market with the Romo Series . 2025. [vacuumwars.com/dji-romo-series/](https://vacuumwars.com/dji-romo-series/) ## Keep exploring [SOLUTIONPre-actuation authorization gate](https://rankshieldrobotics.com/solutions/pre-actuation-authorization-gate/)[SOLUTIONRevocation and kill switch](https://rankshieldrobotics.com/solutions/robot-kill-switch-dead-man-credential/)[BLOGThe FCC rule and your existing fleet](https://rankshieldrobotics.com/blog/fcc-robot-ban-robots-you-already-own/) ## Make one credential reach one robot. Per-robot identity, deny-by-default pre-actuation authorization, and revocation measured in seconds. [Request early access](https://rankshieldrobotics.com/request-access/) This article is for general information and does not constitute legal, compliance, or incident-response advice. Vulnerability details, patch status, and vendor statements change; confirm the current status of CVE-2026-8153 and any vendor remediation against the vendor advisory and your own environment before acting. Incidents described here are reported by the sources cited, are attributed to them in the references, and are discussed at the level of authorization design rather than exploitation detail.