AnyDesk steht wegen mehrerer ungepatchter Schwachstellen unter Beobachtung: Ein Angreifer kann die Fehler ausnutzen, um einen Denial-of-Service-Zustand auszulösen. Betroffen sind AnyDesk-Installationen im verwundbaren Stand, für die noch keine korrigierende Aktualisierung als primäre Abhilfe bereitsteht. Die Risikoeinstufung liegt im mittleren Bereich, der praktische Effekt kann in Betriebsumgebungen dennoch spürbar sein: Fällt der Remote-Access-Dienst aus oder reagiert nicht mehr zuverlässig, verlieren Helpdesk, Administratoren und externe Dienstleister im Zweifel den schnellen Zugriff auf Systeme. Besonders kritisch ist das dort, wo AnyDesk für Störungsbehebung, Bereitschaft oder Zugriff auf dezentrale Standorte eingeplant ist.
Warum ein DoS bei Fernwartung mehr ist als ein Schönheitsfehler
Denial of Service klingt zunächst nach einem Verfügbarkeitsproblem ohne direkten Datenabfluss. Bei Remote-Access-Software ist diese Einordnung zu kurz gegriffen. AnyDesk wird häufig genau dann benötigt, wenn Systeme nicht vor Ort administriert werden können: Außenstellen, Homeoffice-Clients, Kiosksysteme, Produktionsumgebungen oder Server ohne komfortablen zweiten Administrationsweg. Wenn ein Angreifer den Dienst gezielt in einen nicht mehr nutzbaren Zustand bringen kann, entsteht schnell ein operatives Problem.
Die Schwachstellen betreffen nicht die Vertraulichkeit oder Integrität als primäres Ziel, sondern die Verfügbarkeit des Produkts. Der Angriffspfad läuft auf eine Störung der Anwendung oder ihrer erreichbaren Komponenten hinaus. Für Administratoren ist deshalb weniger die klassische Frage nach Datenexfiltration entscheidend, sondern die Frage: Welche Systeme sind im Fehlerfall nicht mehr fernwartbar, und welche Prozesse hängen an genau diesem Zugriff?
Die mittlere Einstufung passt zu einem Szenario, in dem ein Angreifer keinen vollständigen Systemkompromiss erreicht, aber einen Dienst aus dem Tritt bringen kann. In der Praxis kann ein gezielter Ausfall trotzdem eskalieren, wenn er mit anderen Störungen zusammenfällt. Ein Beispiel: Ein Client ist nur über AnyDesk erreichbar, ein lokaler Nutzer kann nicht unterstützen, und gleichzeitig muss eine sicherheitsrelevante Änderung ausgerollt werden. Dann wird aus einem DoS-Fehler ein echtes Betriebsrisiko.
Welche Angriffsfläche Admins prüfen sollten
Der wichtigste Punkt ist die Erreichbarkeit. Ein Denial-of-Service-Angriff setzt voraus, dass ein Angreifer die verwundbare AnyDesk-Instanz oder die relevante Kommunikationsfläche überhaupt ansprechen kann. Systeme, auf denen AnyDesk dauerhaft aktiv ist, verdienen daher eine andere Behandlung als Clients, auf denen das Tool nur bei Bedarf gestartet wird. Je stärker AnyDesk in Standard-Images, Jump-Hosts oder Support-Prozesse integriert ist, desto größer wird die betriebliche Angriffsfläche.
Admins sollten ihre Inventarisierung nicht auf Server beschränken. AnyDesk läuft typischerweise auch auf Arbeitsplatzsystemen, Notebooks oder Spezialgeräten, die in klassischen Patch- und Monitoring-Prozessen schlechter sichtbar sind. Genau dort fallen Verfügbarkeitsprobleme oft spät auf: Der Dienst startet nicht mehr, Sitzungen brechen ab, oder Support-Mitarbeiter verlieren reproduzierbar die Verbindung. Solche Symptome gehören derzeit nicht als einzelnes Client-Problem abgetan, sondern sollten zentral gesammelt und korreliert werden.
Da die Schwachstellen als ungepatcht gemeldet sind, liegt der Schwerpunkt vorerst auf Begrenzung und Kontrolle statt auf einem einfachen Update-Haken. Das heißt: AnyDesk sollte nur dort laufen, wo ein geschäftlicher Zweck besteht. Dauerhaft aktive Installationen auf Systemen ohne aktuellen Support-Bedarf erhöhen die Angriffsfläche unnötig. Ebenso sollten Berechtigungen, Autostart-Konfigurationen und Zugriffspfade überprüft werden. Eine Fernwartungssoftware ist Infrastruktur – und sollte entsprechend restriktiv betrieben werden.
Mitigation bis zum Hersteller-Fix
Ohne verfügbaren Patch müssen Security-Teams temporäre Schutzmaßnahmen sauber dokumentieren und nachverfolgen. Das Ziel ist nicht, AnyDesk pauschal abzuschalten, sondern die Folgen eines möglichen DoS zu begrenzen. Dazu gehört ein klares Bild, welche Abteilungen, Standorte und Systeme von AnyDesk abhängig sind. Für kritische Systeme sollte ein alternativer Administrationsweg existieren, etwa ein vorhandener Management-Zugang oder ein definierter Vor-Ort-Prozess.
Auch Monitoring spielt eine Rolle. Ein DoS gegen Fernwartung fällt nicht immer sofort im klassischen Server-Monitoring auf, wenn der betroffene Host selbst weiterläuft. Sinnvoll sind daher Prüfungen auf Dienststatus, wiederholte Prozessabbrüche, ungewöhnlich viele Verbindungsabbrüche und Support-Tickets mit identischem Muster. Wer zentral Logs oder Endpoint-Telemetrie auswertet, sollte AnyDesk-bezogene Abstürze und Neustarts vorübergehend höher priorisieren.
Für den Betrieb empfiehlt sich jetzt ein kontrollierter Zwischenstand: Inventar aktualisieren, Exposition reduzieren, Support-Prozesse absichern und ein Wartungsfenster vorbereiten, sobald ein korrigierter Herstellerstand verfügbar ist. Gerade weil es sich um mehrere Schwachstellen handelt, sollten Admins nicht nur auf ein einzelnes Symptom achten, sondern die Verfügbarkeit der gesamten AnyDesk-Nutzung im Blick behalten.
- AnyDesk-Installationen inventarisieren und unnötige Daueraktivierung deaktivieren.
- Zugriff auf AnyDesk nur für benötigte Systeme und Support-Szenarien zulassen.
- Monitoring auf Dienstabbrüche, Verbindungsfehler und wiederholte Neustarts schärfen.
- Wartungsfenster für ein Hersteller-Update vorbereiten, sobald ein Fix bereitsteht.