AnyPwn: How an AnyDesk Linux Vulnerability Enables Root RCE Before Connection Approval

When someone connects to a remote desktop application, the person sitting at the computer generally expects to decide whether that connection should be accepted. That approval step is supposed to be a meaningful security boundary.

But a recently published exploit against AnyDesk for Linux demonstrates a dangerous limitation of that assumption.

A vulnerability known as AnyPwn allows an attacker to target a memory corruption flaw in AnyDesk’s session-handling code before the remote user has approved a connection.

Security researcher Rick de Jager of the V12 security team identified the issue, and a public exploit was released on October 8, 2026. The published proof of concept targets AnyDesk for Linux 8.0.2 and reportedly achieves command execution with root privileges through direct network connections.

AnyDesk had already shipped a fix in June 2026. The public AnyDesk Linux changelog describes the correction in version 8.0.3 as a fix for a potential crash, without presenting it as a detailed security advisory.

As of October 13, 2026, the AnyPwn vulnerability has no publicly confirmed CVE identifier, and the existence of exploit code should not be confused with confirmed exploitation in real-world attacks.

What Is AnyPwn?

AnyPwn is the name given to a pre-authentication heap buffer overflow vulnerability affecting AnyDesk’s Linux application.

AnyDesk is widely used for remote support, administration, and accessing computers outside the local network. Its service needs to handle incoming session negotiation traffic before presenting a connection request to the user.

This creates an unavoidable attack surface: remote data must be parsed before the application can decide how to handle a session.

According to the publicly documented AnyPwn technical analysis, the vulnerability exists in the session protocol’s handling of specially crafted packets. Under particular conditions, incorrect size calculations can cause the program to allocate an insufficient amount of memory.

Subsequent processing can then write data beyond the allocated buffer.

Attribut	Einzelheiten
Vulnerability name	AnyPwn
Affected software	AnyDesk for Linux
Demonstrated target	Version 8.0.2
Art der Schwachstelle	Pre-authentication heap buffer overflow
Attack interface	Direct TCP connection, typically port 7070
Reported impact	Command execution as root
User approval required	No, in the demonstrated exploit scenario
Fixed version	8.0.3, released June 23, 2026
Public exploit released	October 8, 2026
CVE identifier	None publicly confirmed as of October 13
Known exploitation in the wild	Not established

It is important to distinguish the demonstrated target from the full possible affected version range. The public exploit is tailored to the Linux 8.0.2 build. Earlier versions may contain similar vulnerable code, but successful exploitation of every previous release has not been established.

Why Pre-Authentication Vulnerabilities Are Especially Dangerous

A normal remote desktop connection involves several stages. A client contacts the remote service, the application negotiates the session, and the user may then approve or reject the request.

The critical detail is that session negotiation requires software to process network input before user authorization has occurred.

That processing may involve decoding protocol fields, parsing structured messages, allocating memory, or maintaining temporary session objects.

If any of those operations contains a memory safety vulnerability, an attacker may be able to exploit the service without successfully authenticating or obtaining permission to control the desktop.

In the AnyPwn case, the attack is associated with the service’s handling of a particular class of stream packets.

The researchers reported that malformed packet data can trigger a heap memory corruption condition. Because the AnyDesk Linux service commonly runs with elevated privileges, successful exploitation can potentially lead directly to root-level code execution.

This creates a very different security impact from an ordinary flaw in which an attacker must first log in or persuade a user to approve a connection.

The Integer Overflow Behind AnyPwn

At the heart of AnyPwn is an arithmetic error that changes how much memory the application allocates for incoming data.

The affected code processes a message containing a payload length supplied by the remote peer. The application then adds space for an additional header.

The problem arises when that calculation uses an integer type that cannot represent the mathematical result.

For example, consider an illustrative 32-bit unsigned size calculation:

#include <stdint.h>
#include <stdbool.h>

bool checked_add_u32(
    uint32_t payload_length,
    uint32_t header_length,
    uint32_t *result
) {
    if (payload_length > UINT32_MAX - header_length) {
        return false;
    }

    *result = payload_length + header_length;
    return true;
}

This is a defensive example demonstrating a checked integer addition, not the AnyDesk source code.

If a program performs an unchecked addition and the mathematical result exceeds the maximum value representable by the integer type, the result may wrap around.

That can produce a much smaller allocation size than the application actually needs.

The dangerous sequence is straightforward: the remote peer controls a length field, the application calculates an incorrect buffer size, the allocator reserves too little memory, and a subsequent operation attempts to process more data than the buffer can safely hold.

The result is a heap buffer overflow.

Heap memory corruption is not automatically equivalent to remote code execution. A malformed packet may simply crash the process.

However, under favorable conditions, an attacker can manipulate the resulting memory corruption to influence control flow and execute instructions.

The AnyPwn researchers published a build-specific proof of concept demonstrating that higher-impact outcome.

Why Root Privileges Change the Impact

On Linux, many remote access applications use privileged background services for operations such as session management and system integration.

