PHP-Sicherheitslücken CVE-2026-109618 und CVE-2026-109619: was Website-Betreiber jetzt tun sollten

Am 21. Oktober 2026 um 16 Uhr Schweizer Zeit hat das PHP-Projekt die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Sie schliessen zwei kritische Sicherheitslücken, CVE-2026-109618 und CVE-2026-109619, über die Angreifer unter bestimmten Bedingungen ohne Anmeldung und ohne Nutzerinteraktion Code auf einem Webserver ausführen können. Am selben Tag haben das deutsche BSI und das Bundesamt für Cybersicherheit (BACS) gewarnt; das BACS empfiehlt, die Sicherheitsupdates sofort einzuspielen.

Auf PHP laufen WordPress, Joomla, Drupal, Magento, Laravel- und Symfony-Anwendungen sowie sehr viele Onlineshops und Business-Anwendungen. Wenn Ihre Website eines dieser Systeme nutzt, sind Sie betroffen. Hier finden Sie die geprüften Fakten, die richtigen Versionen und eine praktische Checkliste.

Was passiert ist

Laut dem Sicherheitshinweis auf php.net liegen beide Lücken im Kern von PHP, in der Speicher- und Fehlerverwaltung, also in Teilen, die fast jede Anfrage durchläuft:

• CVE-2026-109618: Läuft eine Anfrage im falschen Moment in das Speicherlimit, kann PHP interne Daten nur teilweise initialisiert zurücklassen und später als gültig behandeln. Dadurch wird Speicher beschädigt.
• CVE-2026-109619: Ein anfragebezogener interner Zustand kann bestehen bleiben, nachdem der zugehörige Speicher freigegeben wurde; eine spätere Anfrage im selben Worker-Prozess kann ihn wiederverwenden.

Beide Lücken haben einen CVSS-4.0-Wert von 9,2 von 10 und gelten als kritisch. Der vor der Veröffentlichung in sozialen Medien verbreitete Wert von 10.0 war falsch, wie die PHP Foundation klarstellt. In Medienberichten heissen die Lücken auch «PHP2Shell», in Anlehnung an Log4Shell aus dem Jahr 2021.

Gemeldet wurden die Lücken von den Sicherheitsfirmen Calif und Wiz sowie von OpenAI. Geplant war die Veröffentlichung für den 22. Oktober; weil die CVE-Nummern am 20. Oktober online kursierten, zog das PHP-Projekt den Termin um einen Tag vor.

Wer betroffen ist

Laut php.net ist jede PHP-Installation gefährdet, die Webanfragen verarbeitet: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten ist das Risiko bei Apache mit mod_php: Dort wurde ein Angriff demonstriert, bei dem eine nicht authentifizierte Anfrage die Lücke auslöst, bevor überhaupt Anwendungscode läuft. Verwundbar sind die Versionen 5.4 bis 8.5.11; das BSI spricht von allen bekannten Versionen bis mindestens PHP 5 zurück und führt die Warnung mit der Kritikalitätsstufe «sehr hoch».

Das BACS betont, dass die Prüfung nicht bei öffentlichen Websites aufhören darf: PHP steckt auch in Administrationsoberflächen, internen Fachanwendungen, Hosting-Plattformen, Containern und Appliances, manchmal ohne dass die Betreiber es wissen.

Die Bedrohungslage

Zum Zeitpunkt der Veröffentlichung waren keine bestätigten Ausnutzungen bekannt. Das BSI erwähnte jedoch unbestätigte Berichte über existierende Exploits, und das kanadische Cyber Centre berichtet, dass ein Proof of Concept verfügbar ist. Laut BBC sagte der Technikchef von Cloudflare, er sehe erste Angriffe.

