When a Robot Fleet Shares One Secret, the Broker Becomes the Blast Radius

Connected robots depend on trust that is usually invisible to the user. In Yarbo’s case, that trust boundary centered on MQTT, the messaging layer carrying telemetry and operational commands. The problem was not a single bug in isolation. It was the combination of a shared credential in the mobile app and weak broker-side authorization in the cloud, a pairing that can collapse the separation between “my device” and “every device.”

Fast Facts

• CISA identified two issues in Yarbo’s Android/iOS mobile application and cloud infrastructure: CVE-2026-10557 and CVE-2026-7368.
• The app contained hard-coded MQTT broker credentials that were identical for all users and devices.
• The cloud environment did not enforce per-device or per-user authorization for topic access.
• The advisory says the credentials could be extracted from the app binary via APK decompilation.
• No known public exploitation specifically targeting the flaws had been reported to CISA at publication time.

How a Messaging Protocol Becomes a Control Path

MQTT is a publish-subscribe protocol, which makes it efficient for telemetry and remote control. But MQTT does not automatically decide who may read or publish which topic. That responsibility sits with the vendor’s authentication and authorization design. When a client app ships with embedded credentials, and the broker accepts them broadly, one extracted secret can become a reusable key to a much larger system.

The first weakness here maps to CWE-798, hard-coded credentials. Secrets placed in a client binary should be assumed discoverable, because app packages are inspectable artifacts rather than secure vaults. The second weakness maps to CWE-862, missing authorization. Even if a credential is valid, the broker still needs to verify whether that identity may subscribe to a topic or publish a command for a specific robot.

That distinction matters. Telemetry access is a confidentiality issue, but command-topic publishing moves the risk into integrity. In a fleet setting, the difference between observing devices and steering them is enormous. If a serial number is enough to address a target and no per-device policy blocks the action, a single credential can have outsize reach.

Yarbo’s mitigation path focuses on updating the mobile app to version 3.17.4 or later and enforcing server-side broker authorization in the May 2026 update. That is the right direction because the fix has to live on the server side, not in client-side secrecy. For defenders, the lesson is simple: do not rely on the app to protect the app’s own secrets.

At the time of writing, the confirmed technical picture is already serious enough without speculation. The advisory establishes that shared credentials and missing authorization created exposure to telemetry access and command paths. What remains for operators is to verify that credentials are rotated, broker rules are tightened, and any legacy access path is retired.

Conclusion

This is the kind of flaw that looks small until it meets a fleet. In robotics, industrial tooling, and other cloud-managed devices, the real security boundary is not the mobile app alone, but the policy enforced behind it. Shared secrets and coarse authorization can turn a normal control channel into a system-wide liability. The broader lesson is to design every remote command path as if the client will be inspected, because eventually it will.

WIKICROOK

• MQTT: A publish-subscribe messaging protocol often used to carry telemetry and command data for connected devices.
• Hard-coded credentials: Secrets embedded directly in software, where they can be discovered by reverse engineering or inspection.
• APK decompilation: The process of examining an Android application package to inspect code and embedded resources.
• CWE-798: A weakness category for software that contains credentials baked into code or binaries.
• CWE-862: A weakness category for missing authorization checks that should restrict access to data or actions.