CVE-2026-109390 · AnyDesk Linux Pre-Auth Heap Buffer Overflow in Session Protocol…

01 · The Real Story

A locksmith's spare key that only fits one brand of lock on one kind of door — but that door is wide open

CVE-2026-109390 is a heap-based buffer overflow in AnyDesk for Linux versions 8.0.0 through 8.0.2 (fixed in 8.0.3, released June 23, 2026). The flaw lives in the session protocol's mode-5 stream packet handler: a remote, unauthenticated attacker sends a crafted packet declaring a payload length of 0xFFFFFFF0. When the 16-byte object header is added, 32-bit arithmetic wraps to zero, causing a tiny heap allocation while the object retains the original oversized logical length. Attacker-controlled data overflows into adjacent heap objects. On Linux, where AnyDesk's systemd service runs as root by default, successful exploitation yields pre-auth arbitrary command execution as root — no credentials, no user approval, no click required. Windows and macOS are not affected. The published PoC ('AnyPwn' by Rick de Jager of V12 Security) targets TCP port 7070 on direct connections.

The vendor CVSS of 9.8 is technically accurate for the *isolated vulnerability mechanics* — network-reachable, no auth, no interaction, full CIA impact. But it ignores three compounding narrowing factors that matter at fleet scale: (1) only Linux is vulnerable, eliminating the vast majority of the AnyDesk install base; (2) exploitation requires a direct TCP/7070 connection, not AnyDesk's standard relay infrastructure (relay-based triggering reached the vulnerable code path in testing but the full RCE chain through relays remains unconfirmed); and (3) the published exploit is probabilistic and build-specific, requiring exact heap-layout adjacency and hard-coded offsets for AnyDesk Linux 8.0.2 — a miss crashes the service instead of granting a shell. A CRITICAL label here sends the wrong triage signal to a team that also has relay-reachable or Windows-affecting bugs in the queue. HIGH (8.0) better reflects the real deployment-adjusted risk.

"Pre-auth root RCE on AnyDesk Linux, but platform and network constraints shrink the real blast radius"

02 · The Attack Path

5 steps from start to impact.

STEP 01

Target discovery — locate exposed AnyDesk Linux instances

The attacker queries Censys, Shodan, or FOFA for services on TCP/7070 presenting AnyDesk banners. Censys reports over 230,000 AnyDesk assets globally, though most are Windows or macOS and many route through AnyDesk's relay infrastructure rather than exposing direct TCP. The attacker filters for Linux hosts with direct exposure.

Conditions required:

Target host runs AnyDesk for Linux 8.0.0–8.0.2
AnyDesk is listening on TCP/7070 and reachable from the attacker's network (not behind NAT or relay-only)

Where this breaks in practice:

Most enterprise AnyDesk deployments use relay connections, not direct TCP exposure
AnyDesk 8.0.3 has been available since June 2026 — auto-updating or well-maintained hosts are already patched
The Linux share of AnyDesk's install base is a small minority; Windows dominates

Detection/coverage: Shodan/Censys/FOFA queries for port:7070 anydesk identify exposed instances. Tenable plugin 298245 detects vulnerable versions.

STEP 02

Initiate unauthenticated session — connect to stream protocol

The attacker establishes a raw TCP connection to port 7070 and enters the AnyDesk session protocol. No credentials or session tokens are required; the mode-5 stream handler is reachable before any user approval step on the victim side. The attacker begins the heap-shaping phase by sending ~100 persistent mode-5 objects across size classes (0x1–0x17f1 in 0x10 increments) to influence heap layout.

Conditions required:

Network path to TCP/7070 on the target
No authentication gate or VPN required

Where this breaks in practice:

Firewall or network-level ACLs blocking 7070 inbound stop this step entirely
AnyDesk relay-only configurations never expose this port

Detection/coverage: Network IDS can flag raw TCP connections to 7070 that do not follow normal AnyDesk handshake patterns. Anomalous connection volume to a single AnyDesk instance is a signal.

