A newly published exploit has raised the urgency around a previously understated vulnerability in AnyDesk for Linux. The proof of concept, named AnyPwn, targets a heap buffer overflow in the remote desktop application's session protocol and can execute commands as root before the recipient accepts a connection.
A Quiet Fix Becomes a Serious Security Issue
AnyDesk corrected the underlying problem in version 8.0.3 in June 2026. However, its changelog characterized the update as fixing a bug that could cause a crash. No CVE identifier or dedicated security advisory had been published when the working exploit became available.
The public exploit is designed for AnyDesk Linux 8.0.2 and operates through direct TCP connections on port 7070. It abuses an integer overflow during memory allocation. A malicious packet can cause the application to reserve an extremely small buffer while continuing to process a much larger declared payload, allowing attacker-controlled data to overwrite adjacent memory.
The exploit is not completely reliable because the required heap layout may not always occur. A failed attempt may crash the service rather than run a command. That limitation should not reassure administrators, since repeated attempts and adaptations for additional builds could improve an attacker's success rate.
Exposure Beyond Direct Connections
The vulnerable code path may also be reachable through AnyDesk relay infrastructure, although researchers had not demonstrated the complete remote-code-execution chain through relays. Windows and macOS versions are not reported to be affected by this particular issue.
Recommended Defensive Actions
- Upgrade Linux installations to AnyDesk 8.0.3 or later, with the newest supported release preferred.
- Inventory unmanaged or manually installed copies on workstations, servers and support appliances.
- Restrict inbound access to TCP port 7070 where direct connections are unnecessary.
- Review logs for unexplained crashes, connection attempts and commands launched by the AnyDesk service.
I believe the disclosure process is almost as important as the bug. Describing a security-relevant memory flaw only as a crash can prevent administrators from assigning the correct priority. Once exploit code is public, organizations must assume that scanning and weaponization will follow, even when no CVE exists to trigger conventional vulnerability-management workflows.