21. Oktober 2026 | PHP | IT-Sicherheit
Am 21. Oktober 2026 hat das PHP-Sicherheitsteam Updates für alle noch unterstützten PHP-Versionen veröffentlicht. Sie schließen zwei kritische Schwachstellen, die als PHP2Shell bekannt geworden sind. Das BSI hat dazu eine Warnung herausgegeben und verlangt, betroffene Systeme unverzüglich zu patchen. Wer einen Webserver mit PHP betreibt, sollte heute noch handeln. Das gilt auch für alle, die „nur“ ein WordPress, Nextcloud oder Joomla betreiben, denn diese Anwendungen laufen auf PHP.
Dieser Beitrag fasst zusammen, was passiert ist, welche PHP-Versionen betroffen sind, welche Version Sie jetzt brauchen und wie Sie in wenigen Minuten prüfen, ob Ihr Server abgesichert ist.
Inhalt dieses Beitrags
- Was ist passiert? Der zeitliche Ablauf
- Die beiden PHP-Schwachstellen im Überblick
- Wer ist betroffen?
- Diese PHP-Versionen sind sicher
- So prüfen und aktualisieren Sie Ihren Server
- PHP 8.1 und älter: kein offizielles Update
- Übergangsmaßnahmen und die Frage „Server offline nehmen?“
- Häufige Fragen
- Unterstützung durch Biricon IT Services
Was ist passiert? Der zeitliche Ablauf
Das PHP-Sicherheitsteam hat die Veröffentlichung der Korrekturen vorab angekündigt, damit Hoster und Administratoren Zeit hatten, sich vorzubereiten. Die Veröffentlichung selbst fand am 21. Oktober 2026 statt. Das BSI hat noch am selben Tag seine Warnung (Version 1.1) herausgegeben.
- 20. Oktober 2026: Vorwarnung des PHP-Sicherheitsteams, dass am Folgetag Sicherheitsupdates erscheinen.
- 21. Oktober 2026, 14:00 UTC (16:00 Uhr MESZ): Die Patches für PHP 8.5, 8.4, 8.3 und 8.2 werden veröffentlicht.
- 21. Oktober 2026: Das BSI warnt vor den „kritischen Schwachstellen, die Webanwendungen weltweit bedrohen“, und empfiehlt, unverzüglich zu patchen. Nach Angaben des BSI haben große Hosting-Anbieter zum Teil Server vorsorglich offline genommen.
Die beiden PHP-Schwachstellen im Überblick
Es handelt sich um zwei getrennte Fehler im PHP-Kern: CVE-2026-109618 und CVE-2026-109619. Beide können nach den Angaben des PHP-Sicherheitsteams dazu führen, dass ein Angreifer Programmcode auf dem Server ausführen kann, ohne sich anzumelden (unauthenticated Remote Code Execution). Die Schwachstellen werden mit CVSS v4.0: 9,2 (kritisch) bewertet.
| Merkmal | Bedeutung |
|---|---|
| Kennungen | CVE-2026-109618 und CVE-2026-109619 |
| Bewertung | CVSS v4.0: 9,2 — kritisch |
| Auswirkung | Ausführen von Code auf dem Server (Remote Code Execution), ohne Anmeldung |
| Ursache 1 | Beschädigter Speicher, wenn PHP während der Verarbeitung keinen Arbeitsspeicher mehr bekommt (Out-of-Memory) |
| Ursache 2 | Veralteter globaler Zustand, der zwischen Anfragen im Speicher stehen bleibt |
| Besonders gefährdet | Apache mit mod_php |
Nach Einschätzung des BSI gab es zum Zeitpunkt der Veröffentlichung keine bestätigten Angriffe, es gab aber unbestätigte Hinweise auf Ausnutzungsversuche. Bei kritischen Lücken in einer so weit verbreiteten Software ist erfahrungsgemäß damit zu rechnen, dass Angreifer die Korrekturen analysieren und automatisierte Angriffe vorbereiten. Das Zeitfenster zum Patchen ist deshalb kurz.
Wer ist betroffen?
Betroffen ist grundsätzlich jeder Server, auf dem PHP läuft, unabhängig davon, wie PHP angebunden ist: PHP-FPM, mod_php im Apache, php-cgi, FrankenPHP oder LiteSpeed. Am höchsten ist das Risiko laut PHP-Sicherheitsteam bei Apache mit mod_php.
Das BSI nennt ausdrücklich Anwendungen, die auf PHP aufbauen und deshalb mitbetroffen sein können:
- Content-Management-Systeme: WordPress, Drupal, TYPO3, Joomla
- Shopsysteme: Magento
- Cloud- und Dateiablage: Nextcloud
- Firewall-Oberflächen: pfSense, OPNsense
Die Anwendung selbst muss dafür nicht fehlerhaft sein. Die Lücke liegt in PHP, deshalb hilft ein Update von WordPress, Nextcloud & Co. allein nicht. Es muss die PHP-Version auf dem Server aktualisiert werden. Bei Firewalls wie pfSense und OPNsense kommt die korrigierte PHP-Version über das jeweilige Firmware-Update des Herstellers.
Diese PHP-Versionen sind sicher
Die Schwachstellen sind in den folgenden Versionen behoben. Alles darunter gilt als verwundbar.
| PHP-Zweig | Mindestens erforderlich | Hinweis |
|---|---|---|
| PHP 8.5 | 8.5.12 | aktueller Zweig |
| PHP 8.4 | 8.4.27 | |
| PHP 8.3 | 8.3.36 | |
| PHP 8.2 | 8.2.35 | Support endet am 31. Dezember 2026 |
| PHP 8.1 und älter | kein offizielles Update, siehe unten | |
So prüfen und aktualisieren Sie Ihren Server
1. Installierte PHP-Version feststellen
Auf der Kommandozeile des Servers zeigt php -v die Version der Kommandozeilen-PHP. Der Webserver kann eine andere PHP-Version verwenden. Prüfen Sie deshalb auch die Version von PHP-FPM beziehungsweise des Apache-Moduls, zum Beispiel mit php-fpm8.3 -v oder über eine Seite, die phpinfo() ausgibt (diese anschließend sofort wieder entfernen).
2. Update über die Paketverwaltung einspielen
Bei Debian, Ubuntu, RHEL und Verwandten kommt die korrigierte Version über die normale Paketverwaltung, zum Beispiel apt update && apt upgrade oder dnf upgrade. Bei Fremdquellen wie dem Sury-PPA oder Remi-Repository erscheinen die neuen Pakete meist zeitnah.
apt changelog php8.3-fpm oder rpm -q --changelog php | grep CVE-2026-1096).
3. PHP-Dienst neu starten
Ein Paketupdate allein genügt nicht: laufende PHP-Prozesse behalten den alten Code im Speicher. Starten Sie PHP-FPM (systemctl restart php8.3-fpm) beziehungsweise Apache (systemctl restart apache2) neu, und prüfen Sie danach, ob die Prozesse nach dem Update gestartet wurden.
4. Gehostete Webseiten
Bei Shared Hosting aktualisiert in der Regel der Anbieter. Im Kundenmenü lässt sich meist die PHP-Version je Webseite einstellen. Wählen Sie dort eine der oben genannten sicheren Versionen, oder fragen Sie beim Anbieter nach dem Stand der Patches. Nach Angaben des BSI haben einzelne Anbieter Server vorsorglich vom Netz genommen. Falls Ihre Seite kurz nicht erreichbar ist, kann das die Ursache sein.
PHP 8.1 und älter: kein offizielles Update
Für PHP 8.1 und älter gibt es keine offiziellen Sicherheitsupdates mehr. Betreiber solcher Systeme haben zwei Möglichkeiten:
- Auf eine unterstützte Version wechseln (empfohlen). Je älter die Version, desto größer ist der Anpassungsaufwand für Anwendung und Erweiterungen, deshalb sollte ein Wechsel vorher getestet werden.
- Korrekturen zurückportieren. Das PHP-Sicherheitsteam hat die Korrekturen in Entwicklungszweigen auf GitHub bereitgestellt. Wer PHP selbst kompiliert, kann diese Änderungen in ältere Versionen übernehmen. Das ist eine Übergangslösung und erfordert Fachwissen.
Auch PHP 8.2 ist nur noch bis zum 31. Dezember 2026 unterstützt. Planen Sie den Umstieg auf PHP 8.4 oder 8.5 deshalb jetzt ein, und verschieben Sie ihn nicht auf den Jahreswechsel.
Übergangsmaßnahmen und die Frage „Server offline nehmen?“
Das PHP-Sicherheitsteam hat mit der Ankündigung auch vorläufige Schutzmaßnahmen beschrieben. Diese mindern das Risiko, schließen die Lücken aber nicht vollständig. Sie ersetzen das Update nicht und sind nur dafür gedacht, die Zeit bis zum Update zu überbrücken.
Ob ein Server bis zum Update vom Netz genommen werden sollte, hängt von seiner Bedeutung und seiner Erreichbarkeit ab. Das BSI führt aus, dass große Anbieter diesen Schritt gegangen sind. Als Faustregel gilt:
- Öffentlich erreichbarer Server, Update jetzt möglich: sofort patchen, kein Abschalten nötig.
- Öffentlich erreichbarer Server, Update nicht kurzfristig möglich: Zugriff einschränken (zum Beispiel per Firewall nur für bekannte Adressen) oder den Dienst vorübergehend abschalten, besonders bei
mod_php. - Nur intern erreichbarer Server: zeitnah patchen, die Dringlichkeit ist geringer.
Häufige Fragen
Muss ich WordPress, Joomla oder Nextcloud aktualisieren?
Nicht wegen dieser Lücke. Sie liegt in PHP, nicht in der Anwendung. Aktualisieren Sie die PHP-Version auf dem Server. Ein Update der Anwendung ist unabhängig davon trotzdem sinnvoll.
Woran erkenne ich, ob jemand die Lücke bereits ausgenutzt hat?
Eine sichere Aussage ist schwer. Auffällig sind unbekannte PHP-Dateien im Webverzeichnis, ungewöhnliche Prozesse unter dem Webserver-Benutzer, neue Benutzerkonten oder Cronjobs und ungewöhnlicher ausgehender Datenverkehr. Bei einem konkreten Verdacht sollte das System forensisch geprüft und im Zweifel neu aufgesetzt werden.
Reicht eine Web Application Firewall?
Eine Firewall kann bekannte Angriffsmuster abfangen, ist aber kein Ersatz für das Update. Mehr zum Zusammenspiel mehrerer Schutzschichten lesen Sie in unserem Beitrag Odoo 19 absichern: Firewall, 2FA & Web RBL. Die Grundsätze gelten für jede Webanwendung.
Ist Odoo betroffen?
Nein. Odoo ist in Python geschrieben und läuft nicht auf PHP. Betroffen wären nur PHP-Anwendungen, die auf demselben Server laufen.
Wo finde ich die offiziellen Informationen?
Die Ankündigung des PHP-Sicherheitsteams finden Sie in den News-Archiven auf php.net (Eintrag vom 20. Oktober 2026), die Versionen unter php.net/downloads. Die Warnung des BSI trägt die Nummer 2026-297981-1032 und ist auf bsi.bund.de veröffentlicht.
Unterstützung durch Biricon IT Services
Wenn Sie nicht sicher sind, welche PHP-Version auf Ihrem Server läuft, oder Hilfe beim Patchen brauchen, unterstützen wir Sie gerne: bei der Bestandsaufnahme aller PHP-Systeme, beim Einspielen der Updates, beim Umstieg auf eine unterstützte PHP-Version und bei der Prüfung auf Kompromittierung. Als IT-Dienstleister betreuen wir Server, Firewalls und Webanwendungen für kleine und mittlere Unternehmen.
Stand: 21. Oktober 2026. Die Lage kann sich kurzfristig ändern; maßgeblich sind die Veröffentlichungen des PHP-Sicherheitsteams und des BSI.