In dieser Ausgabe geht es um vorhandene Funktionen und alte Lücken, die jetzt ausgenutzt werden. Ein Linux-Kernel-Fehler aus dem Mai steht im CISA-Katalog und macht PHP2Shell-Webshells zu Root-Shells, eine chinesische Spionagegruppe nutzte eine VMware-ESX-Zero-Day-Lücke, um Logs zu verschleiern, Angreifer haben es auf Magento-Onlineshops abgesehen und Phisher setzen MDM-Plattformen ein, um ScreenConnect auszurollen.
- Linux-Lücke Fragnesia wird aktiv ausgenutzt und steht im CISA-Katalog: Kernel-Fehler macht aus einer Webshell eine Root-Shell
- Chinesische Spionagegruppe nutzte VMware-ESX-Zero-Day-Lücke, um Spuren aus Audit-Logs herauszuhalten, CISA nimmt die Lücke in den Katalog auf
- Kritische Upload-Lücke in Magento und Adobe Commerce wird gegen Onlineshops ausgenutzt
- Angreifer missbrauchen MDM-Plattformen als Hintertür: Hexnode und Rippling bringen ScreenConnect auf Endpoints
Linux-Lücke Fragnesia wird aktiv ausgenutzt und steht im CISA-Katalog: Kernel-Fehler macht aus einer Webshell eine Root-Shell
| Schwachstelle | Fehler im ESP-in-TCP-Pfad von XFRM im Linux-Kernel (Fragnesia): Ein lokaler Angreifer kann Daten in den Page Cache schreibgeschützter Dateien wie /usr/bin/su schreiben und so Root-Rechte erlangen. Betroffen sind Kernel älter als 7.0.10, 6.18.33, 6.12.91, 6.6.141, 6.1.174 und 5.15.208 sowie Distributionskernel ohne den Fix |
| CVE-Nummer | CVE-2026-46300 |
| CVSS-Score | 7,8 (laut Security Affairs) |
| Aktiv ausgenutzt | Ja, die CISA hat die Lücke am 28. Oktober 2026 in den KEV-Katalog aufgenommen, mit einer Frist bis zum 31. Oktober für US-Bundesbehörden |
| Patch verfügbar | Ja, in den stabilen Kerneln 7.0.10, 6.18.33, 6.12.91, 6.6.141, 6.1.174 und 5.15.208 sowie in Distributionskerneln. Vorübergehende Maßnahme: die Module esp4 und esp6 blockieren |
Wie wurde die Lücke ausgenutzt?
Fragnesia ist eine lokale Privilege Escalation: Der Angreifer muss bereits Code auf dem Server ausführen können. Laut dem Forscher William Bowling von V12 (via Security Affairs) war die Lücke seit Mai öffentlich bekannt, einschließlich Proof of Concept. Da die CISA sie nun in den Katalog der bekanntermaßen ausgenutzten Schwachstellen aufnimmt, gibt es Belege dafür, dass Angreifer sie verwenden. Security Online berichtet, dass sie mit den PHP2Shell-Lücken aus dem Patchwork vom 27. Oktober kombiniert wird: zuerst eine Webshell über PHP, dann Root-Rechte über den Kernel.
Welche Folgen kann das haben?
Die Änderung findet nur im Arbeitsspeicher statt, nicht auf der Festplatte. HOL Guard beschreibt, dass ein Angreifer auf diese Weise eine Datei wie /etc/pam.d/su manipulieren kann, ohne Spuren auf der Disk zu hinterlassen. Ein Neustart oder das Leeren des Caches beseitigt damit auch die Beweise. Ein Webserver, der bereits über PHP2Shell übernommen wurde, kann sich so zu einem vollständig kompromittierten Host entwickeln.
Was sollten IT-Administratoren jetzt tun?
Installieren Sie einen gepatchten Kernel oder das Update Ihrer Distribution und starten Sie den Host anschließend neu. Können Sie nicht sofort patchen, blockieren Sie die Module esp4 und esp6. Führen Sie bei Hosts mit Verdacht auf PHP2Shell-Missbrauch vor dem Neustart zunächst eine forensische Triage des Page Cache durch. Achten Sie auch auf Firewalls und Appliances, die auf einem Linux-Kernel laufen: Dort sind Sie auf Firmware des Herstellers angewiesen.
Chinesische Spionagegruppe nutzte VMware-ESX-Zero-Day-Lücke, um Spuren aus Audit-Logs herauszuhalten, CISA nimmt die Lücke in den Katalog auf
| Schwachstelle | Unzureichendes Logging in VMware ESX: Ein Angreifer mit Administratorrechten kann bestimmte Aktionen ausführen, ohne dass sie protokolliert werden. Betrifft ESX, vSphere Foundation, Cloud Foundation und Telco Cloud Platform |
| CVE-Nummer | CVE-2026-41709 |
| CVSS-Score | 2,7 |
| Aktiv ausgenutzt | Ja, als Zero-Day Anfang 2026 durch Warp Panda (CrowdStrike). Die CISA hat die Lücke am 28. Oktober 2026 in den KEV-Katalog aufgenommen, mit einer Frist bis zum 11. November |
| Patch verfügbar | Ja, seit dem Broadcom-Advisory vom Juli 2026: ESXi80U3j-25429389, ESXi-9.0.2.0100-25595025, ESXi-9.1.0.0-25370933 und VCF 5.2.4 |
Wie wurde die Lücke ausgenutzt?
Laut The Hacker News geht dies aus dem Legal Threat Landscape Report von CrowdStrike hervor. Die chinesische Spionagegruppe Warp Panda, auch bekannt als Armory Castle (früher UNC5221), Clay Typhoon und VerdantBamboo, nutzte die Lücke Anfang 2026, um die Sichtbarkeit des Audit-Trails zu verringern. Die Gruppe verschafft sich über aus dem Internet erreichbare Edge-Geräte mit Zero-Days und eigener Malware Zugang, bewegt sich anschließend zu VMware vCenter und installiert die Malware BRICKSTORM und SharpStorm. Teilweise stiehlt die Gruppe Cloud-Session-Tokens für den Zugriff auf Microsoft 365, und in mindestens einem Fall registrierte sie ein neues MFA-Gerät, um den Zugang auch nach einer Passwortänderung zu behalten. Mandiant schrieb Warp Panda Anfang dieses Monats außerdem die Zero-Day-Lücke in BeyondTrust Remote Support zu.
Welche Folgen kann das haben?
Der niedrige Score vermittelt ein falsches Bild. Die Lücke verschafft dem Angreifer keinen Zugang, sie macht seine Aktivitäten unsichtbar. Ein MSP, der ESX-Hosts für Kunden verwaltet, findet nach einem Einbruch unter Umständen weniger Logeinträge, als Aktionen stattgefunden haben, sodass eine Incident-Untersuchung zu wenig Beweise liefert.
Was sollten IT-Administratoren jetzt tun?
Installieren Sie die Fixes aus dem Broadcom-Advisory vom Juli (siehe auch die CISA-Meldung), auch wenn Ihre ESX-Hosts nicht mit dem Internet verbunden sind. Beschränken Sie Administratorkonten auf ESX und vCenter, leiten Sie Logs an einen externen Logserver weiter und prüfen Sie vCenter auf unbekannte MFA-Geräte und ungewöhnliche Sessions.
Kritische Upload-Lücke in Magento und Adobe Commerce wird gegen Onlineshops ausgenutzt
| Schwachstelle | Uneingeschränkter Upload von Dateien mit gefährlichem Typ in Adobe Commerce und Magento Open Source. Betroffen: Commerce 2.4.8-p5 und früher, 2.4.7-p10 und früher, 2.4.6-p15 und früher, 2.4.5-p17 und früher, 2.4.4-p18 und früher (sowie 2.4.9), Magento Open Source 2.4.8-p5, 2.4.7-p10 und 2.4.6-p15 und früher, B2B 1.5.3 und frühere Releases, Commerce Events 1.6.0 bis einschließlich 1.20.0 |
| CVE-Nummer | CVE-2026-48356 |
| CVSS-Score | 9,6 |
| Aktiv ausgenutzt | Ja, die CISA hat die Lücke am 27. Oktober 2026 in den KEV-Katalog aufgenommen. Adobe meldete bei der Veröffentlichung im Juli noch keine Ausnutzung |
| Patch verfügbar | Ja, Bulletin APSB26-73 vom 14. Juli 2026: die 2026-jul-Releases (zum Beispiel 2.4.8-2026-jul für Commerce und Magento Open Source) und Commerce Events 1.21.0 |
Wie wurde die Lücke ausgenutzt?
Laut dem niederländischen Sicherheitsportal Security.nl meldet die CISA Angriffe auf Onlineshops über diese Lücke, ohne Einzelheiten zu den Angriffen zu nennen. Ein nicht authentifizierter Angreifer kann gefährliche Dateitypen auf den Webserver hochladen. Das Adobe-Bulletin nennt dabei eine Benutzerinteraktion als Voraussetzung und spricht von einer möglichen Privilege Escalation.
Welche Folgen kann das haben?
Mehr als hunderttausend Onlineshops laufen auf Magento oder Adobe Commerce. Schwachstellen in dieser Plattform werden häufig genutzt, um Kundendaten und Kreditkartendaten zu stehlen. Für einen MSP oder Hoster mit Magento-Kunden zählt das doppelt: Der Patch ist bereits seit Monaten verfügbar, ein Shop, der jetzt übernommen wird, hat also ein bekanntes Update versäumt.
Was sollten IT-Administratoren jetzt tun?
Prüfen Sie für jede Magento-Installation, ob der Patch vom Juli 2026 (APSB26-73) installiert ist. Suchen Sie in den Upload-Verzeichnissen und im Webroot nach unbekannten PHP-Dateien oder anderen ausführbaren Uploads. Prüfen Sie außerdem die Checkout-Seite auf hinzugefügte Skripte.
Angreifer missbrauchen MDM-Plattformen als Hintertür: Hexnode und Rippling bringen ScreenConnect auf Endpoints
| Schwachstelle | Missbrauch vorhandener Funktionen: Opfer registrieren ihr Gerät nach einem Phishing-Angriff bei einem MDM-Tenant des Angreifers (beobachtet bei Hexnode und Rippling), woraufhin der Angreifer unautorisiert ScreenConnect als SYSTEM ausrollt |
| CVE-Nummer | Keine CVE vergeben |
| Aktiv ausgenutzt | Ja, laut Huntress (28. Oktober 2026) |
| Patch verfügbar | Nein, es gibt keinen Softwarefehler. Maßnahme: zugelassene MDM-Tenants und RMM-Instanzen inventarisieren und unerwartete Registrierungen als Incident behandeln |
Wie wurde die Lücke ausgenutzt?
Laut Huntress (Autor Ben Nahorney) beginnt es mit Social Engineering. Im ersten Fall erhielt ein Benutzer eine Phishing-Mail zu einer Angebotseinladung, mit einer MSI-Datei, die sich als DocuSign-Installer ausgab, aber ein Hexnode-MDM-Paket enthielt. Anschließend wurde ScreenConnect mit einem Relay des Angreifers installiert. Der MSP entfernte ScreenConnect, doch Stunden später war es wieder da, weil der MDM-Client nicht entfernt worden war. Im zweiten Fall klickte eine Empfangsmitarbeiterin auf eine gefälschte Teams-Termineinladung. Das Gerät wurde in einem Rippling-MDM-Tenant des Angreifers registriert, der Agent lief als SYSTEM und etwa 35 Minuten später folgte ScreenConnect.
Welche Folgen kann das haben?
Der MDM-Client ist ein vertrauenswürdiger Verwaltungsweg, daher stuft Sicherheitssoftware ihn als normal ein. Entfernen Sie nur das RMM-Tool, rollt der Angreifer es einfach erneut aus. Für MSPs ist das besonders heikel, da Ihr eigenes RMM und MDM für Kunden genauso aussehen.
Was sollten IT-Administratoren jetzt tun?
Führen Sie ein Inventar zugelassener MDM-Produkte, Tenants, Agents und RMM-Instanzen und behandeln Sie eine unerwartete Registrierung als Sicherheitsvorfall. Ein frühes Signal im zweiten Fall war ein neuer Rippling-Registry-Schlüssel. Isolieren Sie einen verdächtigen Endpoint, entfernen Sie ihn aus dem unbekannten MDM-Tenant, widerrufen Sie Sessions und Tokens, setzen Sie Zugangsdaten zurück und installieren Sie das Gerät neu, wenn sich seine Integrität nicht feststellen lässt. Schulen Sie Benutzer im Umgang mit unerwarteten Besprechungs-, Signatur- und Angebotsanfragen.
Dieser Artikel ist ursprünglich auf Niederländisch bei MSP Business erschienen. Zum Originalartikel →
