In dieser Ausgabe geht es um VPN, NAS und Netzwerkgeräte. Angreifer verketten drei Lücken in Ivanti Connect Secure zu Root-Zugriff und umgehen dabei die Integritätsprüfung, während Tausende GitLab-Server die aktiv ausgenutzte CI/CD-Lücke noch nicht gepatcht haben. Synology warnt vor C3RB3R-Ransomware auf veralteten NAS-Systemen, das niederländische NCSC meldet Angriffe auf Kühlanlagen in Europa und Zyxel schließt eine Lücke in GS1900-Switches.
- Ivanti Connect Secure: Angreifer verketten drei Lücken zu Root-Zugriff und umgehen den Integrity Checker
- GitLab: Kritische Lücke im CI/CD-Regex-Compiler wird aktiv ausgenutzt, auch in den Niederlanden sind noch Server offen
- Synology warnt vor C3RB3R-Ransomware auf NAS-Systemen mit veralteten DSM-Versionen
- Angriffe auf Kühlanlagen in Europa: Auch niederländische Systeme über Internetexposition und Standardpasswörter getroffen
- Zyxel schließt Lücke in GS1900-Switches, über die ein Angreifer im LAN Befehle ausführen kann
Ivanti Connect Secure: Angreifer verketten drei Lücken zu Root-Zugriff und umgehen den Integrity Checker
| Schwachstelle | Kette aus drei Lücken in Ivanti Connect Secure: ein Authentifizierungs-Bypass mit Befehlsausführung, eine lokale Rechteausweitung und ein Datei-Upload in einen bekannten Pfad. Zusammen verschaffen sie einem Angreifer ohne Konto Root-Zugriff. Betroffen sind 25.1.1.2 und älter sowie 22.8R2.5 und älter |
| CVE-Nummer | CVE-2026-104935, CVE-2026-111357 und CVE-2026-118527 |
| CVSS-Score | 8,6 (CVE-2026-104935), 8,8 (CVE-2026-111357) und 4,3 (CVE-2026-118527), laut Ivanti |
| Aktiv ausgenutzt | Ja, laut Volexity seit dem 3. Oktober 2026. CISA hat zwei der Lücken am 30. Oktober in den KEV-Katalog aufgenommen |
| Patch verfügbar | Ja. 25.1.1.3 bzw. 22.8R2.6 behebt die beiden neuen Lücken. Die Fixes vom 13. Oktober (25.1.1.2 und 22.8R2.5) decken diese nicht ab |
Laut Rapid7 nutzte die Bedrohungsgruppe UTA0576 eine Exploit-Kette, um sich ohne Authentifizierung Root-Zugriff auf eine Connect-Secure-Appliance zu verschaffen. Volexity beobachtete die Ausnutzung auf einem Gerät mit 22.8R2.4; anschließend sammelten die Angreifer Passwörter und fragten im Active Directory Windows-LAPS-Passwörter und BitLocker-Wiederherstellungsschlüssel ab. Ivanti zufolge fand die Ausnutzung bei einer begrenzten Zahl von Kunden bereits vor Erscheinen des Advisorys statt. Die erste Lücke der Kette wurde bereits am 13. Oktober gepatcht, die beiden neuen Lücken wurden am 29. Oktober in das Advisory aufgenommen.
Wie wurde die Lücke ausgenutzt?
Die Angreifer senden eine manipulierte Anfrage an die Anmeldeseite des VPN und nutzen anschließend die beiden anderen Lücken, um Root-Rechte zu erlangen. Laut Volexity umgeht diese Aktivität das Integrity Checker Tool von Ivanti, und Logs werden gezielt manipuliert – ein sauberer Scan beweist also nichts. Die Anfrage läuft über /dana-na/auth/url_default/welcome.cgi, mit einem auffälligen X-DSCGI-PATH-Header.
Was kann die Folge sein?
Ein VPN-Gateway steht zwischen dem Internet und dem internen Netzwerk Ihres Kunden. Ein Angreifer, der die Appliance übernimmt, sieht die Anmeldedaten der Mitarbeitenden und kann sich von dort aus im Netzwerk bewegen. Die Rapid7-Meldung nennt den Diebstahl von AD-Daten ausdrücklich. Das NCSC warnte bereits am 13. Oktober vor der ersten Lücke der Kette.
Was sollten IT-Administratoren jetzt tun?
Aktualisieren Sie außerhalb des regulären Patchzyklus auf 25.1.1.3 bzw. 22.8R2.6. Sichern Sie nach Möglichkeit Arbeitsspeicher und Logs, bevor Sie ein Gerät neu starten oder zurücksetzen. Suchen Sie in den Logs nach Anfragen an den oben genannten Pfad mit auffälligen Headern, prüfen Sie /tmp/ und /data/.icscap/ auf fremde Dateien und blockieren Sie die IP-Adresse 108.165.147[.]64. Bei Verdacht auf einen Einbruch folgen Sie den Wiederherstellungsschritten von Ivanti und ersetzen die Passwörter, die die Appliance gesehen haben könnte, darunter die von Servicekonten und LAPS.
GitLab: Kritische Lücke im CI/CD-Regex-Compiler wird aktiv ausgenutzt, auch in den Niederlanden sind noch Server offen
| Schwachstelle | Integer Overflow im Regular Expression Compiler für CI/CD-Konfigurationen von GitLab CE/EE, über den ein Angreifer ohne Konto aus der Ferne Code ausführen kann. Eine zweite Lücke im selben Compiler wurde bereits früher gepatcht |
| CVE-Nummer | CVE-2026-97229 (zweite Lücke: CVE-2026-110264) |
| Aktiv ausgenutzt | Ja, CISA hat die Lücke Ende Oktober in den KEV-Katalog aufgenommen. Shadowserver sieht mehr als 1.000 ungepatchte Server, die angegriffen werden |
| Patch verfügbar | Ja, GitLab 19.4.2, 19.3.5 und 19.2.8 (12. Oktober 2026). GitLab.com ist bereits gepatcht, bei GitLab Dedicated ist nichts zu tun |
BleepingComputer berichtet, dass der Patch bereits seit drei Wochen verfügbar ist, laut Shadowserver aber noch mehr als 1.000 aus dem Internet erreichbare Server verwundbar sind und angegriffen werden. Die zweite Lücke (CVE-2026-110264), die einen Monat früher gepatcht wurde, ist laut Shadowserver noch auf mehr als 11.300 Instanzen offen. Das niederländische Portal Security.nl meldet auf Basis derselben Scans, dass es in den Niederlanden um 14 Server bei der ersten und 175 bei der zweiten Lücke geht.
Wie kann die Schwachstelle ausgenutzt werden?
Ein Angreifer platziert einen speziell präparierten regulären Ausdruck in einer CI/CD-Konfiguration. Bei dessen Verarbeitung läuft der Compiler über, woraufhin der Angreifer Code auf dem GitLab-Server ausführen kann. Unter bestimmten Bedingungen ist dafür kein Konto nötig.
Was kann die Folge sein?
Auf einem GitLab-Server liegen Quellcode, Pipeline-Secrets und häufig Zugangsschlüssel zu Produktions- und Kundenumgebungen. Eine Übernahme verschafft Angreifern also ein Sprungbrett zu allem, was die Pipelines erreichen dürfen. GitLab-Server wurden bereits früher bei Ransomware-Angriffen genutzt, und CISA führt inzwischen sechs GitLab-Lücken im KEV-Katalog.
Was sollten IT-Administratoren jetzt tun?
Prüfen Sie bei sich selbst und bei Ihren Kunden, welche selbstverwalteten GitLab-Installationen laufen, und aktualisieren Sie auf eine der gefixten Versionen oder neuer. Läuft eine Installation schon seit Monaten ungepatcht, behandeln Sie sie als möglicherweise kompromittiert: Rotieren Sie CI/CD-Variablen, Deploy-Schlüssel und Tokens und suchen Sie in der Pipeline-Historie nach auffälligen Konfigurationen.
Synology warnt vor C3RB3R-Ransomware auf NAS-Systemen mit veralteten DSM-Versionen
| Schwachstelle | Ransomware-Angriffe (C3RB3R, auch Cerber genannt) auf Synology-NAS-Geräte mit veraltetem DiskStation Manager. Synology zufolge wird eine im Dezember 2024 gepatchte Schwachstelle ausgenutzt, welche, nennt das Unternehmen jedoch nicht |
| CVE-Nummer | Nicht bestätigt. Das referenzierte Advisory SA-24-20 nennt CVE-2024-10441, CVE-2024-50629 und CVE-2024-10445 |
| Aktiv ausgenutzt | Ja, Synology meldet laufende Angriffe. Die ersten Meldungen gingen gut zwei Wochen vor der Warnung ein |
| Patch verfügbar | Ja, DSM 7.2.2-72806-1, 7.2.1-69057-6, 7.2-64570-4, 7.1.1-42962-7 oder 6.2.4-25556-8 bzw. neuer |
Laut BleepingComputer hat Synology seit August 2019 keine vergleichbare Warnung mehr herausgegeben. Betroffene Nutzer finden eine Lösegeldforderung (read-me3.txt) und verschlüsselte Dateien mit der Endung .L0CK3D. Für den „C3rb3r Decryptor“ verlangen die Angreifer mehrere Tausend Dollar. Die Zahl der betroffenen Geräte ist nicht bekannt.
Wie wurde die Lücke ausgenutzt?
Die Angreifer haben es auf Geräte abgesehen, die nicht aktualisiert wurden und über das Internet erreichbar sind. Shadowserver zählt mehr als 380.000 Synology-Systeme, die aus dem Internet erreichbar sind; wie viele davon verwundbar oder Honeypots sind, ist allerdings unbekannt.
Was kann die Folge sein?
Ein NAS ist bei vielen KMU der Ort für Dateifreigaben und Back-ups. Wird es verschlüsselt und liegen die Back-ups auf demselben Gerät, gibt es nichts mehr, woraus sich etwas wiederherstellen ließe. Die Angreifer warnen zudem, dass eine Wiederherstellung mit Software von Drittanbietern die Dateien irreparabel beschädigen könne.
Was sollten IT-Administratoren jetzt tun?
Inventarisieren Sie die Synology-Geräte bei Ihren Kunden und aktualisieren Sie DSM auf die gefixte Version oder neuer. Aktivieren Sie automatische Updates und nehmen Sie die Verwaltungsoberfläche vom Internet. Bewahren Sie außerdem mindestens eine Back-up-Kopie außerhalb des NAS selbst auf, damit ein verschlüsseltes Gerät nicht zugleich Ihr einziger Wiederherstellungspunkt ist.
Angriffe auf Kühlanlagen in Europa: Auch niederländische Systeme über Internetexposition und Standardpasswörter getroffen
| Schwachstelle | Kühlanlagen verschiedener Hersteller, die direkt am Internet hängen oder Standard- bzw. schwache Passwörter verwenden, sodass Angreifer aus der Ferne Einstellungen wie Temperatur und Abtauzyklen ändern können |
| CVE-Nummer | Keine CVE vergeben |
| Aktiv ausgenutzt | Ja, am 2. November 2026 meldet das NCSC Angriffe in Europa, darunter in den Niederlanden |
| Patch verfügbar | Nein, es gibt keinen zentralen Patch. Das NCSC rät, beim Hersteller nachzufragen, ob die Anlage verwundbar ist, sofort zu aktualisieren und die Anlage vom Internet zu trennen |
Das NCSC untersucht mehrere Angriffe auf Kühlanlagen in Europa und beobachtet die Lage. Security.nl berichtete früher am Tag, dass bei belgischen Supermärkten die Temperatureinstellungen verändert wurden.
Wie wurde die Lücke ausgenutzt?
Angreifer melden sich an Kühlsystemen an, die aus dem Internet erreichbar sind, oder nutzen Schwachstellen bzw. schwache und Standardpasswörter aus. Damit ändern sie Temperatur oder Abtauzyklen, sodass die Kühlung nicht mehr richtig funktioniert.
Was kann die Folge sein?
Produkte können sich überhitzen und verderben, was ein Risiko für die Lebensmittelsicherheit darstellt. Hinzu kommen finanzielle Schäden, entsorgte Ware und möglicherweise ein Betriebsstillstand. Für MSPs mit Kunden in Einzelhandel, Gastronomie oder Lebensmittelproduktion entsteht hier eine neue Verantwortung: Geräte eines Installateurs hängen oft unbemerkt im selben Netzwerk oder an einer eigenen Internetverbindung.
Was sollten IT-Administratoren jetzt tun?
Fragen Sie Ihre Kunden und deren Lieferanten, welche Kühlanlagen mit dem Internet verbunden sind, und erkundigen Sie sich beim Hersteller, ob die Anlage verwundbar ist. Nehmen Sie Systeme vom Internet oder beschränken Sie den Zugriff auf vertrauenswürdige IP-Adressen, ersetzen Sie Standardpasswörter durch starke Passwörter, installieren Sie Sicherheitsupdates und überwachen Sie die Systeme. Vorfälle können Sie freiwillig beim NCSC melden.
Zyxel schließt Lücke in GS1900-Switches, über die ein Angreifer im LAN Befehle ausführen kann
| Schwachstelle | Out-of-Bounds-Write im CGI-Programm der Firmware der Zyxel-GS1900-Serie (GS1900-8, -8HP, -10HP, -16, -24, -24E, -24EP, -24HPv2, -48 und -48HPv2), Firmware 2.90(xxxx.2)C0 und älter |
| CVE-Nummer | CVE-2026-107441 |
| Aktiv ausgenutzt | Nein, Zyxel meldet keine Ausnutzung |
| Patch verfügbar | Ja, Firmware 2.90(xxxx.3)C0 (für den GS1900-8 ist das 2.90(AAHH.3)C0), nur für Modelle, die sich noch im Support-Zeitraum für Schwachstellen befinden |
Laut dem Advisory von Zyxel, das am 3. November erschien, kann ein Angreifer im LAN ohne Authentifizierung über eine speziell präparierte HTTP-Anfrage möglicherweise OS-Befehle ausführen. Gemeldet wurde das Problem von Yegor Vasilenko von Binarly. Zyxel veröffentlichte am selben Tag zudem ein Advisory zu einem Buffer Overflow in diversen Access Points, FWA7-Geräten und einem Security-Router.
Wie kann die Schwachstelle ausgenutzt werden?
Der Angreifer benötigt Zugang zum lokalen Netzwerk und sendet eine präparierte HTTP-Anfrage an die Verwaltungsoberfläche des Switches. Ein Konto ist nicht erforderlich.
Was kann die Folge sein?
Der GS1900 ist ein im Mittelstand weit verbreiteter Switch. Ein Angreifer, der sich bereits im Netzwerk befindet, etwa über einen gehackten Laptop oder einen Gastport, kann über diesen Switch dauerhaft im Netzwerk Fuß fassen und von dort aus Datenverkehr einsehen oder umleiten.
Was sollten IT-Administratoren jetzt tun?
Prüfen Sie, welche GS1900-Modelle bei Ihren Kunden im Einsatz sind, und installieren Sie die gefixte Firmware. Modelle außerhalb des Support-Zeitraums erhalten keinen Patch; beschränken Sie dort den Zugriff auf die Weboberfläche auf ein separates Managementnetz und planen Sie einen Austausch.
Dieser Artikel ist ursprünglich auf Niederländisch bei MSP Business erschienen. Zum Originalartikel →