STEP 03

Heap spray — groom memory layout for overflow

The attacker opens ten additional client connections to place candidate victim objects adjacent to the soon-to-be-overflowed buffer. Then twenty 0xF000-byte ROP chain objects are sprayed, each containing gadget sleds pointing to AnyDesk's system() PLT entry. This dual-spray strategy aims to create the exact adjacency pattern the overflow requires. The published AnyPwn PoC automates this with a Python script using the rich library for status output.

Conditions required:

Heap layout must align — attacker-controlled object must land adjacent to target dispatch structure
Offsets must match the exact AnyDesk build (PoC targets SHA-256 62ee04ad... of 8.0.2)

Where this breaks in practice:

Heap layout is probabilistic — misalignment crashes AnyDesk instead of exploiting it, revealing the attempt
Different AnyDesk builds, kernel versions, or allocator configurations change offsets — porting requires reverse engineering per build
ASLR and other kernel hardening affect gadget reliability

Detection/coverage: AnyDesk crash logs and systemd journal entries showing repeated service restarts are a strong indicator of exploitation attempts.

STEP 04

Trigger overflow — send crafted mode-5 packet

The attacker sends a stream packet declaring payload length 0xFFFFFFF0. Adding the 16-byte object header wraps the 32-bit allocation size to near-zero. The allocator returns a tiny buffer, but subsequent writes use the original declared length, overflowing into adjacent heap objects. The overflow overwrites the victim object's dispatch function pointer with a gadget pointing to system().

Conditions required:

Successful heap grooming from step 3
The integer truncation behavior is present (fixed in 8.0.3)

Where this breaks in practice:

Single-attempt exploitation — failure crashes the service, alerting monitoring and requiring service restart before retry
AnyDesk 8.0.3 adds proper length validation, making the wrap impossible

Detection/coverage: Process crash monitoring via systemd watchdog or endpoint detection agent. Heap corruption often leaves core dumps for forensic analysis.

STEP 05

Code execution — arbitrary command as root

When the corrupted dispatch pointer is invoked, execution jumps through the ROP chain into system() with an attacker-controlled command string. Because AnyDesk's systemd unit runs as User=root, the command executes with full root privileges. The attacker can drop a reverse shell, install persistence, or exfiltrate data — all before the victim user sees or approves any desktop-sharing request.

Conditions required:

Steps 1–4 succeed
AnyDesk is running in service mode as root (the default systemd configuration)

Where this breaks in practice:

EDR agents on the host may detect anomalous child processes spawned from the AnyDesk binary
SELinux or AppArmor profiles (if enforced) may confine the AnyDesk process and block shell execution

Detection/coverage: EDR/XDR detection of unexpected child processes from anydesk binary. Process tree analysis showing anydesk → sh → <payload> is a high-fidelity alert.

03 · Compensating Control

HIGH 8.0→LOW 3.0

SEVERITY REDUCED

Block inbound TCP/7070 at the network perimeter immediately — The confirmed exploit path requires a direct TCP connection to port 7070. Blocking this port at firewalls, security groups, and host-based firewalls eliminates the known attack vector entirely. Deploy within 3 days per the noisgate mitigation SLA for HIGH. This does not affect AnyDesk relay-based connections, which route through AnyDesk's cloud infrastructure on different ports.

HIGH 8.0→IGNORE 0.0

SEVERITY REDUCED

Upgrade AnyDesk Linux to 8.0.3 or later — Version 8.0.3 adds proper payload length validation, completely eliminating the integer wrap and heap overflow. Current release is 8.1.0. Deploy within 30 days (noisgate mitigation SLA for HIGH) if port blocking is already in place; if port blocking is *not* feasible, treat this as the primary mitigation and deploy within 3 days. Verify via anydesk --version on each Linux host.

HIGH 8.0→LOW 2.5

SEVERITY REDUCED