Mehrere Behörden haben ihre Websites vorsorglich vom Netz genommen, bis die Patches installiert waren: in Baden-Württemberg etwa die Landesregierung und mehrere Universitäten (tagesschau), laut BBC auch die öffentlichen Webdienste der finnischen Regierung. Laut dem Innenministerium Baden-Württemberg war das keine Reaktion auf einen erfolgreichen Angriff, sondern eine reine Sicherheitsmassnahme.

Die richtigen Versionen

• PHP 8.5: Version 8.5.12
• PHP 8.4: Version 8.4.27
• PHP 8.3: Version 8.3.36
• PHP 8.2: Version 8.2.35 (Supportende am 31. Dezember 2026)

PHP 8.1, 8.0, 7.x und älter erhalten keine offiziellen Updates mehr. Das PHP-Sicherheitsteam hat minimale Quellcode-Backports für 7.4, 8.0 und 8.1 veröffentlicht, und einige Linux-Distributionen liefern korrigierte Pakete. Empfohlen ist aber der Wechsel auf eine unterstützte Version.

Achtung bei der Versionsnummer auf Linux-Servern: Distributionen spielen den Fix oft in ihre eigene Paketversion ein. Unter Ubuntu 24.04 ist das korrigierte Paket zum Beispiel 8.3.6-0ubuntu0.24.04.13 (USN-8948-1), unter Debian 13 8.4.27-1~deb13u1 (DSA-6574-1). Massgeblich ist die genaue Paketversion des Anbieters, nicht nur die Nummer, die PHP anzeigt.

Was jetzt zu tun ist

Mit Managed Hosting

Liegt die Website auf einem Shared- oder Managed-Hosting, ist das PHP-Update Sache des Anbieters. Lassen Sie sich schriftlich bestätigen, dass der Fix installiert ist, wie es auch das BACS empfiehlt. Prüfen Sie im Control Panel, welche PHP-Version Ihre Website nutzt: Ist es 8.1 oder älter, planen Sie jetzt den Wechsel auf 8.3 oder 8.4 und testen Sie ihn zuerst an einer Kopie der Website.

Mit VPS oder eigenem Server

1. Erstellen Sie ein Backup oder einen Snapshot des Servers, inklusive Datenbanken und hochgeladener Dateien.
2. Aktualisieren Sie die PHP-Pakete über die Paketverwaltung der Distribution (unter Debian und Ubuntu: apt update und Upgrade der PHP-Pakete).
3. Starten Sie PHP-FPM und den Webserver neu: Ohne Neustart nutzen laufende Prozesse weiterhin den alten Code.
4. Prüfen Sie die tatsächlich verwendete Version mit php -v und der Paketversion, auch für den Prozess, der die Website ausliefert.
5. Bauen Sie Docker-Images mit PHP neu und rollen Sie sie neu aus.
6. Prüfen Sie die Logs auf ungewöhnliche Anfragen, Abstürze, veränderte Dateien und unerwartete Prozesse: Ein Update behebt keine bereits erfolgte Kompromittierung.

Eine zusätzliche gute Praxis: expose_php = Off setzen, damit der Server seine PHP-Version nicht in den HTTP-Headern verrät. Das schützt nicht vor der Lücke, gibt aber weniger Hinweise an alle, die nach ungepatchten Servern suchen.

Wenn Sie nicht sofort aktualisieren können

php.net nennt einige Übergangsmassnahmen, zum Beispiel session.upload_progress.enabled=0 und einen niedrigen Wert für post_max_size. Sie verkleinern nur einzelne Angriffswege und machen eine Installation nicht sicher. Laut BACS reicht auch eine Web Application Firewall allein nicht aus. Bei kritischen Anwendungen ist eine vorübergehende Trennung vom Internet zu prüfen.

Checkliste

