CVE-2026-30789 concerns RustDesk clients, listed through version 1.4.8, where the password proof uses fast SHA256 hashing with no slow key derivation. NVD scores it 9.8, while the researcher's later notes rate it 5.7 and limit it to offline cracking. Use long passwords and update.
What's affected
The NVD record lists RustDesk Client through 1.4.8 on desktop and mobile platforms. It names a rogue or on-path API or relay server as a way to obtain a proof, and mentions two related CVEs.
The researcher's findings document, updated in June 2026, retains this CVE at 5.7 Medium and says the weakness is offline brute force only. It says capture and replay is not viable, because the proof travels inside the secure peer channel and a per connection challenge defeats replay. It also says online guessing is rate limited. The record names no fixed version.
How to check if you're exposed
List RustDesk clients and their versions across your devices. Then check how access is set up: a permanent password, a one time password or manual accept. The weakness matters most for short passwords, so look for six digit PINs and short passwords on devices used for unattended access. Find out whether anyone runs a self-hosted API or relay server, and who administers it.
What to do now
- Replace short or guessable permanent passwords with long random ones from a password manager.
- Update RustDesk to the latest release and read its notes for authentication changes, including the one time password and login failure limits the researcher mentions for 1.4.7.
- Where you can, use manual accept or one time passwords instead of permanent access.
- Keep API and relay servers under your own control and patch them.
- Limit local access to devices, because the researcher says a stored verifier or captured proof is what enables offline cracking.
Why it matters
The record files this under CWE-916, use of a password hash with insufficient computational effort. Fast hashes like SHA256 let an attacker test billions of guesses per second on a graphics card, so a short password falls in moments. The researcher's own table puts a six digit PIN at a tiny fraction of a second and an eight character lowercase and number password at a few minutes.
The fix for this class is a slow, salted key derivation or a protocol designed for password proof, and the researcher suggests SRP. Until then, password length is your control. The gap between the 9.8 in NVD and the 5.7 the researcher retains is large, so use the lower number as context and not as permission to ignore it. The record does not mark this as exploited in the wild.
Quick check
Why is the NVD score so much higher than the researcher's?
The NVD entry was scored on the original claim. The researcher's later notes withdrew parts of it and kept the offline cracking issue at 5.7.
What is the best practical defence?
A long random password, which makes offline cracking impractical.
Sources
Last reviewed: 19 October 2026.
