PHP-Schwachstellen im Oktober 2026: was jetzt zu tun ist

Stand: 21. Oktober 2026, 16 Uhr (Patches veröffentlicht). Dieser Abschnitt fasst zusammen, was zur PHP-Schwachstelle bekannt ist, und ordnet die nötigen Schritte in das Patch- und Änderungsmanagement nach IT-Grundschutz ein.

Was über die PHP-Schwachstelle bekannt ist

Das PHP-Sicherheitsteam hat am 20. Oktober 2026 eine außerplanmäßige Sicherheitsveröffentlichung angekündigt. Sie behebt zwei kritische Schwachstellen, beide bewertet mit CVSS v4.0 9,2. Die Veröffentlichung ist für Mittwoch, 21. Oktober 2026, 14:00 Uhr UTC geplant, also 16:00 Uhr deutscher Zeit. Das Team behält sich vor, früher zu veröffentlichen, falls Details bekannt werden oder Angriffe beobachtet werden.

Das BSI führt die Schwachstellen in seiner Cybersicherheitswarnung vom 21. Oktober 2026 unter CVE-2026-109618 und CVE-2026-109619. Laut BSI könnten Angreifer aus der Ferne Code auf Webservern mit PHP-Anwendungen ausführen; nach der CVSS-Bewertung braucht es dafür weder Anmeldung noch eine Handlung von Nutzern. Bestätigte Ausnutzungen sind dem BSI bisher nicht bekannt, es gibt unbestätigte Berichte über existierende Exploits.

Die Korrektur: diese Versionen schließen die Lücken

Am 21. Oktober 2026 um 13:38 Uhr UTC hat das PHP-Team PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Laut den Sicherheitshinweisen betrifft CVE-2026-109618 die Behandlung von Speichermangel (Out-of-Memory) und CVE-2026-109619 internen Zustand, der eine Anfrage überlebt und von der nächsten Anfrage desselben Prozesses verwendet werden kann.

Betroffen sind alle PHP-Installationen, die Webanfragen bedienen: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht das PHP-Team bei mod_php; dafür gibt es einen vorgeführten Exploit, bei dem eine Anfrage ohne Anmeldung den Angriff auslöst, bevor Anwendungscode läuft.

PHP 8.1 und älter erhalten vom PHP-Projekt keine Updates mehr. Einige Distributionen und LTS-Anbieter liefern zurückportierte Korrekturen; das PHP-Team hat für 7.4, 8.0 und 8.1 nur Quellcode-Backports bereitgestellt. Praktisch heißt das: auf eine unterstützte Version umstellen. PHP 8.2 erhält nur noch bis 31. Dezember 2026 Sicherheitsupdates.

Wer betroffen sein kann

Betroffen sind potenziell alle Systeme, auf denen PHP Anfragen aus dem Internet verarbeitet:

• Websites und Shops mit WordPress, TYPO3, Joomla, Drupal, Magento oder Shopware
• selbst betriebene Anwendungen wie Nextcloud, Ticket- oder Warenwirtschaftssysteme mit Weboberfläche
• Appliances, deren Verwaltungsoberfläche PHP nutzt, etwa Firewalls auf Basis von pfSense oder OPNsense
• eigene Entwicklungen und Kundenportale

Bei gemietetem Webspace oder Managed Hosting spielt in der Regel der Anbieter PHP ein. Bei eigenen Servern, virtuellen Servern und Containern liegt die Aktualisierung bei Ihnen.

Übergangsschutz, bis das Update läuft

Das PHP-Team nennt Einstellungen, die bekannte Angriffswege verkleinern, aber ausdrücklich keinen vollständigen Schutz bieten. Sie müssen in der Server-Konfiguration gesetzt werden (php.ini, FPM-Pool bzw. php_admin_value), nicht per ini_set() oder .user.ini, und alle PHP-Prozesse müssen danach neu starten:

• memory_limit = -1 (Speicher stattdessen über Container- bzw. cgroup-Grenzen deckeln, nicht über RLIMIT_AS/RLIMIT_DATA)
• post_max_size = 8M, bei Uploads 32M, und upload_max_filesize darunter
• session.upload_progress.enabled = 0
• nur PHP 8.5: fatal_error_backtraces = 0

Sofortmaßnahmen

Bestand klären

Erstellen Sie eine kurze Liste aller Systeme mit PHP, die aus dem Internet erreichbar sind: Hostname, Anwendung, Betreiber, PHP-Version (php -v oder Anzeige im Hosting-Panel), Ansprechpartner. Im IT-Grundschutz entspricht das der Strukturanalyse; für den Ernstfall reicht eine Tabelle.

Angriffsfläche verkleinern

• Nicht benötigte PHP-Anwendungen, Test- und Altinstallationen abschalten.
• Verwaltungsoberflächen (z. B. /wp-admin, Firewall-Oberflächen) nicht offen ins Internet stellen, sondern auf bekannte IP-Adressen oder VPN beschränken.
• Eine Web Application Firewall bzw. vorhandene Filterregeln aktiv halten. Sie ersetzt den Patch nicht, kann aber bekannte Angriffsmuster abfangen, sobald Regeln vorliegen.

Abwägen: vorübergehend vom Netz

Die Allianz für Cyber-Sicherheit (ACS) berichtet, dass große IT-Dienstleister Webserver bis zum Patch vorübergehend vom Netz nehmen. Ob das sinnvoll ist, hängt vom Schutzbedarf ab: Ein Kundenportal mit personenbezogenen Daten wiegt anders als eine reine Informationsseite. Treffen Sie die Entscheidung bewusst und dokumentieren Sie sie kurz.

Datensicherung prüfen

Stellen Sie sicher, dass von jedem betroffenen System eine aktuelle, getrennt gespeicherte Sicherung existiert und die Wiederherstellung funktioniert. Das hilft beim Update ebenso wie im Fall einer Kompromittierung.

Nach der Veröffentlichung: Patch einspielen

1. Hinweise des PHP-Teams lesen: betroffene und korrigierte Versionen.
2. PHP über die üblichen Wege aktualisieren: Paketquellen der Distribution, Docker-Images (neues Image ziehen und Container neu erstellen) oder Hosting-Panel. Distributionen liefern Korrekturen teils mit Verzögerung oder als Backport mit eigener Versionsnummer.
3. Dienste neu starten (PHP-FPM, Webserver), damit die neue Version tatsächlich läuft, und die Version prüfen.
4. Anwendung kurz testen: Startseite, Anmeldung, Formulare.
5. Ausnahmen festhalten: Systeme, die nicht sofort aktualisiert werden können, mit Begründung, Ersatzmaßnahme und Termin.

Auf Spuren eines Angriffs achten

Weil Angriffswerkzeuge vor dem Patch kursieren könnten, lohnt nach dem Update ein Blick auf Auffälligkeiten: neue oder veränderte PHP-Dateien in Upload-Verzeichnissen, unbekannte Administratorkonten, ungewöhnliche ausgehende Verbindungen, Spam-Versand vom Webserver. Bei einem begründeten Verdacht gelten die Regeln Ihres IT-Notfallplans: System isolieren, Spuren sichern, Meldepflichten prüfen.

Einordnung in den IT-Grundschutz

Der Fall zeigt, warum ein geregeltes Patch- und Änderungsmanagement zur Basis-Absicherung gehört. Wer weiß, welche Systeme PHP nutzen, wer für sie zuständig ist und wie schnell sich Updates einspielen lassen, kann an Tagen wie heute in Stunden statt in Tagen reagieren. Prüfen Sie nach dem Vorfall, was gefehlt hat, und ergänzen Sie Ihr Verfahren.