Restrict AnyDesk to relay-only mode (disable direct connections) — AnyDesk can be configured to disallow direct TCP connections and force all traffic through the relay infrastructure. Since relay-based full RCE is unconfirmed, this eliminates the proven attack path. Configure via AnyDesk settings or deploy via custom client with direct connections disabled. Deploy within 30 days.

HIGH 8.0→MEDIUM 5.5

SEVERITY REDUCED

Deploy or verify EDR coverage on AnyDesk Linux hosts — EDR agents detect anomalous child processes spawned from the AnyDesk binary (e.g., anydesk → sh → reverse_shell). Even if exploitation succeeds, post-exploitation activity is highly detectable. Verify agents are installed, running, and reporting on all Linux hosts with AnyDesk. This is a defense-in-depth measure, not a standalone mitigation.

HIGH 8.0→MEDIUM 5.0

SEVERITY REDUCED

Enable SELinux or AppArmor enforcement on AnyDesk hosts — Mandatory access control policies can confine the AnyDesk process, preventing it from spawning arbitrary child processes or accessing files outside its expected scope — even when running as root. This degrades the exploit's post-exploitation utility significantly. Existing profiles may need customization for AnyDesk's legitimate operations.

What doesn't work

Requiring user approval for connections — the exploit fires in the session protocol *before* the user approval step; the victim never sees a prompt.
Changing AnyDesk passwords or access tokens — the vulnerability is pre-authentication; credentials are irrelevant to the attack path.
Network-level rate limiting on port 7070 — the exploit requires only a single TCP connection; rate limiting does not prevent a single well-crafted attempt.
Upgrading to Windows or macOS AnyDesk — while these platforms are not vulnerable to this specific CVE, replacing the OS to dodge a bug is not a realistic compensating control.

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	No confirmed exploitation in the wild as of 2026-10-14. Not listed in CISA KEV. No GreyNoise tags observed for CVE-2026-109390 scanning activity. EPSS of 0.0161 (~98.4th percentile) suggests low near-term exploitation probability despite public PoC availability.
Proof-of-Concept	Public, weaponized PoC available. AnyPwn by Rick de Jager (V12 Security), published October 8, 2026 on GitHub. Python 3 script (`anypwn.py`) with `rich` dependency. Targets exact AnyDesk Linux 8.0.2 build (SHA-256 `62ee04ad48dc039dd9c927f998e56143c87a9c5e12d28654f78c7f6340394f5a`). Probabilistic — heap grooming required, failure crashes service.
EPSS	0.0161 (1.61% probability of exploitation in next 30 days). Relatively low despite public PoC, likely reflecting Linux-only scope and direct-TCP requirement.
KEV Status	Not listed in CISA Known Exploited Vulnerabilities catalog as of 2026-10-14.
CVSS Vector	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8). Network-reachable, low complexity, no privileges, no interaction, full confidentiality/integrity/availability impact. The vector does not account for the platform limitation (Linux-only) or the direct-TCP requirement.
Affected Versions	AnyDesk for Linux versions ≥ 8.0.0 and < 8.0.3 (i.e., 8.0.0, 8.0.1, 8.0.2). Windows and macOS are not affected. The `anydesk --service` systemd unit runs as root by default.
Fixed Versions	AnyDesk 8.0.3 (released June 23, 2026). Current release is 8.1.0. AnyDesk's changelog described the fix only as 'fixed a bug that could lead to a crash' — no CVE assigned, no security advisory issued by AnyDesk at the time. Distro-packaged versions should be verified individually.
Internet Exposure	Censys reports ~230,000 AnyDesk assets globally with direct TCP exposure, but this figure spans all platforms and versions. The subset running Linux 8.0.0–8.0.2 with direct TCP/7070 exposure is significantly smaller. AnyDesk holds ~4.86% of the remote access market (Enlyft).
Disclosure Timeline	June 22, 2026: Initial vulnerability announcement. June 23, 2026: AnyDesk acknowledged and shipped 8.0.3. October 8, 2026: AnyPwn PoC published on GitHub. October 12, 2026: CVE-2026-109390 formally assigned.
Researcher / Org	Rick de Jager, V12 Security (v12-security/pocs). Relay code-path reachability confirmed via Frida-based testing, though full relay RCE chain was not demonstrated.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to HIGH (8.0/10)

