Das Wichtigste in Kürze 

• STARFACE, unsere STARFACE-Module, der StarfleetController, die von uns vertriebenen UTM-Firewalls und WLAN-Produkte sind von „PHP2Shell“ nicht betroffen. Sie müssen hier nichts unternehmen.
• Betroffen ist ausschließlich die Programmiersprache PHP. Die beiden Lücken (CVE-2026-109618 und CVE-2026-109619) erlauben im schlimmsten Fall das Ausführen von Schadcode auf Webservern – ohne Anmeldung.
• Unser Webhosting (Plesk) haben wir umgehend aktualisiert. Kunden-Websites mit PHP haben wir vorübergehend abgeschaltet und auf eine gepatchte PHP-Version angehoben. Bitte prüfen Sie, ob Ihre Website mit der neuen PHP-Version einwandfrei funktioniert.
• Betreiben Sie eigene PHP-Server, aktualisieren Sie PHP sofort auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 bzw. auf den gepatchten Stand Ihrer Linux-Distribution.

Vorwort

Am 21. Oktober 2026 hat das PHP-Projekt Sicherheitsupdates für zwei kritische Schwachstellen veröffentlicht. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stuft die Lage mit Kritikalität 3 / Orange ein: Maßnahmen müssen unverzüglich ergriffen werden. In Fachmedien heißen die Lücken „PHP2Shell“ – in Anlehnung an die Schwachstelle „Log4Shell“ aus dem Jahr 2021.

Seitdem erreichen uns viele Anfragen von Kunden, ob ihre Telefonanlage, ihre Firewall oder ihre Website betroffen ist. Mit diesem Artikel beantworten wir diese Fragen gesammelt. Außerdem erklären wir, was hinter den Lücken steckt und welche Rolle Künstliche Intelligenz bei ihrer Entdeckung gespielt hat.

Was ist passiert

Das PHP-Projekt hat am 20. Oktober 2026 ein kritisches Sicherheitsupdate angekündigt und es am 21. Oktober um 16 Uhr deutscher Zeit veröffentlicht. Beide Lücken sind nach CVSS 4.0 mit 9.2 von 10 bewertet.

Betroffen sind praktisch alle PHP-Versionen der letzten zehn Jahre, laut CERT-EU zurück bis mindestens PHP 5. Gefährdet ist jede PHP-Installation, die Webanfragen verarbeitet – egal ob PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed. Das höchste Risiko sieht das PHP-Sicherheitsteam bei mod_php.

Behoben ist das Problem in diesen Versionen:

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

Für die nicht mehr unterstützten Versionen 7.4, 8.0 und 8.1 stellt das PHP-Projekt nur noch Quellcode-Backports bereit. Linux-Distributionen wie Debian, Ubuntu und Red Hat liefern eigene, gepatchte Pakete aus.

Stand der Angriffe: Ein Proof-of-Concept ist öffentlich. Das BSI geht von einer kurzfristigen Ausnutzung auf verwundbaren Systemen aus. Bestätigte Angriffe waren zum Zeitpunkt der BSI-Warnung (Version 1.1 vom 21. Oktober 2026) noch nicht bekannt.

Wie funktionieren die Lücken

Beide Lücken entstehen, wenn PHP eine Anfrage wegen eines schweren Fehlers abbrechen muss – typischerweise, weil das Speicherlimit (memory_limit) überschritten wird. PHP räumt in diesem Moment nicht vollständig auf. Es bleiben Verweise auf Speicherbereiche zurück, die bereits freigegeben sind.

Vereinfacht läuft ein Angriff so ab:

1. Der Angreifer schickt eine präparierte Anfrage, zum Beispiel einen Datei-Upload mit sehr vielen leeren Formularfeldern. PHP verbraucht dabei so viel Speicher, dass die Anfrage abbricht.
2. Der PHP-Prozess (Worker) läuft weiter. In ihm bleibt ein „verwaister“ Zustand zurück.
3. Eine zweite Anfrage an denselben Worker greift auf diesen Zustand zu. Der Angreifer kann so Speicher auslesen oder gezielt überschreiben – bis hin zum Ausführen eigenen Codes.

Betroffen sind unter anderem die Fortschrittsanzeige für Datei-Uploads (session.upload_progress), die Verarbeitung von Fehlermeldungen und der Zwischenspeicher OPcache.

Das Gefährliche daran: Die Website selbst muss keinen Fehler enthalten. Die Forscher von Wiz schreiben, dass bereits ein einfaches „Hello World“-Skript genügt. Die Lücke greift, bevor der Code der Anwendung überhaupt läuft. Eine Anmeldung oder eine Aktion des Nutzers ist nicht nötig. Vorgeführt wurden Angriffe unter anderem gegen WordPress, Drupal, Joomla und phpMyAdmin.

