Wer heute eine Website betreibt oder online nutzt, sollte Passwörter und Updates nicht auf die lange Bank schieben. In der weit verbreiteten Programmiersprache PHP sind zwei kritische Sicherheitslücken entdeckt worden. Forschende der TU Berlin gehen davon aus, dass PHP mehr als 75 Prozent aller Websites antreibt – darunter Onlineshops, Blogs und Nachrichtenportale. Betroffen sein können unter anderem WordPress, WooCommerce, Magento, Joomla und Drupal.

Die als „PHP2Shell“ bezeichneten Lücken tragen die Kennungen CVE-2026-109618 und CVE-2026-109619. Sie stecken in der Speicherverwaltung: Bei Fehlern während der Verarbeitung einer Anfrage können Daten unvollständig verarbeitet oder bereits freigegebene Speicherbereiche erneut verwendet werden. Angreifer können dadurch eigene Befehle einschleusen und Server aus der Ferne steuern – ohne Anmeldung am System.

Angriffe liefen schon vor dem Patch

Erste Details wurden am Abend des 20. Oktober 2026 auf Hacker News veröffentlicht, einen Tag vor dem ursprünglich vorgesehenen Termin. Das PHP-Team stellte am 21. Oktober um 15:45 Uhr Sicherheitsupdates bereit. Cloudflare beobachtet bereits Angriffe, laut CERT-EU kursieren erste Anleitungen zur Ausnutzung. Amazon meldete Versuche gegen Honeypots ab dem 17. Oktober, auch watchTowr berichtete von Angriffen. Öffentliche Proofs of Concept sind verfügbar, das neuseeländische NCSC meldete Hinweise auf aktive Ausnutzung.

Das RUS-CERT der Universität Stuttgart konnte einen Exploit erfolgreich an einem Testsystem verifizieren. Das BSI bewertet die Lücken mit CVSS 9.8 („kritisch“), während PHP und Sicherheitsforschende für beide Schwachstellen CVSS v4.0 9,2 angeben. Stand 22. Oktober 2026 standen die CVEs noch nicht im KEV-Katalog der CISA; das BSI hatte zu diesem Zeitpunkt keine Ausnutzung bestätigt. Das klingt widersprüchlich, ist es aber nicht: Angriffsversuche und bestätigte Vorfälle sind zwei verschiedene Dinge.

Die Zeit zwischen der Veröffentlichung einer Lücke und ersten Exploits wird laut RUS-CERT inzwischen oft in Stunden oder Tagen gemessen. Bei PHP2Shell begannen die Versuche sogar vor der Patch-Veröffentlichung. Zahlreiche Behörden nahmen ihre Internetseiten deshalb vorsorglich vom Netz. Laut BSI waren Wiz und Calif.io gemeinsam mit OpenAI an der Entdeckung beteiligt. KI-Werkzeuge können inzwischen offenbar beides: Sicherheitslücken finden und sie ausnutzen.

Hier könnte Ihr Advertorial stehen
Ein Advertorial bietet Unternehmen die Möglichkeit, ihre Botschaft direkt im redaktionellen Umfeld zu platzieren

Welche Systeme betroffen sind

PHP stuft Webserver-Installationen einschließlich PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed als potenziell betroffen ein. Bei mod_php gilt das Risiko als besonders hoch, weil eine nicht authentifizierte Anfrage den Angriff auslösen kann, bevor überhaupt Anwendungscode läuft.

Technisch werden beide Lücken mit einem Use-after-free in Verbindung gebracht. Im PHP-Changelog stehen sie unter „Avoid state corruption via bailout“. Bei CVE-2026-109618 können bei Speichermangel teilweise initialisierte Anfragedaten während der Bereinigung als gültig behandelt werden. Bei CVE-2026-109619 kann anfragebezogener globaler Zustand nach der Speicherfreigabe in dauerhaft laufenden Workern verbleiben und von späteren Anfragen genutzt werden.

Laut CERT-EU sind alle PHP-Versionen ab PHP 5 betroffen – also Versionen aus ungefähr zwei Jahrzehnten. In der Praxis kann PHP in WordPress, Drupal, TYPO3, Nextcloud, ownCloud, MediaWiki, DokuWiki, selbst entwickelten Webseiten und Docker-Containern stecken. Auch Control Panels, Appliances und Herstellersoftware können PHP enthalten; dort richten sich die Update-Zyklen nach den jeweiligen Anbietern.

Zum Veröffentlichungszeitpunkt unterstützte PHP vier Entwicklungszweige: 8.5 und 8.4 mit aktivem Support, 8.3 und 8.2 ausschließlich mit Sicherheitsupdates. Das Support-Ende von PHP 8.2 ist der 31. Dezember 2026. PHP 8.1 ist seit dem 31. Dezember 2025 ohne offiziellen Support, PHP 8.0 seit dem 26. November 2023, PHP 7.4 seit dem 28. November 2022 und PHP 5.6 seit dem 31. Dezember 2018.

