CVE-2026-114357 in CrystalSky
Summary
by MITRE • 10/23/2026
Missing authentication for a critical function in the Android Debug Bridge daemon (adbd) in DJI CrystalSky ZS600C firmware v0.3.9.7 through v0.6.6.9 allows an attacker to obtain an unauthenticated shell (uid 2000), a foothold for privilege escalation to root. The device ships with ro.adb.secure=0 (no host key authorization) and USB ADB enabled by default; ADB over TCP is not enabled by default but, once enabled (e.g. via the shipped /system/bin/adbd_tcp.sh or 'setprop persist.adb.tcp.port 5555'), the same unauthenticated shell is reachable over the network (CVSS 4.0 base 9.3).
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in DJI CrystalSky ZS600C firmware versions v0.3.9.7 through v0.6.6.9 represents a critical failure in access control mechanisms within the Android Debug Bridge daemon, commonly referred to as adbd. This flaw allows an attacker to obtain an unauthenticated shell with user ID 2000, which corresponds to the ADB_USER group on many Android-based systems. The presence of this shell provides a significant foothold for further exploitation, specifically enabling privilege escalation attacks that can lead to full root access over the device. The severity of this issue is underscored by its potential impact on both local and remote attack vectors, depending on the configuration state of the device at the time of exploitation.
At the technical level, the core deficiency lies in the default configuration settings shipped with the firmware. Specifically, the property ro.adb.secure is set to 0, which disables host key authorization requirements for ADB connections. In a properly secured environment, this flag should be enabled to ensure that only authorized hosts can establish debugging sessions. Furthermore, USB-based ADB access is enabled by default without any additional authentication prompts or cryptographic verification steps. This configuration effectively bypasses the standard security controls designed to prevent unauthorized devices from interacting with the operating system's debug interface. The lack of mutual authentication means that any physical connection via USB allows immediate shell access if the device does not enforce strict user approval policies, which are often absent in embedded industrial and consumer electronics like drone controllers.
The operational impact extends beyond local physical attacks due to the capability to enable ADB over TCP. While this feature is disabled by default, it can be activated using provided scripts such as /system/bin/adbd_tcp.sh or by setting the persist.adb.tcp.port property to 5555. Once enabled, the unauthenticated shell becomes reachable over the network via standard TCP connections. This transforms a local physical vulnerability into a remote one, significantly expanding the attack surface. An attacker within the same network segment can exploit this misconfiguration to gain initial access without needing physical proximity to the device. The resulting CVSS base score of 9.3 reflects the high severity associated with unauthenticated remote code execution capabilities in an embedded system context where such interfaces are often assumed to be secure or isolated.
From a classification perspective, this vulnerability aligns closely with CWE-287, which describes Improper Authentication, as well as CWE-613, Insufficient Session Expiration, if session tokens were involved, though the primary issue is the absence of authentication entirely for critical functions. In terms of adversary tactics, this flaw facilitates initial access techniques documented in MITRE ATT&CK frameworks, particularly those involving peripheral device interactions or network service exploitation depending on whether USB or TCP vectors are utilized. The ability to escalate privileges from uid 2000 to root further exacerbates the risk, as it allows complete control over the operating system, including modification of firmware, exfiltration of sensitive data such as flight logs and user credentials, and potential use of the device as a pivot point for attacking other systems on the network.
Mitigation strategies must address both the configuration defaults and the exposure of debug interfaces. Manufacturers should enforce ro.adb.secure=1 by default in all production firmware builds to mandate host key authorization. Additionally, ADB over TCP functionality should be disabled entirely or require explicit user consent with strong authentication mechanisms before activation. For deployed devices that cannot receive immediate patches, administrators can manually disable the adbd service when not actively debugging using standard Android shell commands if accessible through other means, or physically isolate the device from networks where such attacks might originate. Users should also avoid enabling ADB over TCP unless absolutely necessary and ensure that any enabled debug interfaces are protected by robust network segmentation policies to limit lateral movement opportunities for potential attackers.