Researchers at V12 published a working exploit on October 8 for a vulnerability in AnyDesk's Linux client, according to reporting from LinkedIn and The Hacker News. The exploit, named AnyPwn, targets a heap buffer overflow in the software's session protocol and demonstrates root-level command execution before authentication or connection approval takes place. The flaw was found by Rick de Jager, and version 8.0.3 is identified as the fix.
The published implementation works against AnyDesk Linux version 8.0.2 over direct TCP connections to port 7070. Success depends on memory layout, and failed attempts can crash the service. Whether earlier releases are similarly exploitable has not been comprehensively confirmed. As of October 9, no CVE or formal security advisory had been issued, according to the reporting.
Why it matters
A pre-authentication flaw sits in the part of the software that must process incoming data before it can decide whether to grant access. That means the defect can be reached before the application's normal identity checks or connection approval workflow have run. Strong passwords and careful session approval remain worthwhile, but defenders should not assume those controls address a weakness that operates ahead of them.
Root-level execution raises the stakes further. On Linux, root normally holds broad authority over the operating system. Depending on how a host is configured and what other controls are in place, an attacker running with those privileges could potentially alter files, disrupt services or set up additional access. Those are possible outcomes of privileged compromise, not observations from this case — a distinction that matters when organisations weigh urgency against evidence from their own systems.
A June fix with a one-line changelog entry
AnyDesk's official Linux changelog confirms that version 8.0.3 was released on June 23, 2026. The entry carries a single correction: "Fixed a bug that could lead to a crash." The same page lists version 8.0.4, dated June 30, as addressing compatibility with older distributions. Version 8.1.0, dated September 23, is the most recent Linux release listed at the time of writing.
Newer builds have therefore been available for months. The difficulty is one of communication: the June entry gives no indication of the security implications tied to the reported flaw. A system administrator reading that line would have little basis for telling a routine stability improvement apart from a fix that deserves accelerated deployment. In organisations where updates compete for testing resources, maintenance windows and operational approval, that distinction shapes how quickly software gets replaced.
The wording alone does not establish why AnyDesk presented the change that way, or whether specific customers received separate communications. It does show the limits of treating a short public changelog as the main source for security triage.
Relay exposure and the scope of what was shown
One open question concerns relay exposure. Researchers reportedly reached the vulnerable code through AnyDesk relays using instrumentation, but did not demonstrate a complete relay-based exploit. AnyDesk's June assessment limited the issue to direct Linux connections and said Windows and macOS were unaffected.
Those qualifications matter. The demonstrated capability is serious, but its tested scope should not be stretched into a claim that every AnyDesk installation can be compromised the same way. A research demonstration and an observed attack campaign are different kinds of evidence. Working code does not establish that a particular business has been targeted, that exploitation is widespread, or that every attempt will succeed.
What administrators should actually check
AnyDesk's client settings documentation states that direct connections use TCP port 7070 by default, and that disabling direct connections routes sessions through AnyDesk's servers. The vendor's advanced configuration documentation provides settings for changing the listening port and turning direct connections off. Administrators should therefore inspect real deployment settings rather than assume every installation uses the default.
A scan that checks a single port could miss a customised listener. Finding the application installed does not by itself prove that its direct-connection service is reachable from an untrusted network — host firewalls, network rules and routing all affect that exposure. Reviews should cover internet-facing and internal systems alike, since remote-support tools are often deployed across managed workstations rather than confined to a single network segment.
A crash also needs interpretation. Service failures have many causes, and repeated failures alongside unusual network activity warrant investigation, but a crash on its own is not a reliable conclusion about malicious intent.
The practical task for affected organisations is to establish which versions remain deployed, how those systems can be reached, and whether updates have actually taken effect. The appropriate response is neither to dismiss the issue because a patch shipped in June nor to declare a breach simply because a vulnerable version is present. Version status, reachability, operational importance and available telemetry need to be assessed together.
Watch for whether AnyDesk issues a formal advisory or CVE identifier for the flaw, and for any confirmation that relay-based exploitation is achievable.
