Im Mittelpunkt dieser Ausgabe steht PHP2Shell: zwei kritische Lücken in der PHP-Runtime selbst, für die bereits Angriffsversuche beobachtet wurden und wegen derer in den Niederlanden Dienste wie das staatliche Login-System DigiD und das Bürgerportal MijnOverheid vorsorglich offline genommen wurden. Außerdem hat GitLab eine Lücke mit CVSS 10,0 in allen Self-Managed-Versionen seit 2014 geschlossen, und Palo Alto Networks sowie Unit 42 melden, dass Ransomware-Gruppen die GlobalProtect-Lücke in PAN-OS nutzen, um über das VPN bis zu vCenter und Veeam vorzudringen.
- PHP2Shell: zwei kritische RCE-Lücken in der PHP-Runtime, erste Angriffsversuche bereits beobachtet
- GitLab schließt kritische Lücke mit Höchstwertung: nicht authentifizierte Codeausführung auf Self-Managed-Servern
- Ransomware-Gruppen missbrauchen GlobalProtect-Lücke in PAN-OS und greifen auf vCenter und Veeam über
PHP2Shell: zwei kritische RCE-Lücken in der PHP-Runtime, erste Angriffsversuche bereits beobachtet
| Schwachstelle | Zwei Fehler in der PHP-Runtime selbst, nicht in einer Anwendung: ein Out-of-Memory-Fehler und ein Fehler beim Upload-Fortschritt von Sessions. Sie ermöglichen nicht authentifizierte Remote Code Execution. Betroffen sind PHP 8.5 vor 8.5.12, 8.4 vor 8.4.27, 8.3 vor 8.3.36 und 8.2 vor 8.2.35 sowie Berichten zufolge nahezu alle Versionen bis zurück zu PHP 5.4 |
| CVE-Nummer | CVE-2026-109618 und CVE-2026-109619 |
| CVSS-Score | 9,2 für beide (CVSS v4.0, laut PHP) |
| Aktiv ausgenutzt | Angriffsversuche wurden beobachtet: Cloudflare meldete Angriffstraffic, und watchTowr meldete am 21. Oktober 2026 aktive Versuche für beide CVEs. Bestätigte Einbrüche wurden nicht gemeldet, und die Lücken stehen noch nicht im KEV-Katalog der CISA |
| Patch verfügbar | Ja, PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für 7.4, 8.0 und 8.1 wurden Quellcode-Backports veröffentlicht. Distributionen haben früh gepatcht und behalten teilweise alte Versionsnummern bei |
Wie kann die Schwachstelle ausgenutzt werden?
Laut The Hacker News zielt der Angriff auf die Runtime, noch bevor Anwendungscode ausgeführt wird. Bei mod_php genügt laut einem demonstrierten Exploit eine einzige nicht authentifizierte Anfrage. Bei PHP-FPM wurde Codeausführung für den Session-Fehler nachgewiesen, allerdings hängt dies von einer Aktion in der laufenden Anwendung ab. Selbst eine einfache „Hello World“-Seite auf einer verwundbaren Version kann zum Ziel werden. Entdeckt wurden die Fehler von Wiz Research, Calif und dem Codex-Security-Team von OpenAI. Die Veröffentlichung verlief nicht nach Plan: Am 20. Oktober sickerte die Ankündigung durch, und Calif veröffentlichte versehentlich ein Video eines funktionierenden Proof of Concept, woraufhin PHP das Release auf den 21. Oktober vorzog.
Welche Folgen kann das haben?
Angreifer können den Arbeitsspeicher von PHP-Workern auslesen, in dem Passwörter, Tokens, API-Schlüssel und Zertifikate anderer Anfragen liegen können, und im schlimmsten Fall Code auf dem Server ausführen. In den Niederlanden gingen laut dem niederländischen Sender NOS unter anderem MijnOverheid, DigiD und die Website der Tweede Kamer, des niederländischen Parlaments, vorsorglich offline. Das niederländische NCSC stellte keinen Missbrauch fest. Für Hoster und MSPs mit verwalteten Webservern betrifft diese Lücke genau die Ebene, für die Sie als Administrator zuständig sind: Ein Update von WordPress oder Laravel aktualisiert die Runtime nicht.
Was müssen IT-Administratoren jetzt tun?
Aktualisieren Sie PHP über das Serverpaket, den Host oder das Container-Image, und starten Sie anschließend Apache, PHP-FPM und andere langlaufende Worker neu. Prüfen Sie bei Distributionspaketen das Changelog auf die CVEs statt auf die Versionsnummer. Können Sie noch nicht patchen, setzen Sie session.upload_progress.enabled auf 0, stellen Sie memory_limit auf -1 ein und halten Sie post_max_size niedrig. Das deckt nicht alle Varianten ab. Achten Sie auf Hinweise auf einen möglichen früheren Einbruch: ungewöhnliche Multipart-Anfragen gefolgt von Speicherfehlern, wiederholte HTTP-500-Meldungen, ungewöhnlich große PHPSESSID-Cookies und unerklärliche Neustarts von Workern. Der Support für PHP 8.2 endet am 31. Dezember 2026, planen Sie also die Migration.
GitLab schließt kritische Lücke mit Höchstwertung: nicht authentifizierte Codeausführung auf Self-Managed-Servern
| Schwachstelle | Integer Overflow beim Kompilieren eines speziell präparierten regulären Ausdrucks in Onigmo, der Regex-Engine von Ruby, die GitLab selbst mitliefert. Betrifft Self-Managed GitLab von 7.0 bis einschließlich 18.11 (vor 18.11.13), 19.0 vor 19.0.10, 19.1 vor 19.1.9, 19.2 vor 19.2.9, 19.3 vor 19.3.6, 19.4 vor 19.4.3 und 19.5 vor 19.5.1 |
| CVE-Nummer | CVE-2026-110264 |
| CVSS-Score | 10,0 |
| Aktiv ausgenutzt | Nein, GitLab sieht keine Hinweise auf Missbrauch, und die Lücke steht am 22. Oktober 2026 nicht im KEV-Katalog der CISA |
| Patch verfügbar | Ja, 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 und 18.11.13. Es gibt keinen Workaround |
Wie kann die Schwachstelle ausgenutzt werden?
Laut The Hacker News kann ein nicht authentifizierter Angreifer über den Overflow Code auf dem Server ausführen lassen, und zwar „unter bestimmten Voraussetzungen“, die GitLab nicht näher erläutert. Administratoren können ihre Betroffenheit also nicht anhand ihrer Konfiguration ausschließen. Es ist bereits der vierte Codeausführungsfehler in der Regex-Engine von GitLab innerhalb eines Monats, gemeldet von einem Forscher namens joaxcar, und der erste, der auch Versionen vor 19.2 betrifft.
Welche Folgen kann das haben?
Ein kompromittierter GitLab-Server verschafft Zugriff auf Quellcode, CI/CD-Secrets, Deploy-Tokens und oft auch auf die Umgebungen, in die diese ausgerollt werden. Für MSPs, die GitLab für Kunden selbst hosten oder intern nutzen, ist das ein direkter Weg in Kundenumgebungen. GitLab.com und Dedicated-Tenants auf den gepatchten Versionen sind bereits sicher.
Was müssen IT-Administratoren jetzt tun?
Aktualisieren Sie auf die gepatchte Version Ihres Zweigs. Haben Sie am 12. Oktober gepatcht und betreiben Sie 19.2 oder neuer, sind Sie erneut verwundbar, denn jenes Update enthielt diesen Fix nicht. Die Versionen 19.4.3 und 19.3.6 enthalten Datenbankmigrationen; rechnen Sie bei einer Single-Node-Installation daher mit Downtime. Bis das Patchen abgeschlossen ist: Nehmen Sie GitLab vom offenen Internet oder stellen Sie es hinter ein VPN, und nutzen Sie die beiden von GitLab veröffentlichten Sigma-Regeln („Onigmo native worker crash“ und „Org mode render error burst“), um die Anwendungslogs zu durchsuchen.
Ransomware-Gruppen missbrauchen GlobalProtect-Lücke in PAN-OS und greifen auf vCenter und Veeam über
| Schwachstelle | Authentifizierungs-Bypass im GlobalProtect-Portal und -Gateway von PAN-OS, mit dem Angreifer ohne gültige Authentifizierung und unter Umgehung der MFA eine VPN-Sitzung aufbauen |
| CVE-Nummer | CVE-2026-0257 |
| Aktiv ausgenutzt | Ja, seit dem 13. Mai 2026 im KEV-Katalog der CISA. Unit 42 meldete am 19. Oktober 2026 Missbrauch durch Ransomware-Gruppen, darunter Qilin und Inc |
| Patch verfügbar | Ja, über eine korrigierte PAN-OS-Version oder die Workarounds im Advisory von Palo Alto Networks. Prüfen Sie im Advisory die passende Version für Ihren Zweig |
Wie wurde die Schwachstelle ausgenutzt?
Laut dem aktualisierten Threat Brief von Unit 42 gelangen Angreifer über den Bypass ins VPN, erkunden das Netzwerk mit legitimen Remote-Monitoring- und Management-Tools und bewegen sich lateral über RDP und SMB. Zuvor war lediglich von Scans auf GlobalProtect die Rede, inzwischen beschreibt Unit 42 auch Aktivitäten nach dem Zugriff. Dieselben Gruppen sind als Spikey Scorpius (Qilin) und Tarnished Scorpius (Inc) bekannt.
Welche Folgen kann das haben?
In einem untersuchten Fall sprangen Angreifer vom VPN-Gateway auf eine vCenter-Appliance, deaktivierten Sicherheitsfunktionen auf ESXi-Hosts und lasen offline Credentials aus der virtuellen Festplatte eines Domänencontrollers aus. Einige Akteure kombinierten dies mit dem Missbrauch von Veeam-Infrastruktur (CVE-2023-27532). Für MSPs mit Palo-Alto-Firewalls bei Kunden ist die Kette von VPN über Hypervisor bis zum Backup genau das Szenario, in dem Verschlüsselung und der Verlust von Backups zusammenkommen.
Was müssen IT-Administratoren jetzt tun?
Patchen Sie PAN-OS oder setzen Sie die Workarounds aus dem Advisory von Palo Alto Networks um. Durchsuchen Sie die GlobalProtect-Logs nach erfolgreichen Logins von den IP-Adressen aus dem Unit-42-Bericht sowie nach Gerätenamen wie WINDOWS-LAPTOP-001, DESKTOP-GP01 und GP-CLIENT. Prüfen Sie, ob GlobalProtect-Profile mit HTTP/HTTPS-Diensten auf Management-Interfaces verknüpft sind, und beschränken Sie den Administrationszugriff mit Interface-Management-Profilen. Testen Sie von außen, ob die Ports 4443 und 3879 auf Ihrer Management-Adresse erreichbar sind. Bei einem Treffer aktivieren Sie Ihren Incident-Response-Prozess und prüfen zusätzlich vCenter, ESXi und Ihre Veeam-Version.
Dieser Artikel ist ursprünglich auf Niederländisch bei MSP Business erschienen. Zum Originalartikel →
