Vision 60’s new vulnerabilities turn robot security into a control problem

The disclosure

On July 27, the National Vulnerability Database published records for two high-severity vulnerabilities affecting the Vision 60 mobile control application, version 5.5.0, made by Ghost Robotics. The independent Korean outlet The Guru reported the same three-CVE disclosure and said Spain’s National Cybersecurity Institute coordinated the findings. The records describe a quadrupedal unmanned ground vehicle, not a generic server or smartphone app.^[1,2,3]

The highest-consequence record, CVE-2026-12989, describes missing authentication in the mobile application. An attacker connected to the robot’s internal Wi-Fi network could reach the web administration interface and HTTP application programming interface, with the record describing access to live camera feeds, movement, sensors, and commands including Play, Pause, Stop, and emergency stop.^[1,3]

The physical consequence is the key delta

That changes the ordinary cybersecurity frame. This is not only a question of stolen video or exposed maps; the disclosed interface reaches the commands and sensors that operators use to move, stop, and recover the machine. A separate record, CVE-2026-12991, describes missing cryptographic protection for communications and says a local-network attacker could interfere with the legitimate controller and prevent the operator from regaining control.^[1,2,3]

The exposure maps onto the product’s stated operating model. Ghost Robotics describes Vision 60 as a network-connected quadruped for defense and commercial work, with Wi-Fi and cellular connectivity, mission control, live video, and field inspection or public-safety applications. The security boundary therefore sits inside the operating layer that a buyer depends on for detection, supervision, and recovery.^[2,4]

What operators still do not know

The evidence is serious but bounded. The records state that exploitation was not known, describe a local-network access condition, and do not document an injury, mission failure, or field compromise. The independent report says no patch had been reported at publication and records the company’s earlier response to a 2025 Vision 60 disclosure that testing had used a developer mode. Whether that response applies to the current APK 5.5.0 findings is unresolved.^[1,2,3]

For integrators, patching is only one control. The next safety review should verify the deployed application and firmware version, isolate the control network, test emergency-stop and manual-recovery behavior, preserve relevant logs, and document what happens when the operator loses the channel. Those are operator controls to verify, not claims that Ghost Robotics has validated a remedy.^[1,2,4]

The next measurable checkpoint is a vendor patch or technical response followed by an independent retest. A deployment-specific incident, evidence of exploitation, or a clear demonstration that the affected app is not used in current fielded systems would change the assessment again. For now, the decision delta is narrow but material: robot cybersecurity has reached the movement, sensor, and recovery layer of the safety case, even though no field attack has been established.^[1,2,3]