1. Erfassen Sie alle Websites, Onlineshops, Business-Anwendungen und Panels, die PHP nutzen.
2. Notieren Sie zu jeder, wer sie betreibt und welche PHP-Version sie nutzt.
3. Lassen Sie sich vom Hosting-Anbieter bestätigen, dass der Fix installiert ist.
4. Auf eigenen Servern: Backup, Update, Neustart der Dienste, Versionsprüfung.
5. Planen Sie den Wechsel von PHP 8.1 oder älter auf eine unterstützte Version.
6. Aktualisieren Sie auch CMS, Themes und Plugins, das ist ein eigenes Thema.
7. Behalten Sie Logs und Dateien der Website in den nächsten Tagen im Blick.

Häufige Fragen

Ist meine WordPress-Website gefährdet?

WordPress läuft mit PHP, also ja, wenn der Server eine ungepatchte PHP-Version nutzt. Das Problem liegt nicht in WordPress, sondern in der Sprache darunter: WordPress und Plugins zu aktualisieren ist sinnvoll, ersetzt aber das PHP-Update nicht.

Wie finde ich heraus, welche PHP-Version meine Website nutzt?

Im Control Panel des Hostings, meist im Bereich PHP oder in den Einstellungen der Website. In WordPress unter Werkzeuge, Website-Zustand, Bericht, Server. Auf dem eigenen Server mit php -v und der installierten Paketversion.

Meine Website läuft noch mit PHP 7.4: was tun?

PHP 7.4 erhält keine offiziellen Updates mehr. Die minimalen Backports für 7.4 sind für alle gedacht, die PHP selbst kompilieren oder keinen Anbieter mit erweitertem Support haben. Für eine Firmenwebsite ist die Migration auf PHP 8.3 oder 8.4 der richtige Weg, vorher an einer Kopie getestet.

Reicht eine Firewall oder ein Dienst wie Cloudflare?

Nein. Sie können einzelne bekannte Angriffe filtern, aber das BACS hält fest, dass eine Web Application Firewall allein nicht genügt. Die einzige vollständige Lösung ist das Update.

Kann das Update meine Website lahmlegen?

Ein Update innerhalb desselben Zweigs, zum Beispiel von 8.3.35 auf 8.3.36, ist ein Sicherheitsrelease und ändert das Verhalten normalerweise nicht. Ein Wechsel auf einen neuen Zweig, etwa von 7.4 auf 8.3, sollte dagegen zuerst an einer Kopie getestet werden, weil alte Themes, Plugins oder alter Code inkompatibel sein können.

Ich habe aktualisiert: muss ich noch etwas tun?

Starten Sie die PHP-Dienste neu, prüfen Sie die verwendete Version und sehen Sie sich die Logs an. Wenn Sie veränderte Dateien, unbekannte Administratoren oder seltsame Prozesse bemerken, behandeln Sie den Server als kompromittiert.

Unser Ansatz

ElaraTeq Sagl betreut Websites und Anwendungen für KMU und öffentliche Stellen im Tessin mit Hosting in der Schweiz. Wir prüfen, welche PHP-Version Ihre Website nutzt, spielen den Fix ein oder planen die Migration weg von einer nicht mehr unterstützten Version. Für die laufende Wartung gibt es den in Orbit beschriebenen Service; für eine Prüfung schreiben Sie uns.

Quellen

• PHP, «Security advisory: Critical remote code execution vulnerabilities, update now», 21. Oktober 2026: php.net
• PHP, GitHub-Advisories GHSA-w8hw-w9fx-j79w (CVE-2026-109618) und GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• The PHP Foundation, «Today's PHP Security Release», 21. Oktober 2026: thephp.foundation
• BACS, «Kritische Schwachstellen in PHP: Sicherheitsupdates sofort einspielen», 21. Oktober 2026: bacs.admin.ch
• BSI, «PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit», 21. Oktober 2026: bsi.bund.de
• Ubuntu, USN-8948-1; Debian, DSA-6574-1
• Canadian Centre for Cyber Security, AL26-026
• tagesschau/SWR, 21. Oktober 2026: Unis und Landesregierung nahmen Websites zeitweise vom Netz; BBC, 21. Oktober 2026: Websites taken down worldwide