A public exploit is now available for a pre-authentication AnyDesk Linux flaw that can lead to root-level remote code execution before a user approves a remote session. For small businesses and government contractors, the lesson is not just “patch AnyDesk.” It is that remote access tools need the same exposure controls, monitoring, and emergency review process as VPNs, firewalls, and other edge services.

The issue was reported by The Hacker News after researchers published a working proof of concept for what they call AnyPwn. The researchers’ write-up says the flaw affects AnyDesk Linux 8.0.2 and abuses the session protocol in a way that can corrupt memory and execute commands as root when the service is reachable directly over TCP/7070. AnyDesk fixed the issue in version 8.0.3 in June, but the original changelog described it as a crash-related bug rather than a security advisory, and no CVE was assigned as of October 9.

What Happened

The published exploit targets AnyDesk Linux running in service mode. In the demonstrated path, the attacker connects to the AnyDesk service directly and triggers a heap buffer overflow before the normal remote-control approval flow matters. That distinction is important: if a remote access product exposes a vulnerable pre-authentication service, user approval prompts are not a meaningful security boundary.

The exploit is not described as universally reliable. It targets a specific Linux build and depends on heap layout conditions; in many attempts the service may crash instead of executing attacker-controlled commands. That should not make defenders comfortable. Once exploit code is public, reliability tends to improve, and even crash behavior can become an operational denial-of-service problem for exposed remote support infrastructure.

The researchers also noted that the vulnerable code path appears reachable through AnyDesk relay behavior, although the public full exploit demonstration focuses on direct TCP/7070 access. AnyDesk previously characterized the issue as limited to direct Linux connections and stated that Windows and macOS were not affected.

Why It Matters

Remote monitoring and remote access tools sit in the blast radius of incident response. They are trusted by help desks, MSPs, IT administrators, and sometimes unmanaged vendor support workflows. That makes them attractive to attackers even when they are not malware. If an adversary can compromise the remote access layer, they may inherit admin-level reach into the environment without needing phishing, password spraying, or endpoint malware first.

This is especially relevant for SMBs and government contractors because AnyDesk and similar tools are often installed for convenience, emergency access, or vendor support and then forgotten. A contractor may have a handful of Linux workstations, jump boxes, lab systems, or field devices where remote access agents were installed during troubleshooting and never added to the formal asset inventory.

Defensive Takeaways

  • Patch AnyDesk Linux immediately. Update Linux installations to at least AnyDesk 8.0.3. If possible, move to the latest available version rather than stopping at the minimum fixed build.
  • Find every AnyDesk installation, not just managed endpoints. Check servers, engineering workstations, test boxes, developer systems, lab machines, and vendor-maintained Linux devices.
  • Restrict TCP/7070. Do not allow direct inbound access to AnyDesk services from untrusted networks. Use host firewalls, network ACLs, VPN/ZTNA policy, or segmentation to limit who can reach remote access services.
  • Review remote support exceptions. If vendors require remote access, document the business owner, access path, allowed source, expiration date, and logging requirement.
  • Monitor for crashes and unexpected service restarts. A failed exploit attempt may look like instability before it looks like compromise.
  • Hunt for remote access sprawl. Inventory AnyDesk alongside ScreenConnect, SimpleHelp, TeamViewer, RustDesk, Splashtop, Atera, NinjaOne, and other support tools.
  • Treat remote access tools as privileged infrastructure. They need MFA, network restrictions, update SLAs, logging, and ownership—not “install and forget” handling.

Bulwark Black Assessment

This is a classic exposure-control problem. The exploit details are technical, but the defensive decision is straightforward: remote access services should not be casually reachable, and patch notes that understate security impact cannot be the only trigger for action.

For organizations supporting government contracts, this also touches basic cyber hygiene and evidence. If a remote access tool exists in the environment, security teams should be able to show who owns it, why it exists, what version is deployed, how it is restricted, and where its logs go. If that evidence does not exist, the tool is not just operational convenience—it is unmanaged privileged access.

Source: The Hacker News — Researchers Publish Working Exploit for Pre-Auth AnyDesk Linux Flaw That Gives Root Access. Additional technical context: V12 Security AnyPwn research repository.