A robot’s camera, artificial intelligence, and motors can all appear healthy while hidden inputs steer its physical actions.
A robot does not need to be switched off for an attack to matter. An attacker can change what the robot sees, the instructions it follows, or the commands moving its body. Each part may keep reporting that it works normally while the robot makes an unsafe choice.
That risk is especially important for physical artificial intelligence systems, including humanoid and four-legged robots. These machines combine sensors, AI models, and motion controllers. Sensors gather information, models interpret it, and controllers turn that interpretation into movement.
The weak point is the link between those steps: the data guiding the decision.
The hidden-trigger problem
One way to attack a robot is to place a secret trigger inside its AI model. A trigger might be a visual pattern, an object, or another input that looks harmless to people but changes the model’s response.
IEEE Spectrum reported on research into BadVLA, an attack aimed at vision-language-action models. These models connect what a robot sees and reads with coordinated physical movement. The reported attack caused the robot’s action path to change when a particular trigger appeared.
Without the trigger, the model largely kept performing its normal task. That makes the problem difficult to spot through ordinary testing. A robot can pass standard checks, then behave differently when it encounters the attacker’s chosen signal.
A related 2025 study called GoBA reportedly used ordinary objects, including a coffee mug, as triggers. The researchers reported a 97 percent attack success rate without reducing performance on clean inputs, meaning inputs without the trigger.
Those are research findings reported by IEEE Spectrum, not evidence that every deployed humanoid robot is vulnerable. But they show why “the model works on our test set” is not enough. Testing must also ask whether an unusual object or visual detail can quietly redirect physical behavior.
The software around the model
An attacker can also target the robot’s surrounding computer systems instead of its AI model.
IEEE Spectrum reported on UniPwn, a Bluetooth exploit chain disclosed in September 2025. The report says researchers found hardcoded cryptographic keys, bypassed authentication checks, and command injection that enabled root-level access on affected quadruped and humanoid robots.
“Root-level” access means control with very broad privileges inside the robot’s software. The report also described the exploit as “wormable”: a compromised robot could scan for nearby units and potentially spread the attack across a fleet.
The same report discussed weaknesses in software systems used to connect robot processes. If an attacker gains enough access, the robot’s parts may continue operating normally while the commands flowing between them are no longer trustworthy. An attacker might override motor commands or replace the model files used by the robot.
This is different from breaking a motor or blinding a camera. The hardware can remain available, and software services can remain online. The dangerous change is who—or what—the robot trusts.
Attacking inputs during operation
Some attacks need neither a modified model nor a network break. They manipulate the inputs that shape decisions while the robot is running.
IEEE Spectrum reported that RoboPAIR used carefully structured prompts to redirect robots controlled by large language models toward unsafe trajectories. It also described BadRobot, where a robot verbally refused a dangerous command in some cases even though its motion controller carried out the action.
That split matters. A spoken refusal is not a safety barrier if the movement system accepts the underlying command.
Vision attacks can work in a similar way. The report said VLAttack used an adversarial patch—an image designed to confuse a vision model—inside the robot’s camera view. The researchers reported that it could reduce a vision-language-action model’s task success rate to zero.
Another reported study, FreezeVLA, used a single adversarial image to freeze a robot’s decision-making loop, leaving it unresponsive to later instructions. In both cases, the camera may still produce images, the model may still run, and the controller may still respond. The robot is failing at the level that matters most: its physical behavior.
What engineers should test
Traditional safety testing asks whether a machine handles faults, such as a failed sensor or an unexpected operating condition. Cybersecurity adds a different question: what happens when someone deliberately manipulates information that the robot normally trusts?
That means testing more than component availability. A dashboard showing that the camera, model, and controller are online cannot prove that the robot is making safe decisions.
Before deployment, teams need tests that connect cyber events to physical results. Can a trigger alter a planned path? Can an unusual camera image make the robot grasp, move, or stop incorrectly? Can a compromised software service send commands that bypass the robot’s normal safety limits?
The reported work includes research studies and demonstrations, while the source does not establish that these techniques have caused harm in a deployed humanoid-robot environment. Operators should therefore treat attack success claims and affected-product details as source-reported until primary research, vendor disclosures, and independent testing confirm them.
The practical lesson is simple: a safe robot must be judged by what it does under hostile inputs, not only by whether its parts remain switched on. For operators, the next step is behavior-focused security testing across the robot’s full lifecycle—from model training and software integration to live fleet monitoring.