A valet who only got the trunk key somehow also has the ignition
RustDesk authorizes a remote session as one of several connection *types* — view-only, file-transfer, full control — but its message dispatcher checks per-capability bitflags on the inbound control stream instead of asking *what kind of session is this?* A peer who only negotiated FileTransfer still has the keyboard, mouse, screenshot, and display-capture handlers reachable because those capability flags are never cleared at session setup. Once the peer is authorized for file moves, it can call mouse_event, key_event, and the screen-grab routines and the server happily honors them. Affected: RustDesk through commit ff226f6d8013dee2de5a6553abaf67bf32b3e875 (disclosed 2026-06-28, CWE-863, fix not yet pinned to a tagged release at time of writing).
Vendor severity of HIGH (7.6) is defensible on paper but a touch hot for the typical deployment. CVSS captures the I:H from synthesized input and C:L from screen capture, but it bakes in PR:L — the attacker must *already* hold a valid FileTransfer authorization. That precondition is the whole story: if you never share a FileTransfer-scoped permanent password or accept a file-transfer prompt from a stranger, the chain never starts. We land MEDIUM for most fleets — confidentiality + integrity *to the single endpoint* the attacker was already granted partial access to, with no lateral pivot and no unauth RCE.
4 steps from start to impact.
Obtain a valid FileTransfer authorization to the target
github.com/bikini/exploitarium/tree/main/rustdesk-session-permission-pocs.- Network reachability to victim's RustDesk peer (direct or via relay)
- Valid FileTransfer credential or accepted prompt
- Victim's RustDesk client is running
- Default install does not set a permanent password — sessions require interactive approval
- MSP brokers typically issue full-control credentials, not FileTransfer-scoped ones, so the precondition is rarer than it sounds
- Users who approve a prompt typically approve full control, not file-transfer-only
FileTransfer followed by input events is the signature.Send keyboard/mouse input messages over the FileTransfer session
MouseEvent and KeyEvent protobuf messages on the established channel. The server-side dispatcher routes them to the input subsystem and synthesizes them on the victim's desktop. No additional auth round-trip. Tool: PoC script invokes the RustDesk protocol library directly.- Step 1 succeeded
- Victim host has an interactive desktop session for input to land on
- On Linux/Wayland targets, input injection paths are flakier than on Windows
- If the victim is at the keyboard, they will *see* the cursor move and can disconnect
Capture screen via the unguarded display-capture handlers
screenshot.py style call against the open session.- Step 1 succeeded
- Victim's display is unlocked or attacker uses input from step 2 to unlock
- A locked screen returns the lock screen image only
- MFA/Windows Hello blocks attacker-driven re-auth
rustdesk analyzer can flag.Action on objectives — single-host data theft or pivot
- Steps 1-3 successful
- Valuable artifacts present on host
- EDR flags credential dumping, browser cookie reads, lsass touch
- DLP egress controls on the corporate network
hbbs/hbbr) to your tenant via --key and IP allowlist — Self-hosted RustDesk Server Pro supports preshared keys and ACLs; force clients to use only your relay and reject public rendezvous (rs-ny.rustdesk.com etc.). This shrinks who can even *attempt* a FileTransfer handshake to your authenticated peers.rustdesk/rustdesk releases and apply the capability-clear fix when tagged — The repository will cut a release with the per-session capability reset; watch GitHub releases or the GHSA. Bundle into your normal endpoint software update channel within the noisgate MEDIUM 365-day remediation window — accelerate to 90 days if you operate RustDesk in MSP-scale deployments.rustdesk.exe — Most EDRs can correlate SetCursorPos/SendInput/keybd_event originating from a network-attached process. Tag any such activity on RustDesk hosts for triage — this catches the bug being exploited *and* legitimate-but-suspicious remote support.- Network-edge firewall blocking inbound — RustDesk relays through outbound-initiated connections to a rendezvous server, so perimeter inbound rules don't stop the attack path.
- Requiring 2FA at the operating system — once input is synthesized into an already-unlocked session, OS auth is bypassed; 2FA only helps for re-auth prompts.
- Running RustDesk as a non-admin user — the bug abuses the granted session scope, not OS privilege; even an unprivileged user's session leaks screen content and accepts input.
- Blocking the RustDesk binary by hash — RustDesk publishes frequent builds and is also commonly self-compiled; binary blocking is brittle and breaks legitimate use without addressing the root flaw.
The supporting signals.
| In-the-wild exploitation | None observed as of 2026-06-30. Not on CISA KEV. |
|---|---|
| Public PoC | Yes — bikini/exploitarium published alongside disclosure. |
| EPSS | 0.00191 (~0.2%) — bottom-decile predicted exploitation probability. |
| KEV status | Not listed. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L — network-reachable but requires existing low-privilege auth (PR:L), no UI. |
| Affected versions | RustDesk through commit ff226f6d8013dee2de5a6553abaf67bf32b3e875 (~v1.4.x branch HEAD as of late June 2026). |
| Fixed version | No tagged release at disclosure; track upstream rustdesk/rustdesk main for the capability-clear patch. |
| Exposure footprint | RustDesk clients are typically NAT'd behind the relay/rendezvous server (default hbbs:21115-21119). Shodan shows on the order of a few thousand exposed hbbs/hbbr servers globally — clients themselves are not directly enumerable. |
| Disclosure date | 2026-06-28 |
| Reporter | ashdfrkl, coordinated via VulnCheck advisory channel. |
Sources.
- NVD — CVE-2026-58056
- VulnCheck advisory — RustDesk FileTransfer Session Authorization Scope Bypass
- GHSA-vp3r-hwqm-x826 (CIRCL mirror)
- PoC — bikini/exploitarium (rustdesk-session-permission-pocs)
- RustDesk upstream repository
- RedPacket Security — CVE alert
- CIRCL Vulnerability Lookup — CVE-2026-58056
- FIRST EPSS model
Why this verdict
- Authorization precondition is the gate, not an afterthought — without a valid FileTransfer credential, the dispatcher is never reached. CVSS PR:L understates this in real deployments where FileTransfer-scoped credentials are rarely issued separately.
- Blast radius caps at one host. The bug is a *scope* bypass, not a *peer* bypass — each victim requires its own auth handshake, so this never becomes a wormable or fleet-scale event.
- Role multiplier: low-value role (workstation/end-user endpoint). RustDesk is a remote-support client, not an identity provider, hypervisor, or backup admin server. Even a successful chain hits one user's desktop, not an AD domain or a vSphere cluster.
- Role multiplier: typical role (MSP-managed endpoint fleet). A compromised MSP-side credential vault could enable this at scale, but the credential compromise is itself the headline event — this CVE is the cherry, not the cake. Floor stays HIGH only for MSPs operating FileTransfer-scoped credentials at scale (rare).
- EPSS 0.00191 + no KEV + no observed campaigns — predicted and observed exploitation pressure is minimal.
Why not higher?
HIGH would require either an unauthenticated path or a fleet-scale blast radius. Neither exists: the attacker is already inside the trust boundary the victim drew when issuing the credential, and the chain ends at that single endpoint. For an MSP that issues FileTransfer-only credentials at scale, HIGH is the right call — but that is not the modal deployment.
Why not lower?
LOW would understate I:H — synthesized keyboard and mouse on an unlocked desktop plus screen capture is real impact, and a working PoC exists. A defender who has any RustDesk in their estate should track this and patch on a normal cadence, not ignore it.
Crowdsourced verification payload.
Run on each Windows endpoint you suspect has RustDesk installed. Invoke from an admin PowerShell session: .\Check-RustDeskCVE-2026-58056.ps1. Requires local admin to read Program Files and the per-user config. Output is VULNERABLE, PATCHED, or UNKNOWN per host with the detected version/commit.
#requires -Version 5.1
# Check-RustDeskCVE-2026-58056.ps1
# Detects RustDesk installs vulnerable to the FileTransfer authorization scope bypass.
# Exit codes: 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN/NOT_INSTALLED
$ErrorActionPreference = 'SilentlyContinue'
$VULN_COMMIT = 'ff226f6d8013dee2de5a6553abaf67bf32b3e875'
# Set this to the upstream-tagged fixed version once published.
$FIXED_VERSION = '1.4.1' # placeholder — update when RustDesk tags the capability-clear release
$paths = @(
"$env:ProgramFiles\RustDesk\rustdesk.exe",
"${env:ProgramFiles(x86)}\RustDesk\rustdesk.exe",
"$env:LOCALAPPDATA\RustDesk\rustdesk.exe"
)
$exe = $paths | Where-Object { Test-Path $_ } | Select-Object -First 1
if (-not $exe) {
Write-Output 'UNKNOWN: RustDesk not installed in standard locations'
exit 2
}
try {
$info = (Get-Item $exe).VersionInfo
$ver = $info.ProductVersion
if (-not $ver) { $ver = $info.FileVersion }
} catch {
Write-Output "UNKNOWN: could not read version from $exe"
exit 2
}
Write-Output "Detected RustDesk $ver at $exe"
# Compare semantic version: if lower than FIXED_VERSION -> vulnerable.
function Test-VersionLess($a, $b) {
try { return ([version]$a) -lt ([version]$b) } catch { return $true }
}
if (Test-VersionLess $ver $FIXED_VERSION) {
Write-Output "VULNERABLE: $ver < $FIXED_VERSION (CVE-2026-58056 / commit $VULN_COMMIT)"
exit 1
} else {
Write-Output "PATCHED: $ver >= $FIXED_VERSION"
exit 0
}