AnyPwn: Wenn ein stiller Patch zur offenen Tür für die Fernwartung wird

Fernwartungssoftware ist praktisch und deshalb überall: auf Servern, an Arbeitsplätzen, auf Steuerungsrechnern und auf Linux-Systemen, die ein Hersteller für den Support eingerichtet hat. Genau das macht eine Lücke wie „AnyPwn“ so unangenehm. Für AnyDesk unter Linux ist seit dem 8. Oktober 2026 ein funktionierender Exploit öffentlich, mit dem Angreifer ohne Anmeldung und ohne Zustimmung des Anwenders Code mit Root-Rechten ausführen können.

Die Lücke selbst ist seit Juni behoben. Das eigentliche Problem ist, dass das kaum jemand wusste: Der Hersteller hat die Korrektur als Absturzbehebung ausgeliefert, ohne CVE und ohne Sicherheitshinweis. Wer seine Updates nach Sicherheitsmeldungen priorisiert, hatte keinen Anlass, gerade diese Version einzuspielen.

Was passiert ist

Warum die Lücke so schwer wiegt

Der AnyDesk-Dienst läuft unter Linux mit Root-Rechten und nimmt Direktverbindungen standardmäßig auf TCP-Port 7070 an. Der Fehler sitzt in der Verarbeitung eines Datenpakets, noch bevor der Anwender eine Sitzung bestätigt. Ein Angreifer braucht also weder Zugangsdaten noch einen Klick des Gegenübers. Gelingt der Angriff, gehört ihm das System vollständig – ohne Umweg über eine zusätzliche Rechteausweitung.

Wer Port 7070 nicht nach außen öffnet, ist nicht automatisch sicher. Nach der Analyse des chinesischen CERT von Qianxin ist der verwundbare Codepfad auch über das AnyDesk-Relaisnetz erreichbar. Eine Firewallregel verkleinert die Angriffsfläche, ersetzt das Update aber nicht.

Das eigentliche Problem: der stille Patch

Dass ein Hersteller eine Lücke binnen eines Tages schließt, ist vorbildlich. Dass er sie danach monatelang nicht als Sicherheitsproblem benennt, ist es nicht. In vielen Umgebungen werden Updates für Anwendungssoftware nach Dringlichkeit eingeplant: Sicherheitshinweise und CVEs zuerst, Komfort- und Fehlerbehebungen bei Gelegenheit. Ein „behobener Absturz“ landet in der zweiten Kategorie.

Mit der Veröffentlichung des Exploits hat sich die Lage umgedreht: Angreifer kennen die Lücke im Detail, viele Betreiber haben noch nicht einmal davon gehört. Wie schnell öffentliche Exploits heute in Angriffe übersetzt werden, haben wir im Beitrag zur negativen Time-to-Exploit beschrieben.

Die blinden Flecken: Fernwartung, die niemand verwaltet

Auf Windows-Arbeitsplätzen ist AnyDesk meist bekannt und erfasst. Die Linux-Installationen sind oft das Problem: Systeme, die ein Hersteller für seinen Support eingerichtet hat, Steuerungs- und Visualisierungsrechner in der Haus- oder Gebäudetechnik, Kassen- und Kiosksysteme oder ein Testserver, auf dem ein Dienstleister „mal eben“ einen Zugang gebraucht hat. Solche Installationen tauchen in keiner Softwareverteilung auf und werden entsprechend nie aktualisiert.

Wie riskant vom Hersteller eingerichtete Zugänge sein können, zeigt unser Beitrag „Fahrlässig ab Werk“. Dass Fernwartungszugänge für Angreifer besonders attraktiv sind, haben wir zuletzt am Beispiel BeyondTrust beschrieben.

Was jetzt zu tun ist

1. Bestand aufnehmen: Alle Linux-Systeme mit AnyDesk ermitteln – auch solche, die Hersteller, Dienstleister oder einzelne Abteilungen installiert haben. Ein Portscan auf TCP 7070 im internen Netz hilft, vergessene Installationen zu finden.
2. Aktualisieren: Mindestens auf 8.0.3, besser direkt auf die aktuelle Version. Wird AnyDesk auf einem System nicht mehr gebraucht, ist Deinstallieren die bessere Lösung.
3. Erreichbarkeit einschränken: TCP 7070 nicht aus dem Internet erreichbar machen und intern nur aus den Netzen zulassen, aus denen tatsächlich gewartet wird. Das ersetzt das Update nicht, weil die Lücke auch über das Relaisnetz erreichbar sein soll.
4. Auf Spuren prüfen: Auf Systemen, die mit einer verwundbaren Version am Netz waren, nach unerwarteten Prozessen, neuen Benutzerkonten, Cronjobs, SSH-Schlüsseln und Diensten suchen, die unter root gestartet wurden.
5. Dienstleister einbeziehen: Bei Systemen, die ein Hersteller betreut, aktiv nachfragen, ob und wann aktualisiert wurde. Eine Antwort wie „Das machen wir beim nächsten Termin“ reicht bei einer Lücke mit öffentlichem Exploit nicht.
6. Regel für die Zukunft: Fernwartungssoftware gehört in die zentrale Inventarisierung und in einen festen Update-Rhythmus – unabhängig davon, ob ein Update als sicherheitsrelevant ausgewiesen ist.

anydesk --version

# Debian, Ubuntu
dpkg -l | grep -i anydesk

# RHEL, Rocky, Fedora, openSUSE
rpm -qa | grep -i anydesk

systemctl status anydesk --no-pager

ss -tlnp | grep 7070

# Beispiel mit nmap, Netzbereich anpassen
nmap -p 7070 --open 192.168.10.0/24

Einordnung

• Schnell gepatcht heißt nicht gut kommuniziert. Der Fix lag nach einem Tag vor. Ohne ehrliche Kennzeichnung als Sicherheitsupdate nützt das aber nur denen, die zufällig ohnehin aktualisieren.
• Root-Dienste mit Netzwerkzugang sind Hochrisikosoftware. Ein einzelner Speicherfehler genügt für die vollständige Übernahme. Solche Dienste gehören auf die kürzeste Update-Liste.
• Unbekannte Installationen sind die größte Gefahr. Ein System, von dem niemand weiß, dass AnyDesk darauf läuft, wird auch nach diesem Beitrag nicht aktualisiert. Inventarisierung ist hier die eigentliche Schutzmaßnahme.

Quellen & weiterführende Links

• Cloud Security Alliance

  AnyPwn: AnyDesk Linux Fix Described as a Crash Gains Public Exploit (11.10.2026)
• OpenCVE

  CVE-2026-109390
• AnyDesk

  Changelog AnyDesk für Linux
• Qianxin CERT (via secrss.com)

  Analyse zu CVE-2026-109390 (chinesisch)

Recherchestand: 20. Oktober 2026. Eine aktive Ausnutzung war zu diesem Zeitpunkt nicht bestätigt, die Lücke stand nicht im KEV-Katalog der CISA.