Die Tragweite ist groß, weil PHP nach Angaben von Wiz rund 70 % aller Websites antreibt. PHP steckt außerdem in vielen Produkten, bei denen man es nicht sofort vermutet, etwa in Weboberflächen von Appliances. Das niederländische NCSC führt deshalb eine öffentliche Liste betroffener Produkte.

Die Rolle der Künstlichen Intelligenz

Gefunden haben die Lücken zwei Forschungsteams, beide mit Unterstützung durch KI-Modelle. In Berichten wird oft verkürzt das OpenAI-Modell „GPT-5.6 Sol“ als Entdecker genannt. Die Quellen zeichnen ein differenzierteres Bild:

• Calif meldete den ersten Fehler am 11. August 2026 an das PHP-Projekt. Calif arbeitete nach eigenen Angaben mit allgemein verfügbaren KI-Modellen, nennt aber kein bestimmtes Modell. OpenAI hatte Calif zu seiner Initiative „Patch the Planet“ eingeladen, die Open-Source-Projekten bei der Suche und Behebung von Schwachstellen hilft.
• Wiz Research fand ab dem 19. August 2026 weitere Angriffswege. Wiz nennt als Werkzeuge die eigene Plattform Wiz Atlas sowie die Modelle Gemini 4 Argon und GPT-5.6 Sol. Den größten Beitrag schreibt Wiz dabei Gemini 4 Argon zu.

Die Ursache ist übrigens nicht neu: Schon 2004 wurde eine erste Schwachstelle rund um das PHP-Speicherlimit beschrieben, und auch 2020 und 2024 gab es verwandte Funde. Neu ist, dass KI-Modelle aus diesem bekannten Fehlermuster in wenigen Tagen funktionierende Angriffe ableiten konnten.

Wir sehen hier denselben Trend wie bei den Sicherheitslücken in OpenSSL Anfang 2026: KI findet Fehler in alter, viel genutzter Software schneller als je zuvor. Das hat zwei Seiten. Hersteller können Lücken schließen, bevor Kriminelle sie finden. Gleichzeitig können auch Angreifer veröffentlichte Patches mit KI in kurzer Zeit analysieren. Das BSI hält deshalb eine breite Ausnutzung innerhalb weniger Stunden nach Erscheinen der Patches für wahrscheinlich. Die Zeit zwischen Update und Angriff wird kürzer – schnelles Patchen ist wichtiger denn je.

Sind STARFACE und unsere anderen Produkte betroffen?

Nein. Die Lücken stecken in der PHP-Laufzeitumgebung. Produkte, die kein PHP verwenden, sind nicht betroffen – auch wenn sie eine Weboberfläche haben.

STARFACE, der StarfleetController und unsere Module sind in Java entwickelt. Java und PHP sind zwei völlig getrennte Programmiersprachen mit eigenen Laufzeitumgebungen. Ein Fehler im PHP-Interpreter kann sich deshalb nicht auf eine Java-Anwendung auswirken.

Für Ihre Telefonanlage, Ihre Firewall und Ihr WLAN ist kein Update wegen PHP2Shell nötig. Unabhängig davon empfehlen wir wie immer, alle Systeme auf dem aktuellen Stand zu halten.

Unser Webhosting: Was wir getan haben – und was Sie tun sollten

Unser Webhosting basiert auf Plesk und damit auf PHP. Wir haben sofort nach Veröffentlichung der Patches gehandelt:

1. Alle PHP-Versionen auf unseren Hosting-Servern haben wir auf den gepatchten Stand aktualisiert.
2. Kunden-Websites mit PHP haben wir vorübergehend abgeschaltet, um einen Angriff im Zeitfenster bis zum Update auszuschließen.
3. Websites, die noch eine ältere PHP-Version nutzten, haben wir zwangsweise auf eine aktuelle, gepatchte PHP-Version angehoben.

Wir wissen, dass dieser Schritt kurzfristig Einschränkungen verursacht hat. Angesichts einer Lücke, die ohne Anmeldung und unabhängig vom Code der Website ausnutzbar ist, war das aus unserer Sicht der einzige verantwortbare Weg.

Was Sie jetzt tun sollten

Eine neue PHP-Version kann dazu führen, dass ältere Websites, Plugins oder Themes nicht mehr korrekt funktionieren. Bitte prüfen Sie deshalb Ihre Website:

• Startseite und wichtige Unterseiten aufrufen. Fehlermeldungen, weiße Seiten oder „HTTP 500“ weisen auf Inkompatibilitäten hin.
• Formulare, Shop, Login und Datei-Uploads testen.
• CMS (z. B. WordPress, Joomla, TYPO3), Plugins und Themes auf die neueste Version aktualisieren. Aktuelle Versionen sind meist mit neuen PHP-Versionen kompatibel.
• Bei Eigenentwicklungen den Entwickler oder Ihre Agentur beauftragen, den Code an die neue PHP-Version anzupassen.

