Which versions of Yarbo Cloud are affected by CVE-2026-7368?

Yarbo's cloud MQTT infrastructure contains an authorization bypass that allows any authenticated user with valid credentials to gain full control over the entire global robot fleet, including…. A patch is available.

How to fix or mitigate CVE-2026-7368?

Within 24 hours: Inventory all Yarbo robot deployments and document credential holders; audit access logs for suspicious MQTT subscriptions or command patterns; escalate to Yarbo support requesting security advisory and patch timeline. Within 7 days: Rotate all Yarbo API credentials and authentication tokens; implement continuous monitoring for anomalous MQTT traffic (wildcard subscriptions, cross-robot command publishing); restrict telemetry access to authenticated endpoints only. Within 30 days: Apply vendor patch immediately upon release; conduct forensic review of MQTT logs for unauthorized activity; reassess Yarbo's security roadmap and consider alternative robot management platforms if no patch timeline is provided by 30 days.

Yarbo Cloud CVE-2026-7368

Q: What is the CVSS score of CVE-2026-7368?

CVE-2026-7368 has a CVSS 4.0 base score of 8.6 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.0%.

EUVD-2026-36433 HIGH

Missing Authorization (CWE-862)

2026-06-12 icscert

GHSA-285q-8jwv-fw98

Authentication Bypass Yarbo Android Ios Mobile Application Yarbo Cloud Mqtt Infrastructure

8.6

CVSS 4.0 · Vendor: icscert

Severity by source

Vendor (icscert) PRIMARY

8.6 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

9.9 CRITICAL

Network-reachable MQTT broker, low complexity, requires any valid credential (PR:L), no user interaction; scope changes from cloud auth context to physical robots, with high C/I and limited availability impact.

3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L/SC:H/SI:H/SA:L

Primary rating from Vendor (icscert).

CVSS VectorVendor: icscert

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Patch available

Jun 12, 2026 - 16:01 EUVD

Analysis Generated

Jun 12, 2026 - 14:50 vuln.today

CVE Published

Jun 12, 2026 - 14:01 cve.org

HIGH 8.6

DescriptionCVE.org

The Yarbo cloud does not enforce per-device or per-user authorization. Any client possessing valid credentials, whether the shared hard-coded credentials or legitimate per-user credentials, can subscribe to wildcard topics covering all robots globally, and can publish to any robot's command topic using only the robot's serial number (disclosed in the telemetry stream). Even after removal of hard-coded credentials from the app, a single compromised credential could still provide fleet-wide access without per-device access controls.

AnalysisAI

Authorization bypass in Yarbo's cloud MQTT infrastructure allows any authenticated client to subscribe to wildcard topics covering the entire global robot fleet and to publish commands to any robot using only its serial number, which is itself disclosed in the telemetry stream. The flaw affects both the Yarbo Android/iOS mobile application and the backing cloud MQTT broker, and no public exploit identified at time of analysis, but the design defect means a single compromised credential yields fleet-wide control.

Technical ContextAI

Yarbo robots use an MQTT publish/subscribe broker for telemetry and command-and-control between the mobile app and the cloud. The broker is configured without topic-level Access Control Lists (ACLs) tying a credential to a specific device or user, which is the textbook manifestation of CWE-862 (Missing Authorization). Because MQTT supports wildcard subscriptions (e.g. '+' and '#'), any client that authenticates - historically via hard-coded credentials embedded in the app, and currently via any legitimate per-user account - receives the full telemetry firehose for every robot worldwide, harvests serial numbers from that stream, and can then publish to each robot's command topic. The CPE strings confirm both 'yarbo:yarbo_android/ios_mobile_application' and 'yarbo:yarbo_cloud_mqtt_infrastructure' as in-scope, indicating the root cause is broker-side rather than purely a client mis-implementation.

RemediationAI

No vendor-released patch identified at time of analysis with an exact fixed version; the description confirms that hard-coded credentials were removed from the mobile app in a prior update but states that this change alone is insufficient because per-device authorization is still missing on the broker. Operators should consult ICSA-26-162-01 (https://www.cisa.gov/news-events/ics-advisories/icsa-26-162-01) and the CSAF feed (https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-162-01.json) for vendor mitigation guidance, update to the latest mobile app release to eliminate the shared hard-coded credentials, and rotate any user account credentials that may have been exposed. Because the fundamental fix must occur cloud-side (per-topic ACLs binding credentials to a robot serial), compensating controls available to end users are limited: deregister and reset robots after suspected credential exposure, restrict robot operation to times when the device is physically supervised, and where possible isolate the robot from sensitive areas until the vendor confirms broker-side ACL enforcement - accepting the trade-off that supervised-only use defeats much of the product's autonomous value.