If vulnerable network-facing code executes inside such a privileged service, the impact of memory corruption can extend beyond the remote desktop application’s own functionality.

A successful exploit may inherit the security context of that process.

For AnyPwn, the reported outcome is root command execution.

Root privileges may allow an attacker to modify system configuration, install persistence, access files available to privileged processes, or interfere with security monitoring.

The risk therefore depends on both the memory vulnerability and the process privilege model.

The same underlying memory corruption in a tightly sandboxed, unprivileged process could have a substantially different impact.

This illustrates why running complex network-facing parsers with unnecessary privileges creates additional risk.

Does AnyPwn Work Through AnyDesk Relay Servers?

The public findings distinguish between directly reachable services and connections handled through AnyDesk’s relay infrastructure.

The demonstrated exploit targets direct TCP connections to port 7070.

Some research suggests that portions of the vulnerable processing path may also be reachable through relay-related traffic. However, a complete root code execution chain through that route has not been publicly demonstrated to the same standard.

AnyDesk’s reported assessment limited the affected scenario to direct connections on Linux.

Consequently, administrators should not assume that relay-based exploitation has been proven merely because the underlying protocol may share code paths.

The confirmed practical exposure is an affected Linux service reachable through the demonstrated direct-connection attack surface.

Why the June Patch Became More Important in October

AnyDesk released version 8.0.3 on June 23, 2026.

Its official changelog contained only a brief description of a crash-related bug fix.

At the time, administrators reading the release notes might reasonably have considered the update less urgent than a patch explicitly labeled as a security vulnerability.

That changed when public exploit code became available on October 8.

The release of a working proof of concept can materially change the risk profile of an already patched issue. Attackers no longer need to independently identify and develop the original exploit technique to begin studying vulnerable installations.

The difference between disclosure and exploitation remains important, however.

Public code does not prove that attackers are compromising real systems, and the AnyPwn exploit is reportedly sensitive to the target build and memory conditions.

A failed attempt may cause the service to crash instead of providing reliable command execution.

Nevertheless, that uncertainty is not a reason to leave vulnerable remote access services exposed.

How to Check for Vulnerable AnyDesk Installations

The first defensive task is identifying Linux systems that still run affected AnyDesk versions.

On Debian-based systems, package information can often be checked with:

dpkg-query -W anydesk

On RPM-based systems:

rpm -q anydesk

Administrators can also inspect network listeners:

sudo ss -lntp | grep ':7070'

This command helps identify TCP listeners on the relevant port. A listening socket alone does not establish that a service is vulnerable; the running application and exact software version must also be confirmed.

Where centralized endpoint inventory is available, security teams should search for AnyDesk Linux installations running 8.0.2 or earlier versions potentially sharing the affected code.

Die official AnyDesk Linux download page provides current Linux packages. At the time of this analysis, version 8.1.0 is the latest listed release.

How to Mitigate AnyPwn

Updating AnyDesk for Linux to version 8.0.3 or later is the primary remediation.

Because more recent releases also include other fixes and improvements, administrators should normally select the latest compatible version rather than stop at the minimum patched build.

If an immediate upgrade is impossible, restricting direct inbound connectivity to the AnyDesk service can reduce exposure.

For example, organizations can limit TCP port 7070 to trusted management networks and avoid exposing remote access listeners to arbitrary internet hosts.

AnyDesk should also be removed from Linux systems where it has no legitimate operational purpose.

Security teams should review service crashes, unexpected process execution, and suspicious network connections associated with unpatched installations. These observations are useful investigation signals, although they are not specific proof of AnyPwn exploitation.

Frequently Asked Questions

Does AnyPwn require user interaction?

The published direct-connection exploit does not require a user to approve an incoming remote desktop session.

Which AnyDesk version fixes AnyPwn?

The vulnerability was fixed in AnyDesk for Linux 8.0.3, released June 23, 2026. Upgrading to a newer supported release is recommended.

Does AnyPwn affect Windows or macOS?

The public vulnerability reports identify Linux as the affected platform. Windows and macOS exploitation has not been established for this specific issue.

Is there a CVE for AnyPwn?

No publicly confirmed CVE identifier was identified as of October 13, 2026. It should not be confused with older, unrelated AnyDesk vulnerabilities.

Is AnyPwn being exploited in real attacks?

A public proof of concept exists, but confirmed exploitation in the wild has not been established by the reviewed sources.

Abschließende Überlegungen

AnyPwn illustrates a problem that extends far beyond remote desktop software.

Applications often expose complex protocol-processing functionality before authentication or user authorization takes place. If that code contains a memory corruption vulnerability and runs with elevated privileges, the application’s normal approval workflow may provide little protection.

The vulnerability also demonstrates how a seemingly routine stability update can later become a critical security concern when the underlying flaw is publicly understood.

For administrators, the priorities are clear: identify outdated AnyDesk Linux installations, apply supported updates, and reduce unnecessary exposure of remote access services.

A connection approval dialog cannot protect a system from a vulnerability that executes before the dialog is ever displayed.