In dieser Ausgabe geht es um drei Sicherheitslücken, die MSPs unmittelbar im Tagesgeschäft betreffen. Nach einer kritischen PHP-Schwachstelle (PHP2Shell), die praktisch jede Webhosting-Umgebung betrifft, wird bereits breit gescannt. In Arista VeloCloud Orchestrator wird eine SQL-Injection aktiv ausgenutzt, und GitLab schließt eine Lücke mit dem Höchstwert von 10,0, die Releases aus zwölf Jahren betrifft.
- PHP2Shell: Zwei kritische PHP-Lücken ermöglichen Angreifern Codeausführung ohne Anmeldung, Scans laufen bereits
- Arista warnt vor aktiv ausgenutzter SQL-Injection in VeloCloud Orchestrator
- GitLab schließt kritische Lücke mit CVSS 10,0, die selbst betriebene Installationen bis zu zwölf Jahre zurück betrifft
PHP2Shell: Zwei kritische PHP-Lücken ermöglichen Angreifern Codeausführung ohne Anmeldung, Scans laufen bereits
| Schwachstelle | Zwei Fehler in der Speicherverwaltung und der Fehlerbehandlung von PHP selbst, mit denen ein Angreifer ohne Authentifizierung Code auf dem Server ausführen lassen kann. Laut The Hacker News sind alle Releases der Reihen 7.x und 8.x betroffen |
| CVE-Nummer | CVE-2026-109618 und CVE-2026-109619 |
| CVSS-Score | 9,2 (beide) |
| Aktiv ausgenutzt | Ja, laut The Hacker News. Einen ersten Versuch beobachtete Amazon am 17. Oktober 2026, am 21. Oktober folgten die ersten Angriffe mit dem geleakten Proof of Concept. Nicht alle Quellen bestätigen eine erfolgreiche Ausnutzung |
| Patch verfügbar | Ja, seit 21. Oktober 2026: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 (laut Sekundärquellen; prüfen Sie php.net). Für End-of-Life-Branches gibt es keinen Fix |
Wie kann die Schwachstelle ausgenutzt werden?
Beide Fehler stecken in Code, den nahezu jede Anfrage durchläuft, und laut The Hacker News bezeichnet die PHP Foundation sie als schwer zu beheben, ohne die Kompatibilität zu beeinträchtigen. Entdeckt wurden sie von Forschern von Calif, OpenAI und Wiz. Details und ein Proof of Concept gelangten vor dem geplanten Release an die Öffentlichkeit, woraufhin die PHP Foundation das Release um einen Tag vorzog. Amazon beobachtete bereits am 17. Oktober einen ersten Versuch und am 21. Oktober die ersten Angriffe mit dem geleakten Code, wobei offenbar mehrere Angreifer aktiv sind. Pantheon blockierte am 21. Oktober mehr als 60.000 verdächtige Anfragen, und Cloudflare beobachtet, dass Angreifer ihre Payloads anpassen, um Filter zu umgehen. Auf GitHub kursieren zudem gefälschte PoCs mit Malware. Laut Dutch IT Channel nahmen mehrere niederländische Websites, darunter die der Tweede Kamer (der Zweiten Kammer des niederländischen Parlaments) und des niederländischen NCSC, sich vorsorglich vom Netz.
Was können die Folgen sein?
Ein erfolgreicher Angriff verschafft direkten Zugriff auf das Dateisystem und die Datenbank des Webservers. Die Erkennung ist schwierig: Laut CrowdStrike bleiben die Worker stabil, die Responses liefern HTTP 200 und das Anwendungslog bleibt leer. Die einzige Spur ist ein einzelner Memory-Limit-Fehler im Fehlerlog des Webservers, der häufig als Rauschen abgetan wird. VulnCheck zählt mehr als 2,6 Millionen aus dem Internet erreichbare Hosts mit PHP, von denen ein großer Teil auf veralteten Branches läuft.
Was sollten IT-Administratoren jetzt tun?
Aktualisieren Sie PHP auf die gepatchte Version Ihres Branches oder installieren Sie die Pakete Ihres Hosting-Anbieters (CloudLinux etwa hat Fixes für ea-php52 bis einschließlich ea-php85 veröffentlicht). Hosten Sie Ihre Kunden auf End-of-Life-Versionen, ist eine Migration die einzige echte Lösung; setzen Sie in der Zwischenzeit WAF-Regeln ein, zum Beispiel die von Cloudflare oder AWS. Durchsuchen Sie die Fehlerlogs nach Memory-Limit-Fehlern und prüfen Sie, ob PHP-Prozesse unerwartet Shells starten oder Dateien herunterladen, wie es das FBI empfiehlt. Vertrauen Sie keinen PoCs von GitHub, ohne sie zu prüfen.
Arista warnt vor aktiv ausgenutzter SQL-Injection in VeloCloud Orchestrator
| Schwachstelle | SQL-Injection in Arista VeloCloud Orchestrator (VCO), der zentralen Verwaltungsplattform von VeloCloud SD-WAN. Betroffen sind On-Premises-Releases vor 5.2.3.18, 6.1.3.10 und 6.4.2.12 |
| CVE-Nummer | CVE-2026-114625 |
| CVSS-Score | 9,9 |
| Aktiv ausgenutzt | Ja, von Arista im Advisory vom 22. Oktober 2026 bestätigt |
| Patch verfügbar | Ja: VCO 5.2.3.18, 6.1.3.10 und 6.4.2.12. Hosted und Dedicated Orchestrators sind bereits gepatcht |
Wie wurde die Lücke ausgenutzt?
Laut The Hacker News benötigt ein Angreifer Netzwerkzugriff auf die VCO-Weboberfläche und einen gültigen Login, wobei die niedrigste Kundenrolle (Enterprise Read Only) bereits genügt. Damit lässt sich Superuser-Zugriff auf den Orchestrator erlangen. Die Oberfläche ist standardmäßig erreichbar, und es gibt keine Einstellung, um das zu verhindern. Arista teilt nicht mit, wann die Angriffe begannen oder was die Angreifer anschließend taten.
Was können die Folgen sein?
Vollständige Kontrolle über den Orchestrator und die darin gespeicherten Daten. Es ist bereits die dritte VCO-Lücke, die Arista seit Ende Juli als ausgenutzt meldet. Bei den beiden früheren warnte Arista, dass ein kompromittierter Orchestrator Zugriff auf VeloCloud-Edge-Geräte ermöglichen kann. Ob das auch hier gilt, geht aus dem Advisory nicht hervor. Orchestrators auf Releases, die die früheren Lücken geschlossen haben, sind weiterhin verwundbar.
Was sollten IT-Administratoren jetzt tun?
Aktualisieren Sie On-Premises-Umgebungen auf das gepatchte Release und beschränken Sie den Zugriff auf die Weboberfläche bis dahin auf vertrauenswürdige Verwaltungsnetze. Blockieren Sie die IP-Adressen 74.82.197[.]86 und 38.54.50[.]151 und suchen Sie in den Logs nach ihnen. Achten Sie auf Webshells, Hintertüren, unerwarteten ausgehenden Datenverkehr und kürzlich von Administratoren vorgenommene Änderungen. Bei Verdacht auf eine Kompromittierung sichern Sie zuerst die Logs und Zeitstempel. Betreiben Sie ein älteres, nicht mehr unterstütztes Release, wenden Sie sich an das Arista TAC.
GitLab schließt kritische Lücke mit CVSS 10,0, die selbst betriebene Installationen bis zu zwölf Jahre zurück betrifft
| Schwachstelle | Integer Overflow beim Kompilieren eines speziell präparierten regulären Ausdrucks in Onigmo, der Regex-Engine von Ruby, die GitLab mitliefert. Ermöglicht Codeausführung ohne Authentifizierung auf selbst betriebenen GitLab-Servern, in allen Releases ab 7.0 |
| CVE-Nummer | CVE-2026-110264 |
| CVSS-Score | 10,0 |
| Aktiv ausgenutzt | Nein, GitLab sieht keine Hinweise auf Angriffe, und die Lücke war am 22. Oktober 2026 nicht im CISA-KEV-Katalog gelistet |
| Patch verfügbar | Ja, seit 21. Oktober 2026: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 und 18.11.13. Kein Workaround |
Wie kann die Schwachstelle ausgenutzt werden?
Laut The Hacker News kann ein Angreifer ohne Konto einen speziell präparierten regulären Ausdruck kompilieren lassen, woraufhin der Integer Overflow Codeausführung ermöglicht. GitLab sagt nicht, unter welchen Bedingungen das funktioniert. Gemeldet wurde der Fehler von einem Forscher namens „joaxcar“, der innerhalb eines Monats bereits vier Codeausführungslücken in derselben Regex-Engine gemeldet hat. Frühere Fixes, etwa der vom 12. Oktober, deckten nur Version 19.2 und höher ab, sodass auch aktualisierte Instanzen verwundbar sein können.
Was können die Folgen sein?
Ein GitLab-Server enthält Quellcode, CI/CD-Secrets und Zugänge zu Produktionsumgebungen, eine Übernahme ist also ein Sprungbrett in Kundenumgebungen. GitLab.com und GitLab Dedicated sind bereits abgesichert; das Risiko liegt bei selbst betriebenen Installationen, die MSPs häufig für sich selbst oder für Kunden betreiben.
Was sollten IT-Administratoren jetzt tun?
Aktualisieren Sie auf das gepatchte Release Ihres Branches. Einen Workaround gibt es nicht. Auf einem Single-Node-Server verursachen 19.4.3 und 19.3.6 wegen Datenbankänderungen Downtime; bei Multi-Node-Installationen können Sie dem Zero-Downtime-Verfahren folgen. GitLab hat zwei Sigma-Regeln („Onigmo native worker crash“ und „Org mode render error burst“) veröffentlicht, mit denen Sie die Anwendungslogs durchsuchen können. Dasselbe Release schließt zehn weitere Schwachstellen, darunter eine Kontoübernahme und eine Cache-Poisoning-Lücke in OAuth/OpenID Connect.
Dieser Artikel ist ursprünglich auf Niederländisch bei MSP Business erschienen. Zum Originalartikel →
