NEWS

Researchers Publish Working Exploit for Pre-Auth AnyDesk Linux Flaw That Gives Root Access

A public 'AnyPwn' exploit abuses a heap overflow in AnyDesk Linux 8.0.2's session protocol for pre-auth root RCE; AnyDesk fixed it quietly in 8.0.3.

Dylan H.

News Desk

October 9, 2026
7 min read
Researchers Publish Working Exploit for Pre-Auth AnyDesk Linux Flaw That Gives Root Access

Researchers Publish Working Exploit for Pre-Auth AnyDesk Linux Flaw That Gives Root Access

Security researchers have published a full working exploit, dubbed AnyPwn, for a pre-authentication remote code execution flaw in AnyDesk Linux that grants attackers root access before anyone on the target machine approves the incoming connection. The exploit, released on GitHub on October 8, 2026, targets AnyDesk Linux 8.0.2 and abuses a heap buffer overflow in the software's session protocol, reachable over the direct TCP connection port 7070 that AnyDesk uses when a relay server isn't in play. The underlying bug was discovered by Rick de Jager of the V12 security team, disclosed to AnyDesk on June 22, 2026, and quietly patched in version 8.0.3 the following day — but AnyDesk's changelog described the fix only as having "fixed a bug that could lead to a crash," with no CVE assigned and no security advisory published either at patch time or since.


Incident Details

AttributeValue
Exploit NameAnyPwn
Vulnerability ClassHeap buffer overflow via 32-bit integer overflow → pre-auth root RCE
CVE IDNone assigned as of October 9, 2026
Discovered ByRick de Jager, V12 security team
Disclosed To VendorJune 22, 2026
Affected ProductAnyDesk Linux (session protocol handler)
Affected Versions8.0.2 and earlier (8.0.1 suspected, unconfirmed)
Fixed Version8.0.3 (released June 2026); current release is 8.1.0
Attack VectorNetwork — direct TCP connection on port 7070
Authentication RequiredNone (pre-auth, zero-click)
Privileges GainedRoot
Public Exploit ReleasedOctober 8, 2026 (GitHub)
Vendor AdvisoryNone published; changelog entry only

How It Worked

The Root Cause: An Unchecked 32-Bit Addition

AnyDesk's session protocol on Linux processes mode-5 stream packets, and the handler responsible for them calculates how much heap memory to allocate by adding a fixed 16-byte header to the payload length declared in the incoming packet — using 32-bit arithmetic with no overflow check. A remote, unauthenticated client can declare a payload length of 0xFFFFFFF0. Adding the 16-byte header (0x10) to that value wraps the 32-bit sum back to zero, so the allocator reserves a tiny buffer while the object internally still records the original, enormous declared length. The result is that even a single byte of attacker-supplied data written against that length field writes past the end of the undersized allocation.

From Overflow to Root Shell

Because the corrupted write lands in adjacent heap memory, the overflow can clobber fields in neighboring heap objects. The published AnyPwn exploit chains this corruption into a ROP (return-oriented programming) chain that ultimately executes an arbitrary command as root — all before the AnyDesk service on the target has required any user approval of the incoming session, since the vulnerable code runs in the pre-authentication connection-handling path.

Two important caveats temper the exploit's reliability. First, it is probabilistic: successful exploitation depends on the heap layout placing a specific target object immediately adjacent to the overflowed buffer at the moment of the attack; if it doesn't, the AnyDesk service simply crashes rather than executing the attacker's payload. Second, the offsets hardcoded in the published proof-of-concept are specific to the 8.0.2 build — reusing the exploit against a different build or distribution package would require recalculating those offsets.

Relay Servers May Also Be Exposed