Why this verdict

Linux-only scope eliminates the majority of the install base. AnyDesk's user base is overwhelmingly Windows. Linux deployments represent a single-digit percentage of AnyDesk installations. The CVSS vector treats every AnyDesk instance as reachable — in practice, ~85–90% of the install base (Windows + macOS) is simply not vulnerable. This is the largest single friction factor.
Direct TCP/7070 exposure is atypical in enterprise. The confirmed exploit path requires a raw TCP connection to port 7070 on the target. Most managed AnyDesk deployments route through AnyDesk's relay infrastructure, not direct inbound TCP. Organizations that firewall inbound 7070 (the default enterprise posture) are not reachable. Relay-based exploitation reached the vulnerable code path in lab testing but did *not* achieve full RCE — this remains unconfirmed and should be monitored.
Exploit is probabilistic and build-specific. The AnyPwn PoC targets one exact build of AnyDesk 8.0.2 with hardcoded heap offsets. Different builds, kernel versions, or glibc allocator behavior change the layout. Failed attempts crash the service rather than granting a shell, creating a noisy, single-shot failure mode that alerts defenders and requires service restart before retry.
Patch has been available for nearly four months. AnyDesk 8.0.3 shipped June 23, 2026. Organizations with any cadence of updates should already be patched. The current release is 8.1.0. The vulnerable window (8.0.0–8.0.2) is narrow and aging.
Role multiplier: AnyDesk is a remote access tool, not a canonically high-value component (it is not an identity provider, hypervisor, backup system, or CI/CD tool). (a) *Low-value role*: developer/personal workstations — compromise is host-scoped. (b) *Typical role*: IT support endpoint — compromise yields one host with root. (c) *High-value role*: AnyDesk on a production Linux database or application server — compromise yields root on a critical server, blast radius is host-level extending to whatever data/services that host controls. However, AnyDesk is not canonically deployed in high-value roles (it is an IT support tool, not infrastructure-defining software). The fraction of AnyDesk Linux installs on high-value servers with direct TCP/7070 is small. The floor for HIGH is met (public pre-auth root RCE PoC on a product with measurable internet exposure) but the CRITICAL floor is not (AnyDesk is not a canonically high-value component where ≥10% of installs define the high-value role).
Public PoC prevents further downgrade. Despite all friction, a working pre-auth root RCE exploit is publicly available on GitHub. This materially lowers the attacker skill threshold. Combined with 230K globally exposed AnyDesk assets (even if the vulnerable Linux subset is small), opportunistic exploitation is plausible. This anchors the verdict at HIGH and prevents a MEDIUM assessment.

Why not higher?

The CRITICAL floor requires either (a) a canonically high-value component where ≥10% of installs occupy the high-value role, or (b) a chain that reliably produces domain/fleet/supply-chain-scale impact. AnyDesk is an IT support tool, not infrastructure-defining software. The exploit is probabilistic, build-specific, and constrained to direct TCP/7070 on Linux only — three compounding narrowing factors that the CVSS 9.8 does not reflect. Relay-based exploitation, which would dramatically expand the attack surface, remains unconfirmed for the full RCE chain.

Why not lower?

A public, weaponized pre-auth root RCE exploit exists. The vulnerability requires zero credentials, zero user interaction, and executes as root. Censys shows substantial AnyDesk internet exposure, and even a small Linux/direct-TCP subset represents thousands of potentially reachable hosts. The patch gap between June 23 and the PoC release on October 8 means some organizations may still be running vulnerable versions. Dropping below HIGH would understate the risk to any organization that does have exposed AnyDesk Linux instances.