PHP zufolge sind alle Versionen unterhalb von 8.2.35 betroffen. Eine Shodan-Banner-Auswertung vom 20. Oktober meldete rund 884.000 internetnahe Hosts mit einer End-of-Life-PHP-Version. Das entsprach 59 Prozent von rund 1,5 Millionen Hosts mit sichtbarer Versionsangabe. Weitere rund 740.000 Hosts verrieten ihre PHP-Version nicht. Die Zahlen beruhen auf Banner-Zählungen und bestätigen keine tatsächliche Verwundbarkeit.

Patchen, neu starten, nachhaken

Für Website-Betreiber stehen diese korrigierten PHP-Versionen bereit:

  • PHP 8.5.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 8.2.35

Die Empfehlung ist unspektakulär, aber dringend: PHP aktualisieren und den Server anschließend neu starten. Wer einen Hosting-Dienst nutzt, sollte beim Anbieter nachfragen, ob die Reparatur bereits durchgeführt wurde. Für PHP 8.1 und ältere Versionen gibt es kein offizielles Sicherheitsupdate. PHP empfiehlt den Wechsel auf einen unterstützten Zweig, Backports durch Distributionen oder LTS-Anbieter sowie Quellcode-Backports für PHP 7.4, 8.0 und 8.1. Für PHP 5.6 gibt es keine offiziellen Backports.

Debian, Red Hat und Ubuntu veröffentlichten korrigierte Pakete, teilweise auch für nicht mehr unterstützte PHP-Zweige. cPanel stellte korrigierte PHP-Pakete einschließlich Backports für PHP 7.4, 8.0 und 8.1 bereit. Plesk veröffentlichte korrigierte PHP-Builds und ein Update für seine Verwaltungsoberfläche. Updates des zugrunde liegenden PHP beheben die Lücken auch in darauf laufenden Anwendungen wie WordPress, Drupal und Nextcloud.

Für Palo Alto Networks gelten alle Versionen von PAN-OS und Panorama als betroffen. Bis Korrekturen verfügbar sind, soll der Zugriff auf Management-Schnittstellen auf vertrauenswürdige interne IP-Adressen beschränkt werden. CERT-EU empfiehlt außerdem, internetexponierte Anwendungen bis zum Patchen aus öffentlichen Netzen zu isolieren. Die CISA rät, nicht unverzüglich aktualisierbare Systeme sowie PHP 8.1 und ältere Versionen bis zur Behebung vom Netz zu nehmen.

Als vorübergehende Maßnahmen nennt PHP unter anderem memory_limit=-1 gegen CVE-2026-109618 und session.upload_progress.enabled=0 gegen CVE-2026-109619. Diese Einstellungen ersetzen kein Update. Die Mitigations helfen laut PHP-Autoren gegen bestimmte Exploits, schließen die Schwachstellen aber nicht vollständig. Eine öffentlich erreichbare PHP-Anwendung sollte damit also nicht einfach weiterbetrieben werden.

Auch Besucher sollten aufmerksam sein

Die Sache betrifft nicht nur Serverleute mit müden Augen vor dem Terminal. Angreifer können über die Lücken sensible Daten aus dem Arbeitsspeicher betroffener Server auslesen, darunter Passwörter und kryptografische Schlüssel. Nutzerinnen und Nutzer sollten deshalb Mitteilungen ihrer Webdienste beachten. Wenn ein Dienst zur Änderung des Passworts auffordert, ist das kein Newsletter, den man irgendwann zwischen Mensa und Seminar wegklickt.

Greenbone hat für beide CVEs Prüfungen in den OPENVAS ENTERPRISE FEED aufgenommen. Authentifizierte Scans suchen systemweit nach PHP-Dateien und Binärdateien, agentenbasierte Scans verwenden lokale Nachweismethoden. Paketprüfungen gibt es für Arch, Rocky Linux, Amazon Linux, Red Hat, Oracle Linux, Ubuntu, Debian, Slackware, Fedora und Mageia; weitere Distributionen sollen folgen. Ein manuelles Feed-Update lädt die Prüfungen sofort, sonst wird der Feed über Nacht aktualisiert.

Nicht authentifizierte Scans können nur öffentlich preisgegebene Versionsinformationen auswerten. Authentifizierte Scans untersuchen die installierte Software und erkennen PHP auch bei verborgenem Versionsbanner. Für eine tiefere Windows-Prüfung muss vor dem Scan die Erkennung portabler Anwendungen aktiviert werden. Wer bereits mit CVE-2024-4577 zu tun hatte, kennt das Tempo: Diese Lücke wurde 2024 innerhalb eines Tages nach Bekanntwerden angegriffen. Bei PHP2Shell begannen die Versuche noch früher.

Die RUS-CERT-Information vom 21. Oktober 2026, zuletzt am 22. Oktober 2026 aktualisiert,