AnyDesk told researchers in June that the flaw is "limited to direct connections on Linux (connections that do not go through our relays)," and that Windows and macOS are unaffected. However, the V12 researchers report that the same vulnerable code path is also reachable through AnyDesk's relay infrastructure, which the client falls back to when a direct connection can't be established. They validated this reachability using a Frida instrumentation hook to confirm the vulnerable function executes on the relay path, but stopped short of demonstrating a complete working exploit chain over relays. That leaves open the possibility that machines believed to be shielded by NAT or firewalls — because they never accept direct inbound connections — could still be reachable via AnyDesk's own relay network.

Impact Assessment

Impact AreaDescription
Full Host CompromiseSuccessful exploitation hands an unauthenticated remote attacker root on the target Linux host, with no user interaction or approval needed
Silent Patch WindowAnyDesk's vague "fixed a bug that could lead to a crash" changelog entry gave administrators no signal to prioritize the June 8.0.3 update as a security fix
Unpatched Fleet ExposureAny AnyDesk Linux 8.0.2 (or earlier) instance still reachable on TCP 7070 remains exploitable now that a working PoC is public
Relay Path UncertaintyAnyDesk's "direct connections only" scoping may not hold if the relay code path proves fully exploitable, widening exposure beyond directly-reachable hosts
Reliability Trade-offThe exploit's probabilistic nature (heap layout dependent) means failed attempts crash the AnyDesk service — a visible but disruptive signal rather than silent compromise
Server/Kiosk RiskLinux systems running AnyDesk unattended for remote support (servers, kiosks, jump boxes) are the highest-risk targets since no local user needs to approve anything

Recommendations

For System Administrators

  • Update AnyDesk Linux to version 8.0.3 or later immediately — the current release is 8.1.0. Treat this as an urgent security patch despite the vague changelog wording, not a routine stability fix.
  • Audit all Linux hosts for AnyDesk installations still running 8.0.2 or earlier, especially unattended servers, kiosks, and remote-support jump boxes where no human would notice an unapproved connection attempt.
  • Where immediate patching isn't possible, restrict inbound access to TCP port 7070 at the host or network firewall level to block direct-connection exploitation.

For Security Teams

  • Monitor for AnyDesk service crashes on Linux hosts, which may indicate failed exploitation attempts given the exploit's probabilistic, heap-layout-dependent behavior.
  • Do not assume NAT or firewall isolation fully protects a host — the researchers' Frida-validated finding that the vulnerable code path is also reachable via AnyDesk's relay servers means relay-dependent hosts may not be out of scope.
  • Flag AnyDesk as a monitored remote-access tool in EDR/XDR tooling given the now-public exploit, and treat any anomalous AnyDesk process behavior (unexpected child processes, privilege changes) as a high-priority alert.

For MSPs and IT Support Providers

  • Confirm the AnyDesk version deployed across every managed endpoint where it's used for remote support, and push the 8.0.3+ update across the fleet rather than relying on individual customers to self-patch.
  • Communicate proactively with clients: AnyDesk's own changelog did not flag this as a security issue, so customers relying solely on vendor release notes would have no reason to prioritize the update.

Key Takeaways

  1. The AnyPwn exploit gives unauthenticated attackers root access on vulnerable AnyDesk Linux 8.0.2 hosts with no user approval required — a pre-auth, zero-click flaw.
  2. The root cause is a classic 32-bit integer overflow (declaring a 0xFFFFFFF0 payload length) that produces an undersized heap allocation, which the exploit turns into arbitrary code execution via a ROP chain.
  3. No CVE has been assigned and AnyDesk published no formal security advisory — the only public record is a vague changelog line in the 8.0.3 release from June 2026.
  4. The exploit is probabilistic and build-specific: it depends on heap layout and uses offsets hardcoded for the 8.0.2 build, so it is not universally reliable out of the box.
  5. AnyDesk's claim that the issue is limited to direct Linux connections may be incomplete — researchers found the same vulnerable code path reachable via AnyDesk's relay servers, though they did not fully demonstrate exploitation over that path.
  6. Administrators should update to AnyDesk Linux 8.0.3 or later (current: 8.1.0) immediately and restrict TCP port 7070 exposure wherever patching is delayed.

Sources