Diese Ausgabe fasst die Entwicklungen des Wochenendes und des heutigen Tages zusammen. Am schwersten wiegt die aktiv ausgenutzte SQL-Injection-Lücke in Arista VeloCloud Orchestrator, gefolgt von Web Shells über Collabora Online in Nextcloud. Außerdem kapert der Akteur k0t Firewalls und VPN-Gateways von Fortinet und Palo Alto, GitLab behebt eine Lücke mit CVSS 10,0, und eine Forscherin demonstriert eine Root-Eskalation in Tailscale SSH, für die es noch keinen Patch gibt.
- Arista VeloCloud Orchestrator aktiv ausgenutzt: SQL-Injection mit CVSS 9,9 in der SD-WAN-Verwaltungsumgebung
- Collabora Online in Nextcloud wird für Web Shells missbraucht: kritische Lücke im integrierten CODE-Server
- Angreifer k0t kapert Firewalls und VPN-Gateways: über 70.000 Zugangsdaten von FortiGate und GlobalProtect offengelegt
- GitLab behebt kritische Lücke mit CVSS 10,0: Unbekannte Angreifer können ohne Anmeldung Code auf Self-Managed-Servern ausführen
- Tailworm: Forscherin demonstriert Root-Eskalation über Tailscale SSH, noch kein Patch und keine CVE
Arista VeloCloud Orchestrator aktiv ausgenutzt: SQL-Injection mit CVSS 9,9 in der SD-WAN-Verwaltungsumgebung
| Schwachstelle | SQL-Injection im On-Premise-Arista VeloCloud Orchestrator (VCO), der Verwaltungsumgebung von VeloCloud SD-WAN. Ein Angreifer erhält Zugriff auf privilegierte interne Funktionen. Betroffen sind On-Premise-Versionen von VCO vor den gepatchten Releases |
| CVE-Nummer | CVE-2026-114625 |
| CVSS-Score | 9,9 |
| Aktiv ausgenutzt | Ja, Arista meldet aktive Ausnutzung, und die CISA hat die Schwachstelle am 23. Oktober 2026 in den KEV-Katalog aufgenommen |
| Patch verfügbar | Ja, im Oktober 2026: Versionen 5.2.3.18, 6.1.3.10 und 6.4.2.12 |
Wie kann die Schwachstelle ausgenutzt werden?
Laut The Hacker News benötigt ein Angreifer Netzwerkzugriff auf die Weboberfläche von VCO sowie eine gültige angemeldete Sitzung. Die niedrigste Rolle, die dafür ausreicht, ist Enterprise Read Only. Schon eine eingeschränkte Rolle genügt also, um an privilegierte Funktionen zu gelangen. Arista teilt keine technischen Details mit und nennt keinen Täter. Veröffentlicht wurden jedoch zwei IP-Adressen, von denen die Aktivität ausgeht, beide in Japan geolokalisiert: 74.82.197.86 und 38.54.50.151.
Welche Folgen kann das haben?
Ein Orchestrator steuert die SD-WAN-Konfiguration sämtlicher angebundener Kundenstandorte. Mit der Kontrolle über den Orchestrator kann ein Angreifer Routing und Richtlinien ändern. Zudem ist es bereits die dritte VCO-Schwachstelle, die seit Juli 2026 in freier Wildbahn ausgenutzt wird, nach zwei früheren Lücken mit CVSS 10,0. Siehe auch die Meldung der CISA.
Was sollten IT-Administratoren jetzt tun?
Aktualisieren Sie On-Premise-VCO auf 5.2.3.18, 6.1.3.10 oder 6.4.2.12. Machen Sie die Weboberfläche nicht aus dem Internet erreichbar und beschränken Sie den Zugriff auf Verwaltungsnetze. Durchsuchen Sie die Logs nach Datenverkehr von den beiden genannten IP-Adressen und prüfen Sie Konten mit der Rolle Enterprise Read Only auf unerwartete Nutzung.
Collabora Online in Nextcloud wird für Web Shells missbraucht: kritische Lücke im integrierten CODE-Server
| Schwachstelle | OS-Command-Injection im integrierten CODE-Server (richdocumentscode) von Collabora Online, der innerhalb von Nextcloud genutzt wird. Codeausführung über proxy.php, allerdings nur, wenn der lokale CODE-Dokumentenserver nicht läuft |
| CVE-Nummer | CVE-2026-110447 |
| CVSS-Score | 9,2 |
| Aktiv ausgenutzt | Ja, die CISA hat die Lücke am 23. Oktober 2026 in den KEV-Katalog aufgenommen |
| Patch verfügbar | Ja, Version 26.4.303 vom September 2026 |
Wie wurde die Lücke ausgenutzt?
The Hacker News berichtet, dass Angreifer die Lücke nutzen, um Web Shells auf Nextcloud-Servern zu platzieren. Anschließend suchen sie nach gespeicherten Zugangsdaten, Spuren von Passwortmanagern und Krypto-Wallets.
Welche Folgen kann das haben?
Eine Web Shell verschafft dem Angreifer dauerhaften Zugriff auf den Server, auf dem Nextcloud läuft. Für MSPs, die gehostete Nextcloud-Umgebungen für Kunden betreiben, bedeutet das Zugriff auf Dateien und möglicherweise auf weitere Systeme im selben Netzwerk.
Was sollten IT-Administratoren jetzt tun?
Aktualisieren Sie die Collabora-App (richdocumentscode) auf 26.4.303 oder neuer, auch in Umgebungen, die seit Monaten nicht angefasst wurden. Prüfen Sie das Webroot auf unbekannte Dateien, insbesondere im Umfeld von proxy.php, und durchsuchen Sie die Logs nach verdächtigen Anfragen. Finden Sie eine Web Shell, sollten Sie von einer vollständigen Kompromittierung des Servers ausgehen und gespeicherte Zugangsdaten rotieren.
Angreifer k0t kapert Firewalls und VPN-Gateways: über 70.000 Zugangsdaten von FortiGate und GlobalProtect offengelegt
| Schwachstelle | Kampagne gegen aus dem Internet erreichbare Netzwerkgeräte, vor allem Fortinet FortiGate und Palo Alto Networks GlobalProtect. Der Angreifer nutzt bekannte Schwachstellen in FortiWeb und PAN-OS/Prisma Access sowie zusätzlich Brute Force mit gängigen Passwörtern |
| CVE-Nummer | CVE-2025-64446 (FortiWeb, Path Traversal) und CVE-2026-0257 (PAN-OS und Prisma Access, Umgehung der Authentifizierung) |
| Aktiv ausgenutzt | Ja, laut Group-IB und NyxLab; die meisten Einbrüche fanden zwischen Februar und Juni 2026 statt |
| Patch verfügbar | Ja für die genannten CVEs: Installieren Sie die aktuelle Firmware des Herstellers. Gegen Brute Force helfen ein starkes Passwort und MFA |
Wie wurde die Lücke ausgenutzt?
Forscher von Group-IB und NyxLab beschreiben in einer gemeinsamen Untersuchung, wie der Akteur „k0t“ Geräte über Scan-Tools wie FOFA und ZoomEye aufspürte, über die genannten Lücken oder schwache Passwörter eindrang und anschließend eine OpenConnect-VPN-Verbindung aufbaute. Im Netzwerk folgten die Auskundschaftung des Active Directory und der Diebstahl weiterer Zugangsdaten, unter anderem mit Mimikatz und Impacket. Für die Persistenz nutzte der Angreifer legitime Verwaltungstools wie MeshCentral, Atera und AnyDesk, und Daten wurden per Rclone zu Wasabi und MEGA abgezogen.
Welche Folgen kann das haben?
Mehr als 70.000 Zugangsdaten von Netzwerkgeräten sowie LDAP-Dumps wurden offengelegt. Laut der Untersuchung steht k0t wahrscheinlich den Ransomware-Gruppen Qilin und The Gentlemen nahe, als Initial Access Broker oder Affiliate. Rund 15,8 Prozent der Opfer sitzen in Europa. Da es sich um bekannte RMM-Tools handelt, fällt die Persistenz in den Logs kaum auf.
Was sollten IT-Administratoren jetzt tun?
Patchen Sie FortiWeb, PAN-OS und Prisma Access, nehmen Sie Verwaltungsoberflächen vom Internet und erzwingen Sie MFA für VPN. Rotieren Sie Passwörter, die über LDAP oder die Firewall verwendet wurden. Erfassen Sie außerdem, welche Remote-Access-Tools (MeshCentral, Atera, AnyDesk) in Kundenumgebungen vorhanden sein sollten, und untersuchen Sie alles, was darüber hinausgeht.
GitLab behebt kritische Lücke mit CVSS 10,0: Unbekannte Angreifer können ohne Anmeldung Code auf Self-Managed-Servern ausführen
| Schwachstelle | Integer Overflow in der Regex-Engine Onigmo, die GitLab mitliefert. Ein speziell konstruierter regulärer Ausdruck kann ohne Authentifizierung zur Codeausführung auf Self-Managed-GitLab führen, von Version 7.0 bis zu den gepatchten Releases |
| CVE-Nummer | CVE-2026-110264 |
| CVSS-Score | 10,0 |
| Aktiv ausgenutzt | Nein, GitLab beobachtet keine Ausnutzung, und die Lücke stand am 22. Oktober 2026 nicht im KEV-Katalog |
| Patch verfügbar | Ja, unter anderem 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 und 18.11.13 |
Wie kann die Schwachstelle ausgenutzt werden?
Laut The Hacker News hat GitLab die Voraussetzungen für eine Ausnutzung nicht veröffentlicht. Gemeldet wurde die Lücke von einem Forscher mit dem Namen „joaxcar“, demselben, der innerhalb eines Monats vier Lücken in der Regex-Engine gefunden hat. GitLab.com läuft bereits mit einer gepatchten Version, das Risiko liegt also bei selbst verwalteten Installationen.
Welche Folgen kann das haben?
Ein GitLab-Server enthält häufig Quellcode, CI/CD-Secrets und Zugangsschlüssel von Kunden. Codeausführung ohne Anmeldung kann damit zum Sprungbrett auf andere Systeme werden. Achtung: Umgebungen, die am 12. Oktober gepatcht wurden (19.2 und höher), sind erneut verwundbar, bis sie auf die neuen Versionen aktualisiert sind.
Was sollten IT-Administratoren jetzt tun?
Führen Sie ein Upgrade auf die gepatchte Version Ihrer Release-Reihe durch. GitLab bietet keinen Workaround, Aktualisieren ist also die einzige sichere Maßnahme. Rechnen Sie bei Single-Node-Servern mit Downtime, da 19.4.3 und 19.3.6 Datenbankänderungen enthalten. GitLab hat zwei Sigma-Erkennungsregeln („Onigmo native worker crash“ und „Org mode render error burst“) veröffentlicht, mit denen sich Logs nach Ausnutzungsversuchen durchsuchen lassen.
Tailworm: Forscherin demonstriert Root-Eskalation über Tailscale SSH, noch kein Patch und keine CVE
| Schwachstelle | Reihe von 11 Befunden in Tailscale und headscale, darunter eine Eskalation zu Root über Tailscale SSH mit Port Forwarding. Getestet mit Tailscale 1.104.2 und headscale 0.29.5 in einer Laborumgebung |
| CVE-Nummer | Keine CVE vergeben |
| Aktiv ausgenutzt | Nein, es gibt lediglich eine Labordemonstration vom 25. Oktober 2026; der Proof of Concept ist nicht öffentlich |
| Patch verfügbar | Nein, Tailscale hat noch kein Bulletin und keine fehlerbereinigte Version veröffentlicht. Es gibt jedoch Konfigurationsmaßnahmen |
Wie kann die Schwachstelle ausgenutzt werden?
Die Forscherin Erica Windisch von Cyberdione Labs beschreibt in ihrem Bericht, den The Hacker News zusammengefasst hat, dass ein Angreifer bereits ein zugelassenes Gerät im Netzwerk kontrollieren muss und Tailscale SSH Port Forwarding erlauben muss. Über einen Socket, der nur für Root vorgesehen ist, gelang ihr Root-Zugriff auf das Zielsystem. Ohne Tailnet Lock konnte sie über eine Race Condition zudem einen Enrollment-Schlüssel abgreifen und einen eigenen Rechner als vertrauenswürdiges Gerät hinzufügen.
Welche Folgen kann das haben?
Ein einziges gekapertes Gerät kann sich im Labor rasend schnell auf alle Geräte ausbreiten, die die Zugriffsregeln zulassen. Windisch bezeichnet dies als „wormable“, was andere bezweifeln. Tailscale hat die technischen Behauptungen noch nicht bestätigt; VP Engineering Mike Shaver sagte, das Unternehmen untersuche dieselben Bereiche und habe Probleme gefunden, die es behebe. Die Untersuchung wurde bislang nicht unabhängig reproduziert, und die Meldung erfolgte „reported but not coordinated“.
Was sollten IT-Administratoren jetzt tun?
Formulieren Sie SSH-Regeln jeweils von einer Quelle zu einem Ziel und entfernen Sie breit gefasste Regeln auf Basis von Identitäten oder Tags. Deaktivieren Sie SSH Port Forwarding, wo immer möglich. Unter headscale 0.29.5 ist das nicht möglich; behandeln Sie dort jede SSH-Berechtigung wie Root-Zugriff auf das Zielsystem. Aktivieren Sie den Ablauf von Node Keys, schalten Sie Tailnet Lock ein und entfernen Sie ein kompromittiertes Gerät in der Control Plane, denn eine bloße Neuinstallation widerruft kopierte Schlüssel nicht.
Dieser Artikel ist ursprünglich auf Niederländisch bei MSP Business erschienen. Zum Originalartikel →