06 · Verification

Crowdsourced verification payload.

Run this script on each Linux host where AnyDesk may be installed, as any user with read access to the AnyDesk binary. No root required. Invoke with: bash check_cve_2026_109390.sh. The script checks both the installed AnyDesk version and TCP/7070 exposure.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_cve_2026_109390.sh — AnyDesk Linux heap overflow (CVE-2026-109390)
# Checks: (1) AnyDesk is installed, (2) version is in vulnerable range, (3) TCP/7070 is listening
# Exit codes: 0 = PATCHED/NOT_AFFECTED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

VULN_CVE="CVE-2026-109390"
FIXED_VERSION="8.0.3"

# Locate AnyDesk binary
ANYDESK_BIN=$(command -v anydesk 2>/dev/null || true)
if [[ -z "$ANYDESK_BIN" ]]; then
    # Check common install paths
    for p in /usr/bin/anydesk /usr/local/bin/anydesk /opt/anydesk/anydesk; do
        if [[ -x "$p" ]]; then
            ANYDESK_BIN="$p"
            break
        fi
    done
fi

if [[ -z "$ANYDESK_BIN" ]]; then
    echo "NOT_AFFECTED — AnyDesk is not installed on this host."
    exit 0
fi

# Check platform
if [[ "$(uname -s)" != "Linux" ]]; then
    echo "NOT_AFFECTED — $VULN_CVE only affects AnyDesk for Linux. Detected OS: $(uname -s)"
    exit 0
fi

# Get version
VERSION_OUTPUT=$($ANYDESK_BIN --version 2>/dev/null || true)
if [[ -z "$VERSION_OUTPUT" ]]; then
    echo "UNKNOWN — Could not determine AnyDesk version. Binary: $ANYDESK_BIN"
    exit 2
fi

# Extract version number (e.g., "8.0.2")
VERSION=$(echo "$VERSION_OUTPUT" | grep -oP '[0-9]+\.[0-9]+\.[0-9]+' | head -1)
if [[ -z "$VERSION" ]]; then
    echo "UNKNOWN — Could not parse version from output: $VERSION_OUTPUT"
    exit 2
fi

echo "Detected AnyDesk version: $VERSION"

# Version comparison function
version_gte() {
    printf '%s\n%s' "$1" "$2" | sort -V | head -1 | grep -qx "$2"
}

version_lt() {
    ! version_gte "$1" "$2"
}

# Check if version is in vulnerable range: >= 8.0.0 and < 8.0.3
if version_gte "$VERSION" "8.0.0" && version_lt "$VERSION" "$FIXED_VERSION"; then
    # Check if TCP/7070 is listening
    PORT_LISTENING="unknown"
    if command -v ss &>/dev/null; then
        if ss -tlnp 2>/dev/null | grep -q ':7070'; then
            PORT_LISTENING="yes"
        else
            PORT_LISTENING="no"
        fi
    elif command -v netstat &>/dev/null; then
        if netstat -tlnp 2>/dev/null | grep -q ':7070'; then
            PORT_LISTENING="yes"
        else
            PORT_LISTENING="no"
        fi
    fi

    echo "VULNERABLE — AnyDesk $VERSION is in the affected range (8.0.0–8.0.2). $VULN_CVE applies."
    echo "  Fixed version: >= $FIXED_VERSION"
    echo "  TCP/7070 listening: $PORT_LISTENING"
    if [[ "$PORT_LISTENING" == "yes" ]]; then
        echo "  WARNING: Port 7070 is actively listening — this host is directly exploitable."
    elif [[ "$PORT_LISTENING" == "no" ]]; then
        echo "  NOTE: Port 7070 is not listening, reducing direct exploitation risk."
    fi
    exit 1
else
    echo "PATCHED — AnyDesk $VERSION is not in the vulnerable range (8.0.0–8.0.2)."
    exit 0
fi