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
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. |
noisgate verdict.
Downgraded from vendor HIGH to MEDIUM because the decisive friction point is PR:L — the attacker must already hold a valid FileTransfer authorization before any of the bug's behavior is reachable, which collapses the threat population to peers you have already granted partial trust. Blast radius is bounded to the single endpoint that issued the credential; there is no lateral pivot and no unauth path.
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.
What to do — in priority order.
- Inventory RustDesk clients and disable file-transfer-scoped permanent passwords — Open the RustDesk client → ID/Relay Server → Permission settings. Where a permanent password is set, ensure it is *not* scoped to FileTransfer-only; either require interactive approval or use full-control with strong MFA-fronted access. This is the friction point that makes the bug unreachable. Per noisgate MEDIUM SLA there is no formal mitigation deadline, but treat this as 30-day hygiene.
- Restrict RustDesk relay (
hbbs/hbbr) to your tenant via--keyand 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.cometc.). This shrinks who can even *attempt* a FileTransfer handshake to your authenticated peers. - Subscribe to
rustdesk/rustdeskreleases 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. - Add EDR alert for synthesized input from a non-console user-session source on hosts running
rustdesk.exe— Most EDRs can correlateSetCursorPos/SendInput/keybd_eventoriginating 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.
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
}
If you remember one thing.
%LOCALAPPDATA%). For each install with a *permanent* password set, immediately review whether FileTransfer-scoped credentials are issued separately; if yes, rotate or disable. Per the noisgate mitigation SLA for MEDIUM there is no formal mitigation deadline — go straight to the 30-day hygiene window for credential review and to the noisgate remediation SLA of ≤ 365 days to roll out the tagged upstream patch once rustdesk/rustdesk publishes a release containing the capability-reset fix. Accelerate to 90 days remediation if you are an MSP or if you issue FileTransfer-scoped permanent passwords at fleet scale. Do not treat this as KEV-grade — there is no active exploitation evidence and EPSS is in the bottom decile.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
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.