[Robotics](https://rankshieldrobotics.com/) / [Blog](https://rankshieldrobotics.com/blog/) Blog / Threat analysis # When a Robot CVE Has No Patch, What Do You Actually Do? On 27 August 2026 two unauthenticated root code execution chains were published against a widely deployed humanoid robot, both affecting every firmware version through 1.5.2, and neither CVE record references a vendor advisory or a fixed release [1](#ref-1)[2](#ref-2). The ordinary answer to a critical vulnerability is to patch. When the question "which version do I upgrade to" has no answer, an operator still has to decide what to do on Monday. This is that decision. By RankShield Robotics, Robot Security Research | Published August 28, 2026 ## Key takeaways - CVE-2026-76639 (CVSS 4.0 base 8.7) reaches root over a network-adjacent path; CVE-2026-76640 (base 7.7) reaches root from BLE proximity without pairing or credentials [1](#ref-1) [2](#ref-2) . - Both affect Unitree G1 EDU firmware through 1.5.2 , both are unauthenticated, and both need no user interaction [1](#ref-1) [2](#ref-2) . - Neither CVE record lists a vendor advisory or fixed version, and reporting confirms no fixed firmware release has been verified in accessible vendor guidance [3](#ref-3) . - Both carry CWE-306, missing authentication for a critical function [1](#ref-1) [2](#ref-2) : the third time in 2026 that same weakness class has produced a fleet-relevant robot failure. - Reachability is the lever you own. Both chains are adjacent-access , so segmentation and radio control close them without the vendor, while identity and revocation bound what a compromise reaches. ## What exactly was disclosed on 27 August 2026? Two independent root remote code execution chains against the Unitree G1 EDU humanoid, published by researcher Olivier Laflamme and issued as CVEs on 27 August 2026 through VulnCheck as the assigning authority [1](#ref-1)[2](#ref-2)[3](#ref-3). Both terminate at root on the robot's locomotion PC, which is the computer responsible for how the machine moves. The first, CVE-2026-76639, is described in the CVE record as chaining an unauthenticated WebRTC-to-DDS bridge on TCP port 9991, a static AES-128 key stored with world-readable permissions, and a path traversal flaw in a knowledge upload API, allowing a network-adjacent attacker to execute arbitrary commands as root [1](#ref-1). The second, CVE-2026-76640, chains flaws in the BLE GATT server and the Wi-Fi provisioning stack so that an unauthenticated proximate attacker achieves root "without pairing or credentials" [2](#ref-2). This article stays at the level of exposure and defensive posture. It does not reproduce the exploitation detail, and neither should your internal write-up: the useful artifacts for an operator are the affected versions, the access required, and what closes the path. ## How serious are these two, in the terms that matter to an operator? Serious, and the vector strings tell you more than the numbers do. Both are rated HIGH under CVSS 4.0 by the assigning authority, and both share the properties that decide whether a control can help: no privileges required, no user interaction, and adjacent rather than fully remote access [1](#ref-1)[2](#ref-2). CVE | CVSS 4.0 base | Vector, abbreviated | Entry point | Weaknesses | CVE-2026-76639 | 8.7 HIGH [1](#ref-1) | AV:A / AC:L / PR:N / UI:N | Network adjacent, DDS bridge on TCP 9991 | CWE-22 path traversal, CWE-306 [1](#ref-1) | CVE-2026-76640 | 7.7 HIGH [2](#ref-2) | AV:A / AC:H / PR:N / UI:N | BLE proximity, no pairing | CWE-787 out-of-bounds write, CWE-306 [2](#ref-2) | Two details deserve emphasis. PR:N and UI:N mean no credential and no human mistake are required; the robot does not need anyone to click anything. And AV:A, adjacent access, is the operator's opening: unlike a fully remote flaw, an attacker must first be on the same network segment or within radio range, and both of those are properties of your deployment rather than of the firmware. One honest caveat on the scores. Both CVE records currently sit in RECEIVED status with the note that an NVD assessment has not yet been provided, so the CVSS figures above are the assigning authority's [1](#ref-1)[2](#ref-2). Secondary reporting has also quoted an 8.8 figure for the first, which is a CVSS 3.1 style number rather than the 4.0 base recorded at NVD. Cite the record, not the round-up. ## Is there a patch? Not one that has been confirmed. Neither CVE record lists a vendor advisory or a fixed version among its references, which instead point to the researcher's write-up and the assigning authority's advisory [1](#ref-1)[2](#ref-2). Reporting on the disclosure states plainly that "an exact fixed firmware release has not been verified in any accessible Unitree guidance," leaving owners without a confirmed release target for either issue [3](#ref-3). There is partial vendor action, and it is worth being precise about what it covers. The vendor patched a cloud account-to-robot ownership check in July 2026, which broke the original proof-of-concept flow, so the cloud-assisted route now requires an account already bound to the target robot or the relevant key material already in hand [3](#ref-3). That raises the bar on one step of one chain. It is not the same as a firmware release that closes the underlying weaknesses on a robot you own, and it should not be recorded in your risk register as one. The practical position for an operator today: affected versions are known (through 1.5.2), the access required is known, and the upgrade target is unknown. That combination is what the rest of this article is about, because it is not rare. ## Why is "no confirmed fixed version" the normal case in robotics? Because the robotics market has not yet built the vulnerability-response machinery that enterprise software spent two decades building. The comparison worth drawing is with a vendor that did it well. When a critical command injection flaw was found in Universal Robots PolyScope 5, the vendor published an advisory naming the fixed version, 5.25.1, and listed concrete mitigations: minimize network exposure, place controllers behind firewalls, disable the affected interface where unused, and restrict access to trusted hosts or subnets [4](#ref-4). That is what a mature response looks like: a named fixed version and interim controls for people who cannot upgrade tomorrow. Its absence is not a moral failing so much as a market-maturity signal, and the security literature on embodied AI documents the same pattern repeatedly, including flaws where a cloud endpoint was shut down server-side while the client code and default credentials stayed resident on the robots themselves [5](#ref-5). The planning consequence is the part teams miss. If your robot security model assumes a patch will arrive, you have outsourced your risk posture to a vendor's release schedule, and in this market that schedule is frequently unpublished. Assume instead that for some window, possibly a long one, you will operate a machine with a public unauthenticated root chain and no upgrade target. Design for that case rather than treating it as an emergency each time. ## What actually breaks these chains without a vendor fix? Reachability, first and hardest. Both chains are AV:A, adjacent access [1](#ref-1)[2](#ref-2), which means the attacker must reach the robot on the network or stand within radio range. Neither of those is a property of the firmware, and both are things you control. Segmenting the robot control network removes the network-adjacent path to the DDS bridge, and disabling BLE where it is unused, or operating the fleet inside a controlled radio area, removes the proximity path. This is the same conclusion the mature advisory reached for a different robot: minimize network exposure, firewall the controller, disable unused interfaces, restrict to trusted hosts [4](#ref-4). It reads as unglamorous, and for these two CVEs it is the single highest-value action available this week. Our page on [ROS 2, SROS2 and DDS security](https://rankshieldrobotics.com/threats/ros2-sros2-dds-security/) covers why a DDS bus reachable from a flat network is the recurring robotics exposure. After reachability come the controls that decide how far a compromise travels. A credential unique to each unit and held in hardware means an attacker who owns one robot does not inherit its peers, which matters here because one of these chains involves a static key stored world-readable [1](#ref-1). Revocation that a robot reads on its next command, rather than on its next firmware campaign, shortens the window from days to seconds. And a tamper-evident record of what each robot was asked to do is what lets you answer, afterwards, whether a suspect unit did anything at all. The worksheet below maps your current controls onto the two published chains and shows what stays reachable. Everything runs in your browser. Reachability controls stop the published chains starting. Identity, revocation and provenance bound what a compromise reaches. Neither recovers the unit itself. ## Does an authorization gate help once an attacker already has root? Not for the compromised unit, and it is important to say so plainly. Root on the locomotion PC means the attacker holds the same authority as any software running on that computer. A policy check executing on the robot alongside the attacker is not a boundary; it is another process under their control. Anyone selling you an on-robot gate as an answer to a root RCE is selling you something that does not work. What survives is the part that does not execute on the compromised machine. If the robot's credential lives in a secure element rather than a file, root on the application processor does not automatically yield an exportable key that impersonates the unit elsewhere. If high-consequence actions are authorized by a service the robot must satisfy rather than by the robot asserting its own compliance, then a compromised unit can request and be refused. If revocation is read on the next command, the unit is cut off in seconds rather than after a fleet update. And if provenance is written outside the robot, the record of what it did is not the attacker's to edit. So the honest claim is narrow and still valuable: these controls do not save the unit, they decide whether one compromised robot is an incident or an outage. That distinction is the whole of what a fleet operator can influence while no patch exists. See [per-robot attested identity](https://rankshieldrobotics.com/solutions/robot-identity-attestation/) and [revocation](https://rankshieldrobotics.com/solutions/robot-kill-switch-dead-man-credential/) for how each piece is built. ## What does the CRA clock require when there is no patch? Reporting duties do not wait for a fix to exist. The EU Cyber Resilience Act's reporting obligations under Articles 14 and 16 apply from 11 September 2026, ahead of full application on 11 December 2027 [6](#ref-6). From the moment a manufacturer becomes aware of an actively exploited vulnerability or a severe incident, an early warning is due to ENISA and the relevant national CSIRT within 24 hours, a fuller notification within 72 hours, and a final report within 14 days once the issue is handled [6](#ref-6). Read that against the situation above. The trigger is active exploitation, not the availability of a patch, so "we are waiting on the vendor" is not a state that pauses the clock. A manufacturer placing robots on the EU market needs to be able to determine quickly whether a published chain is being used against deployed units, and that determination is exactly what an operator without telemetry cannot make. This is where the unglamorous controls earn their place twice over. Knowing which units run which firmware version answers the scope question. A tamper-evident action record answers the exploitation question. Neither is a compliance feature bolted on for a deadline; they are the operational capability the deadline assumes you already have. Our [secure-by-design and CRA guide](https://rankshieldrobotics.com/compliance/secure-by-design-robots-cra/) sets out the full timeline and the conformity routes. ## Why does the same weakness keep appearing? Because it is a design default rather than a coding slip. Both of these CVEs carry CWE-306, missing authentication for a critical function [1](#ref-1)[2](#ref-2). That is the same weakness class behind a cloud control plane that accepted one owner's device token as authority over roughly 7,000 other people's robots [7](#ref-7), and behind the shared hard-coded credentials documented across embodied-AI research [5](#ref-5). Three separate vendors, three different layers, one recurring assumption: that reaching an interface is sufficient evidence of being entitled to use it. The pattern also explains why patching alone never gets ahead of it. A fix for one unauthenticated endpoint does not change the architectural habit that produced it, and the next interface added to the product tends to inherit the same default. Our analysis of [why one credential can reach an entire robot fleet](https://rankshieldrobotics.com/blog/robot-fleet-one-credential-blast-radius/) traces the same defect across three layers of the stack. For a buyer, this suggests a more useful procurement question than "is it patched." Ask how the robot authenticates a command, whether credentials are unique per unit, and where the authority decision is made. A vendor who can answer those crisply is unlikely to be shipping CWE-306 on their next interface. ## What should a G1 EDU operator do this week? Five things, in order, and none of them require the vendor. Confirm which of your units are on firmware 1.5.2 or earlier, since the affected range is "through 1.5.2" [1](#ref-1)[2](#ref-2). Establish whether the robot control network is reachable from general IT, and segment it if it is. Determine whether BLE is enabled and needed, and disable it where it is not. Check whether a compromise of one unit would yield credentials valid on another. And decide, before you need it, how you would cut a suspect robot off and how long that would take. Then record the position rather than carrying it in someone's head: affected units, controls in place, residual exposure, and the date you last checked for a fixed release. The worksheet below produces that as a downloadable summary. Track the vendor for a firmware release, and treat everything here as containment rather than remediation, because that is what it is. Interactive tool ### No-Patch Posture Worksheet Map your current controls onto the two published chains and see what stays reachable. Nothing you enter leaves your browser. Both published chains require adjacent access (CVSS AV:A) and no privileges or user interaction. Tick what is true of your deployment today. The robot control network is segmented from IT and from the wider OT network BLE is disabled where unused, or the robot operates inside a radio-controlled area Each robot holds its own credential in hardware, not a key shared across the model line A suspect robot can be cut off fleet-wide in seconds, without a firmware campaign High-consequence actions are authorized off-robot and deny-by-default There is a tamper-evident record of what each robot was asked to do and what it did RESIDUAL EXPOSURE WHILE NO FIX EXISTS Download your no-patch posture ## Frequently asked questions about operating a robot you cannot patch **Is there a fix for CVE-2026-76639 and CVE-2026-76640?** No confirmed fixed firmware release has been identified. Neither CVE record lists a vendor advisory or a fixed version among its references [1](#ref-1)[2](#ref-2), and reporting on the 27 August 2026 disclosure states that an exact fixed firmware release has not been verified in any accessible vendor guidance [3](#ref-3). The vendor did patch a cloud account-to-robot ownership check in July 2026, which broke the original proof-of-concept flow, but that is a server-side change to one step of one chain rather than a firmware fix for the underlying weaknesses [3](#ref-3). Track the vendor and record the date you last checked. **Which robots and firmware versions are affected?** Both CVE records list Unitree Robotics G1 EDU with an affected range of versions through 1.5.2 [1](#ref-1)[2](#ref-2). Testing was conducted on V1.5.2 [3](#ref-3). Start by inventorying which of your units are at or below that version. Note that "through 1.5.2" means earlier versions are in scope too, so an older fleet is not safer, and that the absence of a named fixed version means there is currently no upgrade target to move to. **What does adjacent access (AV:A) mean, and why does it matter here?** It means the attacker cannot reach the vulnerability from anywhere on the internet; they must be on the same network segment or, for the Bluetooth chain, within radio range [1](#ref-1)[2](#ref-2). This matters because adjacency is a property of your deployment rather than of the firmware, so it is the one part of the attack chain you can change without a vendor. Segmenting the robot control network and disabling or containing BLE close the two published paths even though no patch exists. **Will a pre-actuation authorization gate protect a robot that is already rooted?** Not the rooted unit itself, and it is worth being direct about that. An attacker with root on the locomotion PC holds the same authority as any software on that computer, so a policy check running alongside them is not a boundary. What still helps is the part that does not execute on the compromised machine: a credential held in a secure element rather than a file, authorization decided by a service the robot must satisfy, revocation read on the next command, and a provenance record written outside the robot. Those decide whether one compromised unit becomes a fleet event, not whether the unit is saved. **Do CRA reporting obligations apply if the vendor has not shipped a patch?** Yes. The CRA reporting duties under Articles 14 and 16 apply from 11 September 2026 and are triggered by awareness of an actively exploited vulnerability or a severe incident, not by the availability of a fix [6](#ref-6). The cadence is a 24-hour early warning to ENISA and the relevant national CSIRT, a fuller notification within 72 hours, and a final report within 14 days once handled [6](#ref-6). Waiting on a vendor does not pause the clock, which is why version inventory and exploitation telemetry matter operationally rather than only for conformity. **Should we take affected robots out of service?** That is a risk decision only you can make, and it depends on what the robot does and who is near it. The inputs worth weighing: whether an attacker could realistically achieve adjacency in your environment, what a rooted unit could physically do given its envelope and location, whether a compromise would spread to other units, and how quickly you could detect and cut off a suspect robot. A unit on an isolated network in a fenced cell is a materially different proposition from one on a flat network in a space shared with people. Document the reasoning either way. **What does RankShield Robotics provide here?** We do not patch vendor firmware, publish vulnerability research, or certify compliance. We provide the controls that keep working when a fix does not exist: hardware-rooted identity unique to each unit so a compromise does not yield credentials valid elsewhere, off-robot authorization for high-consequence actions, revocation that a robot reads on its next command rather than its next firmware campaign, and tamper-evident provenance written outside the robot so the record of what a suspect unit did is not the attacker's to edit. ## References - NIST National Vulnerability Database. CVE-2026-76639 (Unitree G1 EDU, unauthenticated RCE via DDS bridge and path traversal), published 27 August 2026, status RECEIVED . 2026. [nvd.nist.gov/vuln/detail/CVE-2026-76639](https://nvd.nist.gov/vuln/detail/CVE-2026-76639) - NIST National Vulnerability Database. CVE-2026-76640 (Unitree G1 EDU, unauthenticated root via BLE GATT and Wi-Fi provisioning), published 27 August 2026, status RECEIVED . 2026. [nvd.nist.gov/vuln/detail/CVE-2026-76640](https://nvd.nist.gov/vuln/detail/CVE-2026-76640) - The Hacker News. Two Unitree G1 EDU Humanoid Robot Flaws Enable Root RCE, One Starts Over Bluetooth . 27 August 2026. [thehackernews.com/2026/08/two-unitree-g1-edu-humanoid-robot-](https://thehackernews.com/2026/08/two-unitree-g1-edu-humanoid-robot-flaws.html) - 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/) - Recorded Future. Hacking Embodied AI . 2026. [www.recordedfuture.com/research/hacking-embodied-ai](https://www.recordedfuture.com/research/hacking-embodied-ai) - cyberresilienceact.eu. The Cyber Resilience Act Explained: Scope, Classes and Deadlines . 2026. [www.cyberresilienceact.eu/explained.html](https://www.cyberresilienceact.eu/explained.html) - 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/) ## Keep exploring [THREATROS 2, SROS2 and DDS security](https://rankshieldrobotics.com/threats/ros2-sros2-dds-security/)[BLOGOne credential, your entire fleet](https://rankshieldrobotics.com/blog/robot-fleet-one-credential-blast-radius/)[COMPLIANCESecure-by-design and the CRA](https://rankshieldrobotics.com/compliance/secure-by-design-robots-cra/) ## Containment you own, for the window you do not control. Per-unit identity, off-robot authorization, seconds-scale revocation, and provenance an attacker cannot edit. [Request early access](https://rankshieldrobotics.com/request-access/) This article is for general information and does not constitute security, legal, or incident-response advice. It describes published vulnerability records and defensive posture; it does not provide exploitation detail, and it does not link to proof-of-concept code. CVE status, scoring, and vendor remediation change: both records were in RECEIVED status with no NVD assessment provided when this was written, and the CVSS figures are the assigning authority's. Verify the current state of each CVE and any vendor advisory before acting, and confirm your own regulatory obligations with qualified counsel.