Funktioniert Ihre Website nicht mehr und kommen Sie nicht weiter, wenden Sie sich an unseren Support. Eine Rückkehr zu einer ungepatchten PHP-Version ist aus Sicherheitsgründen nicht möglich.

Sie betreiben eigene PHP-Server?

Dann sollten Sie umgehend handeln. Die Empfehlungen des BSI und des PHP-Projekts lauten:

1. PHP sofort aktualisieren – auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Bei Linux-Distributionen gilt der gepatchte Stand des Pakets (Backport), auch wenn die Versionsnummer abweicht. Prüfen Sie dazu die Hinweise von Debian, Ubuntu oder Red Hat.
2. Alle PHP-Worker neu starten. Erst danach läuft die neue Version.
3. Container neu bauen. Docker-Images mit PHP müssen mit einem aktuellen Basis-Image neu erstellt werden.
4. Appliances prüfen. Fragen Sie bei Herstellern von Geräten mit PHP-basierter Weboberfläche nach Firmware-Updates. Die Liste des NCSC-NL hilft bei der Einordnung.
5. Alte Versionen ablösen. PHP 8.1 und älter erhalten keine offiziellen Updates mehr. PHP 8.2 erreicht sein Lebensende am 31. Dezember 2026.

Kann ein Update nicht sofort eingespielt werden, empfiehlt das BSI, den Server vorübergehend vom Internet zu trennen. Die vom PHP-Projekt genannten Workarounds – etwa session.upload_progress.enabled = 0 oder Anpassungen an memory_limit und post_max_size – erschweren einen Angriff nur. Sie ersetzen das Update nicht. Auch eine Web Application Firewall bietet keinen vollständigen Schutz.

FAQ / Häufige Fragen

Muss ich an meiner STARFACE etwas tun? Nein. STARFACE basiert auf Java und verwendet kein PHP. Ein Update wegen PHP2Shell ist nicht nötig.

Sind die Fluxpunkt-Module oder der StarfleetController betroffen? Nein. Beide sind ebenfalls in Java entwickelt.

Meine Firewall oder mein WLAN hat eine Weboberfläche. Ist das ein Risiko? Eine Weboberfläche allein bedeutet nicht, dass PHP im Einsatz ist. Die UTM-Firewalls und WLAN-Produkte aus unserem Vertrieb sind nicht betroffen.

Meine Website läuft bei Fluxpunkt und zeigt seit der Umstellung Fehler. Was nun? Wahrscheinlich ist Ihre Website nicht mit der neuen PHP-Version kompatibel. Aktualisieren Sie CMS, Plugins und Themes oder beauftragen Sie Ihren Entwickler. Bei Fragen hilft unser Support.

Kann ich meine Website wieder auf die alte PHP-Version zurückstellen? Nein. Alte, ungepatchte PHP-Versionen sind angreifbar und gefährden auch andere Kunden auf dem Server.

Wurde meine Website angegriffen? Wir haben unsere Server unmittelbar nach Veröffentlichung der Patches abgesichert. Wenn Sie an Ihrer Website Auffälligkeiten bemerken, melden Sie sich bitte bei uns.

Ist PHP2Shell so gefährlich wie Log4Shell? Der Vergleich bezieht sich auf die Art der Lücke: Schadcode aus der Ferne, ohne Anmeldung, in einer sehr weit verbreiteten Software. Log4Shell betraf allerdings Java-Anwendungen, PHP2Shell betrifft PHP. Das eine hat mit dem anderen technisch nichts zu tun.

Zusammenfassung

PHP2Shell ist eine ernste Bedrohung für Webserver mit PHP. Unsere Telefonie-, Netzwerk- und Sicherheitsprodukte sind davon nicht betroffen: STARFACE, unsere Module und der StarfleetController basieren auf Java. Unser Webhosting haben wir umgehend abgesichert. Hosting-Kunden sollten prüfen, ob ihre Website mit der neuen PHP-Version funktioniert. Wir beobachten die Lage weiter und aktualisieren diesen Artikel bei Bedarf.

Quellen

• BSI-IT-Sicherheitshinweis BITS-H 2026-297981-1132, Version 1.1 vom 21.10.2026 (TLP:CLEAR)
• PHP Security Advisory: Critical remote code execution vulnerabilities
• GitHub Advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub Advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Wiz Research: PHP2Shell
• Calif: A tale of two PHP remote vulnerabilities
• CERT-EU Security Advisory 2026-018
• NCSC-NL: Liste betroffener Produkte