Critical Vulnerabilities in the YoLink Smart Hub: Risk for Smart Home Users

The security firm Bishop Fox found several security-relevant weaknesses in the YoLink Smart Hub (firmware v0382). In a blog post, security researcher Nick Cerne, who disassembled the device, read internal logs, obtained MQTT credentials and API information, shows how attackers could remotely control other smart-home devices.

YoLink is a smart-home brand of the US company YoSmart Inc., based in Irvine, California, which specializes in LoRa-based IoT products such as sensors, door locks, outlets, surveillance systems and control hubs and markets its devices mainly, but not exclusively, in the US market (Amazon, its own online shops).

Nick Cerne, Senior Security Consultant at Bishop Fox, began with a physical teardown of the YoLink Smart Hub. On the circuit board he found an ESP32-WROOM-32 system-on-chip. Via the exposed debug pins he was able to establish a serial connection to the device over UART. The boot and application logs visible over UART showed, among other things, the Wi-Fi MAC, an API endpoint and MQTT connection information. From the logs he could read the address of the YoSmart MQTT broker and several identification values of the hub. This information provided the basis for further analysis. In parallel Cerne performed a packet capture analysis of the mobile client. With Wireshark he was able to view login requests, the family/account IDs and temporary session tokens of the mobile app. From these records it became clear how the app authenticated to the MQTT broker and which topics were used for device communication.

Reverse engineering: API secret and device IDs

By analyzing and decompiling firmware/binary code Cerne identified a function that derived an MD5 hash from a fixed key part and the device ID. This hash was used by the device as part of an API endpoint. It also emerged that device IDs are not sufficiently random and can be derived sequentially. To check whether authorization checks existed, the security researcher purchased a second hub and created two accounts. Using the MQTT credentials of the second account obtained via UART and packet capture, he deliberately published messages to the MQTT topic of the first account. The broker output showed successful CONNECT/CONNACK and PUBLISH sequences. Cerne physically observed that the remote lock actually unlocked.

This proved that the API broker did not perform adequate authorization checks and that valid MQTT credentials were sufficient to control other devices.

Manufacturer response and recommendation

Bishop Fox responsibly disclosed the vulnerabilities to YoSmart. According to the publication there was no response statement or available security update up to the date of the blog post. The researchers recommend treating the hub as untrusted: isolate it from critical networks, do not use it for access control and switch to vendors with demonstrable security practices. The report exemplifies classic IoT problems: open debug interfaces, lack of encryption and inadequate authorization quickly lead to practical, physically relevant attacks. Gateways are single points of failure. If the central unit is compromised, all connected devices are at risk.

Summary (tl;dr)

• Physical teardown of the hub revealed an ESP32 with accessible UART debug.
• UART logs provided MQTT broker info, API endpoints and other identifiers.
• Packet captures of the app showed session tokens, family IDs and MQTT authentication patterns.
• Reverse engineering revealed MD5-based API secrets and predictable device IDs.
• With valid MQTT credentials, a remote smart lock could be unlocked via MQTT publish.
• Bishop Fox reported the issues to YoSmart. No patch was available as of the publication date.

Source: Bishop Fox, „How a $20 Smart Device Gave Me Access to Your Home“, October 2, 2025.