A publicly released proof-of-concept exploit targeting AnyDesk Linux 8.0.2 lets unauthenticated remote attackers execute arbitrary commands as root over TCP port 7070, with no credentials, no user approval, and no interaction required. Here’s the full technical analysis: how the exploit works, and what administrators need to do right now.
Security researchers have published a fully functional exploit for a critical pre-authentication remote code execution vulnerability in AnyDesk Linux, the remote desktop and support application deployed widely in enterprise environments. The vulnerability, dubbed AnyPwn, lets an unauthenticated attacker achieve root-level command execution on a target system before any user approves a remote connection, and in some cases, without the victim ever knowing a connection attempt occurred.
The flaw sits in AnyDesk Linux version 8.0.2 and was quietly patched in version 8.0.3 back in June 2026. AnyDesk’s changelog buried the fix under the description “fixed a bug that could lead to a crash,” with no CVE identifier assigned, no security advisory published, and no notice to downstream users that their systems had been exposed to a zero-click, pre-auth root exploit. The public proof-of-concept code landed on GitHub on October 8, 2026, which put renewed urgency on any organization still running the vulnerable build.
The exploit works over direct TCP connections to port 7070. It requires no authentication tokens, no unattended-access passwords, and no user interaction. The AnyDesk service on Linux runs as root by design, so successful exploitation grants full control over the target system: files, processes, kernel modules, user accounts, and security configurations included.
Discovery, disclosure, and the missing CVE
The vulnerability was found by Rick de Jager of the V12 security team, using V12’s AI-powered security code review platform. V12’s founders previously built the security firm Zellic and led the competitive hacking team Perfect Blue, which has a track record of finding high-severity vulnerabilities in complex software.
V12 disclosed the issue publicly on June 22, 2026. AnyDesk acknowledged the report the following day and shipped the fix in version 8.0.3 within the same month, a disclosure timeline of about one week from initial report to patched release.
What followed the fix was less responsible. No CVE was requested or assigned as of October 9, 2026. No security advisory appeared on AnyDesk’s website or through channels like NIST’s National Vulnerability Database. The changelog entry for version 8.0.3 described the fix as addressing “a bug that could lead to a crash,” language that would cause any security team scanning release notes to deprioritize the update. The vulnerable 8.0.2 binary was quietly pulled from AnyDesk’s download page, though it still shows up in historical changelog entries.
“The vendor appears to have deleted (?) the 8.0.2 build of AnyDesk upon the release of our PoC video,” the V12 researchers noted in their writeup, the question mark doing considerable rhetorical work.
The missing CVE is a real problem for enterprise vulnerability management. Without an identifier, automated patch management systems, vulnerability scanners, and SIEM correlation rules have nothing to flag affected installations against. Security teams relying on standard tooling may have no idea their AnyDesk Linux deployments are exploitable.
The vulnerability: integer overflow in mode-5 stream packet handling
The vulnerability lives in AnyDesk’s session protocol, specifically in the handler that processes mode-5 stream packets, the packet type used for data exchange during remote client connections. Understanding the flaw means walking through the packet structure and the arithmetic error that makes exploitation possible.
📬 Stay Ahead of Cyber Threats
Get the latest cybersecurity news, critical vulnerabilities, threat intelligence, tutorials, and exclusive giveaways delivered straight to your inbox. No spam. Unsubscribe anytime.
Subscribe to the Newsletter →Packet structure
A mode-5 packet on an assigned stream follows this binary layout:
u16be frame_lenu16be assigned_stream_idu8 stream_mode_prefix (0x00)varint mode5_declared_lenu8[] mode5_body
Under normal operation, mode5_declared_len must not exceed the number of bytes remaining in the frame, and the protocol validates that relationship so the declared payload length matches the data actually present. The vulnerable code path skips that validation and instead calculates the backing memory allocation straight from the unvalidated 32-bit declared length value.
The integer wrap
The bug shows up when AnyDesk calculates the size of the memory allocation needed to store the incoming stream object. The handler adds a 16-byte object header (0x10) to the attacker-controlled mode5_declared_len value, using 32-bit unsigned arithmetic with no overflow check.
The exploit declares a payload length of 0xFFFFFFF0 (4,294,967,280 in decimal). Adding the 16-byte header:
0xFFFFFFF0 + 0x10 = 0x1_0000_0000
Because the arithmetic happens in 32-bit space, the result wraps:
(uint32_t)(0xFFFFFFF0 + 0x10) = 0x00000000
The allocator gets a size request of zero bytes (or, for values between 0xFFFFFFF0 and 0xFFFFFFFF, allocations of 0 to 15 bytes). A tiny memory region gets reserved, but the object’s internal metadata still records the original large length value (0xFFFFFFF0) and sets its data pointer to allocation_base + 0x10.
The result: copying even a single byte of attacker-supplied body data writes past the end of the undersized allocation. The attacker doesn’t need to send four gigabytes of data. The outer network frame stays small, its varint-encoded length field triggers the integer wrap, and its body supplies the overflow bytes.
From out-of-bounds write to code execution
The out-of-bounds write corrupts fields in adjacent heap objects. Under the right memory layout conditions, the attacker overwrites dispatch-related fields in a neighboring victim object, including a chosen virtual method table (vtable) pointer and a stack-pivot gadget address. When the AnyDesk service subsequently processes this corrupted object, execution control transfers to attacker-specified memory through a Return-Oriented Programming (ROP) chain.
The general outline of the chain is that it writes the attacker’s desired command string into fixed scratch memory, loads its address as the first argument, and calls the target build’s system() PLT (Procedure Linkage Table) entry, achieving arbitrary command execution with the privileges of the AnyDesk process. On Linux, that process runs as root.
The exploit: heap grooming, ROP sprays, and probabilistic reliability
The published AnyPwn exploit is technically sophisticated and shows a clear understanding of glibc heap allocator internals. It’s not a simple send-packet-get-shell script. Exploitation is probabilistic, dependent on heap layout conditions that the exploit tries to influence through memory grooming. We’re describing the overall structure of the attack at a conceptual level rather than reproducing the exploit’s working parameters.
allocator grooming via mode-5 spray
The exploit begins by sending a large batch of persistent mode-5 objects across a graded range of sizes. This range-based spray populates the allocator’s relevant size classes, creating a dense field of controlled allocations, which reduces dependence on any single exact allocation size and increases the odds that a later allocation lands adjacent to a target object.
victim object placement
Following the size-graded spray, the exploit opens several additional client connections to the AnyDesk service. Each connection causes the service to allocate internal client objects. These candidate victim objects sit among the groomed allocations, which increases the chance that at least one victim object ends up positioned right after the wrapped (undersized) allocation when the overflow triggers.
triggering the overflow
With the heap prepared, the exploit sends the malicious mode-5 packet declaring the oversized length value. The integer wrap allocates a minimal buffer, and the packet’s body then overflows it, overwriting control fields in the adjacent victim object, specifically the vtable pointer and a stack-pivot gadget address.
ROP object spray
The exploit sprays a set of identical objects, each containing a long ret-gadget sled followed by the ROP chain itself. The repetition and the wide sled give the corrupted stack pivot many equivalent landing points, so the pivot doesn’t need to land at one exact address within a single copy of the chain; the sled slides execution forward into the functional payload regardless.
Triggering execution
The exploit continues normal setup operations on each victim client connection. When the service processes the corrupted victim object, it uses the overwritten control data, transferring execution through the stack pivot into the sprayed ROP chain, which finishes the attack by invoking system() with the attacker’s command.
Reliability constraints
The V12 researchers are upfront about the exploit’s limitations. The heap layout has to place a target object adjacent to the overflowed buffer, or the overflow corrupts unrelated memory and the AnyDesk service crashes instead of executing the attacker’s command. The published offsets target the specific binary layout of AnyDesk Linux 8.0.2 on x86_64; other builds, architectures, or versions would need recalculated offsets. The researchers note that earlier versions such as 8.0.1 may share the vulnerable code path, though exploitation of those versions hasn’t been confirmed.
This probabilistic nature means the exploit isn’t a guaranteed one-shot kill. In a real attack, an adversary might need several connection attempts, treating service crashes as noise, before landing successful code execution. For a persistent threat actor targeting high-value infrastructure, though, a probabilistic exploit with no authentication requirement and root-level impact is still a potent weapon.
Direct connection vs. relay: the unresolved attack surface
AnyDesk’s initial response to the disclosure stated that the vulnerability was “limited to direct connections on Linux (connections that do not go through our relays)” and that Windows and macOS were not affected.
The V12 researchers partially pushed back on that assessment. Using Frida instrumentation, they confirmed the vulnerable code path is also reachable through AnyDesk’s relay servers, the intermediary infrastructure AnyDesk uses when a direct peer-to-peer connection can’t be established. They only validated the trigger condition over relays, though; they didn’t demonstrate the full root-code-execution chain through relay connections.
That distinction matters for threat modeling. If the flaw is fully exploitable over relays, the attack surface expands a great deal: any internet-connected Linux system running AnyDesk 8.0.2 in service mode would be vulnerable regardless of firewall rules blocking TCP port 7070, since relay connections travel through AnyDesk’s own infrastructure. The researchers left this question open, and AnyDesk hasn’t offered a definitive answer.
The confirmed, demonstrated attack vector remains a direct TCP connection to port 7070. Organizations should treat that as the primary exposure while keeping in mind that relay-based exploitation hasn’t been ruled out.
Why this is worse than typical remote-access vulnerabilities
Remote desktop and support tools sit in a uniquely dangerous spot in enterprise security architecture. They’re installed on high-value targets (domain controllers, database servers, developer workstations, jump hosts) and trusted by default. Security teams whitelist their processes, open firewall rules for their traffic, and rarely scrutinize their update mechanisms.
AnyPwn exploits that trust model at its foundation. The vulnerability needs:
No authentication: no AnyDesk account, no access token, no unattended-access password. No user interaction: no victim has to click “Accept” on a connection prompt, since the exploit runs before the session approval stage. No prior access: no phishing, no credential theft, no lateral movement prerequisite. And root privileges by default, since the AnyDesk Linux service runs as root, so successful exploitation immediately grants the highest privilege level on the operating system.
Compare that to the typical remote-access attack chain, which usually involves social engineering a user into accepting a connection, stealing an unattended-access password, or exploiting a post-authentication flaw. AnyPwn collapses the entire chain into a single network packet exchange.
For organizations running AnyDesk Linux on internet-facing servers, cloud instances with permissive security groups, or internal systems reachable from compromised network segments, the risk is acute. An attacker who achieves root through AnyPwn can install persistent implants, exfiltrate data, deploy ransomware, pivot to other systems, and disable security controls, all from a single pre-authentication connection.
Broader context: AnyDesk’s security track record
AnyPwn doesn’t exist in isolation. AnyDesk’s recent security history includes several incidents that, taken together, raise questions about the vendor’s secure development lifecycle and vulnerability communication practices.
CVE-2025-27918 (April 2025): A separate heap buffer overflow in AnyDesk’s user image processing affected all platforms (Windows, macOS, and Linux). It involved an integer overflow in a different code path from AnyPwn’s session protocol flaw and was fixed in version 7.0.0. Two distinct heap overflow vulnerabilities in AnyDesk’s codebase within roughly 14 months points to systemic issues in input validation and memory safety.
January 2024 production breach: AnyDesk’s own production systems were compromised in early 2024. The breach led to the revocation of code-signing certificates and forced password resets for all user accounts. It didn’t directly expose end-user systems, but it showed that AnyDesk’s internal security posture had gaps a well-resourced attacker could exploit.
Quiet disclosure patterns: The handling of AnyPwn, no CVE, no advisory, a changelog entry describing a critical pre-auth RCE as a “crash bug,” follows a pattern that erodes trust. Security teams depend on vendors to communicate the severity and scope of vulnerabilities clearly. Minimizing a root-level remote code execution flaw as a stability fix isn’t a defensible communication strategy, whatever the vendor’s reasons.
The remote-access tool category as a whole has become a prime target for threat actors. AnyDesk, TeamViewer, and similar platforms have been repeatedly abused as post-compromise persistence mechanisms in ransomware campaigns and nation-state intrusions. A pre-authentication exploit in one of these tools pushes the risk from “attacker uses the tool after breaking in” to “attacker breaks in through the tool itself.”
Remediation and mitigation: what administrators must do now
The following actions are ordered by priority. Organizations running AnyDesk on Linux should treat this as an urgent patching event, not a routine update cycle.
1. Update AnyDesk Linux immediately. Upgrade from version 8.0.2 (or any earlier 8.x build) to version 8.0.3 or later. The latest available release as of this writing is 8.1.0. Verify the installed version with anydesk --version or by checking the package manager. AnyDesk’s download page no longer lists 8.0.2, but systems installed from cached packages, internal repositories, or container images may still run the vulnerable build.
2. Audit for TCP port 7070 exposure. Identify all Linux systems where AnyDesk is installed and determine whether TCP port 7070 is reachable from untrusted networks. Use firewall rules, cloud security groups (AWS Security Groups, Azure NSGs, GCP Firewall Rules), and VPN gateway policies to restrict inbound access to this port. If AnyDesk must accept direct connections, limit source addresses to known, trusted IP ranges.
3. Review service logs and system integrity. On any system that was running AnyDesk 8.0.2 with port 7070 exposed, run a focused incident response review. Check AnyDesk service logs for unusual connection patterns, repeated connection attempts followed by service crashes (which may indicate failed exploit attempts), unexpected root-level processes, and anomalous outbound network connections. Look for artifacts consistent with the exploit’s heap-spray phases, like an unusual number of short-lived client connections.
4. Restrict AnyDesk to relay-only mode if feasible. If operational requirements allow it, configure AnyDesk to connect exclusively through relay servers and disable direct connection mode. This removes the confirmed attack vector while the relay-based exploitation question stays unresolved. It’s a mitigation, not a fix, given the V12 team’s Frida-based findings on relay reachability.
5. Monitor for exploitation indicators. Deploy detection rules for repeated TCP connections to port 7070 followed by AnyDesk service restarts. Because the exploit is probabilistic, an attacker may generate a pattern of crashes before achieving successful code execution. Endpoint detection and response (EDR) tools should alert on AnyDesk spawning unexpected child processes, particularly shells or interpreters invoked by the root-owned AnyDesk service.
6. Segment AnyDesk hosts. Where possible, isolate AnyDesk Linux systems into dedicated network segments with strict ingress and egress controls. Limit the blast radius of a successful compromise by making sure a rooted AnyDesk host can’t directly reach sensitive internal infrastructure without traversing additional authentication layers.
Detection guidance and indicators
Because AnyPwn exploits the service before any user-facing session is established, traditional AnyDesk connection logs may not capture the attack. Administrators should watch for:
Process creation events where the AnyDesk service (running as root) spawns /bin/sh, /bin/bash, python, perl, curl, wget, or other interpreters and downloaders. Memory anomalies, such as AnyDesk service crashes followed by automatic restarts, particularly when preceded by connection attempts from unfamiliar IP addresses. Network patterns showing bursts of TCP connections to port 7070 from a single source, especially connections that terminate abruptly without completing the AnyDesk handshake. And heap artifacts, which are difficult to observe in production but may show up in memory forensics on a crashed AnyDesk process as a pattern of size-graded allocations consistent with the exploit’s grooming phase.
Frequently asked questions
Is AnyDesk on Windows or macOS affected by AnyPwn? No. AnyDesk has confirmed, and the V12 researchers’ analysis supports, that the vulnerable code path exists only in the Linux build.
Has a CVE been assigned to this vulnerability? As of October 9, 2026, no CVE identifier has been assigned and AnyDesk hasn’t issued a formal security advisory. The vulnerability is tracked publicly under the name “AnyPwn” by the V12 security team.
Can AnyPwn be exploited over AnyDesk relay connections? The vulnerable code path is reachable via relay connections, confirmed through Frida instrumentation testing. The full exploit chain achieving root code execution hasn’t been demonstrated over relays, though. Direct TCP connections to port 7070 remain the confirmed and demonstrated attack vector.
Does the exploit work every time? No. It’s probabilistic, depending on the heap allocator placing a target object adjacent to the overflowed buffer. If the memory layout is unfavorable, the AnyDesk service crashes instead of executing the attacker’s command. The published offsets are specific to AnyDesk Linux 8.0.2 on x86_64.
What should I do if I can’t patch immediately? Restrict inbound access to TCP port 7070 at every network boundary: firewalls, VPN gateways, cloud security groups. Disable AnyDesk’s direct connection mode and enforce relay-only connections. Monitor AnyDesk service logs and system integrity closely until patching is complete.
Remote-access tools as attack infrastructure
AnyPwn is a stark reminder that remote-access and remote-support software is one of the highest-risk categories in enterprise environments. These tools get deep system privileges, run persistently, keep open network listeners, and are often excluded from the scrutiny applied to other network services. When a vulnerability shows up in this class of software, the impact isn’t incremental.
The security community has watched this pattern repeat across multiple vendors and years: legitimate remote-management tools get installed, trusted, and forgotten, until a vulnerability or a compromised credential turns them into an attacker’s persistent foothold. The 2024 AnyDesk production breach, the 2025 CVE-2025-27918 heap overflow, and now AnyPwn in 2026 form a trajectory that should push every organization to re-evaluate whether its remote-access deployment is truly necessary, properly segmented, and aggressively monitored.
For the immediate term: patch AnyDesk Linux to 8.0.3 or later, lock down TCP port 7070, and check whether any system was exposed to untrusted networks during the window between the June fix and the public exploit release. The exploit code and the offsets are both public now, so the only real question is whether your systems are still running 8.0.2.
This analysis is based on the technical documentation published by the V12 security team, AnyDesk’s public changelog and download infrastructure, and independent review of the AnyPwn proof-of-concept code released on October 8, 2026. Organizations requiring incident response assistance related to this vulnerability should engage a qualified cybersecurity firm.
Update: This article will be updated if AnyDesk assigns a CVE identifier, publishes a formal security advisory, or provides additional clarification regarding relay-based exploitability.
