Crystalsky Zs600C
Monthly
DJI CrystalSky ZS600C firmware 0.3.9.7 through 0.6.6.9 exposes an unauthenticated adbd shell to anyone with physical USB access because the device ships with ro.adb.secure=0 and USB ADB enabled. An attacker can obtain a uid 2000 shell as a foothold for a separate privilege-escalation step to root; ADB over TCP is not enabled by default, but when enabled out-of-band the same unauthenticated shell is reachable over the network. No public exploit was identified at time of analysis and there is no CISA KEV entry; the assessed CVSS 3.1 score is 7.0 (AV:P) because the default path requires physical access, while the reported CVSS 4.0 base score is 9.3.
Local apps on DJI CrystalSky ZS600C devices can invoke system-privileged actions-including a factory reset that wipes user data, shutdown, clock/timezone changes, and a firmware-apply hand-off-because the DJIUpdateService binder does not verify caller identity or permissions. The flaw affects firmware v0.3.9.7 through v0.6.6.9 and is reachable by an installed app with no permissions and no user interaction. No public exploit has been identified at time of analysis; the issue is access-gated to local code execution on the specific device but warrants this-week prioritization because successful abuse is destructive and disruptive.
Local privilege escalation in DJI CrystalSky ZS600C firmware 0.3.9.7 through 0.6.6.9 allows an unprivileged process already running on the Android device to write a crafted line to logcat that the root-privileged hardware_monitor helper passes to a shell eval, resulting in arbitrary command execution as root. The attack is strictly local: the attacker must first obtain a foothold on the device, so this is an escalation primitive rather than a remote entry point. No public exploit was identified at time of analysis, and the published CVSS 4.0 score of 8.6 reflects high confidentiality, integrity, and availability impact once the local prerequisite is met.
Missing authorization in DJI CrystalSky ZS600C firmware v0.3.9.7 through v0.6.6.9 allows a local application with no Android permissions to invoke binder transaction 1018 on android.dji.server and execute arbitrary OS commands as root through the root-privileged assistant daemon. The attack is local only and requires the ability to run code on the physical device; no public exploit has been identified at time of analysis. The reported CVSS 4.0 base score is 8.6 (High), and the independent CVSS 3.1 assessment is AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
An undocumented root-level backdoor in the DJI CrystalSky ZS600C 'assistant' daemon allows a physically present attacker with USB access to execute arbitrary OS commands as root on firmware 0.3.9.7 through 0.6.6.9. Sending the hard-coded string 'dji26656677' to /dev/ttyGS0 unlocks a mode in which each subsequent line is passed to system(), with no authentication or user interaction required once USB access is obtained. The physical-access prerequisite is the dominant limiting factor: devices kept in continuous custody are not exposed, while units that leave custody during shipping, loan, resale or shared use are at risk; no public exploit identified at time of analysis.
DJI CrystalSky ZS600C firmware 0.3.9.7 through 0.6.6.9 exposes an unauthenticated adbd shell to anyone with physical USB access because the device ships with ro.adb.secure=0 and USB ADB enabled. An attacker can obtain a uid 2000 shell as a foothold for a separate privilege-escalation step to root; ADB over TCP is not enabled by default, but when enabled out-of-band the same unauthenticated shell is reachable over the network. No public exploit was identified at time of analysis and there is no CISA KEV entry; the assessed CVSS 3.1 score is 7.0 (AV:P) because the default path requires physical access, while the reported CVSS 4.0 base score is 9.3.
Local apps on DJI CrystalSky ZS600C devices can invoke system-privileged actions-including a factory reset that wipes user data, shutdown, clock/timezone changes, and a firmware-apply hand-off-because the DJIUpdateService binder does not verify caller identity or permissions. The flaw affects firmware v0.3.9.7 through v0.6.6.9 and is reachable by an installed app with no permissions and no user interaction. No public exploit has been identified at time of analysis; the issue is access-gated to local code execution on the specific device but warrants this-week prioritization because successful abuse is destructive and disruptive.
Local privilege escalation in DJI CrystalSky ZS600C firmware 0.3.9.7 through 0.6.6.9 allows an unprivileged process already running on the Android device to write a crafted line to logcat that the root-privileged hardware_monitor helper passes to a shell eval, resulting in arbitrary command execution as root. The attack is strictly local: the attacker must first obtain a foothold on the device, so this is an escalation primitive rather than a remote entry point. No public exploit was identified at time of analysis, and the published CVSS 4.0 score of 8.6 reflects high confidentiality, integrity, and availability impact once the local prerequisite is met.
Missing authorization in DJI CrystalSky ZS600C firmware v0.3.9.7 through v0.6.6.9 allows a local application with no Android permissions to invoke binder transaction 1018 on android.dji.server and execute arbitrary OS commands as root through the root-privileged assistant daemon. The attack is local only and requires the ability to run code on the physical device; no public exploit has been identified at time of analysis. The reported CVSS 4.0 base score is 8.6 (High), and the independent CVSS 3.1 assessment is AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
An undocumented root-level backdoor in the DJI CrystalSky ZS600C 'assistant' daemon allows a physically present attacker with USB access to execute arbitrary OS commands as root on firmware 0.3.9.7 through 0.6.6.9. Sending the hard-coded string 'dji26656677' to /dev/ttyGS0 unlocks a mode in which each subsequent line is passed to system(), with no authentication or user interaction required once USB access is obtained. The physical-access prerequisite is the dominant limiting factor: devices kept in continuous custody are not exposed, while units that leave custody during shipping, loan, resale or shared use are at risk; no public exploit identified at time of analysis.