Your AnyDesk deployment on Linux might be accepting root-level commands from strangers, because security researchers just published a full working exploit for a pre-authentication remote code execution flaw, and the attack lands before any approval prompt appears, which means the "accept this connection" dialog that every admin relies on as a safety net isn't part of this chain at all.

The flaw was patched in AnyDesk 8.0.3 back in June, but the changelog described the fix as nothing more than "fixed a bug that could lead to a crash," with no CVE assigned, no advisory published, and no security bulletin issued, so a lot of administrators patched without ever knowing what they were patching.

What Makes the AnyDesk Linux Vulnerability So Serious

Pre-authentication RCE is about as bad as severity gets, and the details here don't soften it.

The exploit runs as root. Not as a limited service account, not as the AnyDesk user. Root.

It doesn't need a session. It doesn't need a user to click anything. It doesn't need credentials.

That table has a gap in it that matters more than any of the technical rows, and it's worth sitting with before we get to the mechanics.

How the AnyPwn Exploit Actually Works

The bug lives in AnyDesk's session protocol handling. Session data moves through what the protocol calls mode-5 stream packets.

The handler takes the declared payload length, adds a 16-byte header, and does that math in 32-bit arithmetic with no overflow check.

That's the whole bug. Everything else is consequence.

The 32-Bit Arithmetic Mistake

The exploit declares a payload length of 0xFFFFFFF0.

Add 0x10 to that and the 32-bit result wraps cleanly to zero.

So the allocator reserves a tiny buffer, while the object still records the original, enormous length. The two numbers no longer agree.

One byte of attacker data is now enough to write past the end of the allocation.

From Overflow to Root

That overflow corrupts fields in whatever heap object happens to sit next to the buffer, and the exploit uses a ROP chain to turn that corruption into an arbitrary command running as root.

The chain is probabilistic. The heap layout has to place a useful target object adjacent to the overflowed buffer. If it doesn't, the service crashes instead of executing.

That's a real constraint, and it means the exploit isn't a guaranteed one-shot. It's a roll of the dice an attacker can repeat.

The Direct Connection Limit and the Relay Question

There's one boundary here that defenders should understand precisely, because it's the difference between "contained" and "not contained."

The published exploit works over direct TCP connections on port 7070. That's what's been demonstrated end to end.

The researchers say the same vulnerable code path is also reachable through AnyDesk's relay servers, which is what the software falls back to when a direct connection can't be established. They validated that with a Frida instrumentation trigger, but they stopped short of demonstrating the full exploit chain over relays.

AnyDesk's June statement framed it narrowly: the vulnerability is "limited to direct connections on Linux (connections that do not go through our relays). Windows and macOS are not affected."

So the vendor says direct only. The researchers say the code path exists on relays too, and they proved it reaches the vulnerable handler without proving the full chain.

Nobody has closed that gap publicly. Treat it as open.

The Silent Patch Problem

Here's the part that should bother you more than the exploit itself.

AnyDesk fixed this in June. The changelog said it addressed "a bug that could lead to a crash."

No CVE. No advisory. No mention of a heap overflow, let alone remote code execution as root.

A crash bug and a pre-auth root RCE get triaged very differently inside a security program. One gets patched when convenient. The other gets an emergency change window.

Administrators who read that changelog and assumed a stability fix had no way to know they were closing a critical hole. That's a transparency failure, and it's the reason this story is still live months after the fix shipped.

The researchers also noted that AnyDesk's download page no longer lists 8.0.2, though it still appears in the changelog. Their read is that the vendor pulled the vulnerable build when the proof-of-concept video went up.

Who Needs to Update Right Now

Anyone running AnyDesk Linux below 8.0.3. That's the floor.

The published exploit's offsets target 8.0.2 specifically, so other builds would need different values. That's a speed bump for a copy-paste attacker, not a barrier for anyone willing to do the work.

The researchers imply that earlier versions, 8.0.1 among them, may share the same vulnerable code path. Exploitation of those builds hasn't been confirmed, but "unconfirmed" is not the same as "safe."

Update to 8.1.0 if you can. It's the current release, and it's past the fix.

How to Reduce Exposure If You Can't Patch Immediately

Sometimes the change window is genuinely out of reach. If that's where you are, do these things today.

• Restrict TCP port 7070. This is the single highest-value mitigation. It cuts off the only demonstrated attack path.
• Block direct connections at the network layer. If every AnyDesk session in your environment runs through relays anyway, you have no reason to leave 7070 open.
• Audit who can reach that port. Internal networks are not a trust boundary. An attacker already inside your perimeter benefits from the same open port your admins use.
• Watch for crash loops in AnyDesk services. The exploit fails by crashing the service when the heap layout doesn't cooperate. Repeated unexpected restarts are a signal, not noise.
• Check whether AnyDesk is even approved software. Remote access tools get installed by users who want convenience and by attackers who want persistence. This is a good moment to reconcile the two lists.
• Restricting port 7070 is a mitigation, not a fix. Patch when you can.

A Pattern in Remote Access Tool Security

This isn't AnyDesk's first heap overflow, and the earlier one makes an instructive comparison.

CVE-2025-27918 was fixed in version 7.0.0 back in April 2025. It affected all AnyDesk platforms, and it involved an integer overflow in user image processing.

Different mechanism, different attack surface, same broad bug class.

AnyDesk also had a much worse year in early 2024, when its production systems were breached outright. That incident led to certificate revocations and forced password resets across the customer base.

Remote access software occupies a uniquely uncomfortable position. It's designed to be reachable, it's designed to execute, and it usually runs with elevated privileges because that's what makes it useful.

Those properties are the product. They're also the attack surface.

The researchers behind this one, Rick de Jager of the V12 security team, found it using V12, a security code review engine. The team's founders previously built Zellic and led the competitive hacking team Perfect Blue. Automated code review surfacing a pre-auth root RCE in widely deployed software is its own signal about how much is still sitting in the session protocol layers of tools like this.

FAQ

What is AnyPwn?

AnyPwn is the name given to a published exploit for a pre-authentication remote code execution flaw in AnyDesk Linux. It targets a heap buffer overflow in AnyDesk's session protocol and can run arbitrary commands as root.

Which AnyDesk versions are affected?

AnyDesk Linux below 8.0.3. The published exploit's offsets target 8.0.2 specifically. Earlier builds like 8.0.1 may share the vulnerable code path, though exploitation of those versions hasn't been confirmed.

Does this affect Windows or macOS?

AnyDesk stated in June that Windows and macOS are not affected and that the issue is limited to direct connections on Linux. The published exploit targets Linux only.

Can the flaw be exploited over AnyDesk relay servers?

Unresolved. The researchers say the same vulnerable code path is reachable via relays and validated that with instrumentation, but they did not demonstrate the full exploit chain over relay connections. AnyDesk's position is that the issue is limited to direct connections.

Is there a CVE for this vulnerability?

No CVE has been assigned as of October 9. AnyDesk never published a formal security advisory either, and the June changelog described the fix only as addressing a bug that could lead to a crash.

What should I do if I can't update right away?

Restrict access to TCP port 7070, which is the only demonstrated attack path. Then patch to at least 8.0.3, and preferably 8.1.0, as soon as your change window allows.

Source: The Hacker News