Das Bundesamt für Sicherheit in der Informationstechnik warnt vor zwei kritischen Schwachstellen in PHP. Angreifer können darüber unter bestimmten Bedingungen ohne Anmeldung eigenen Code auf einem Webserver ausführen. Für Website-Betreiber zählt jetzt vor allem eine Frage: Läuft die eigene Seite auf einer bereits gepatchten PHP-Version?

Das BSI veröffentlichte am 21. Oktober 2026 eine Warnung zu kritischen Schwachstellen in PHP. Die Warnung trägt das Aktenzeichen BITS-H Nr. 2026-297981-1032 und wurde mit Stufe 3 / Orange bewertet. Das Amt rief Betreiber dazu auf, die Sicherheitsupdates nach ihrer Veröffentlichung sofort einzuspielen und öffentlich erreichbare PHP-Server verstärkt auf Auffälligkeiten zu beobachten.
Die PHP-Entwickler benennen zwei Lücken: CVE-2026-109618 und CVE-2026-109619. Beide können eine Ausführung fremden Codes ohne vorherige Anmeldung ermöglichen. PHP schreibt ausdrücklich, dass nur ein Update die Lücken vollständig schließt. Veröffentlicht wurden PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35.
Wie ernst Behörden die Lage einschätzten, zeigte sich schnell: Laut WELT waren unter anderem Webangebote aus Rheinland-Pfalz, Hessen und dem Saarland vorübergehend offline. Auch Berlin.de war zeitweise nur eingeschränkt erreichbar.

PHP läuft im Hintergrund vieler Websites. Dazu zählen WordPress, Joomla, Typo3, Drupal und Moodle. Das Sicherheitsunternehmen Wiz schätzt laut WELT, dass rund 70 Prozent der Websites weltweit auf PHP basieren. Diese Zahl beschreibt die Verbreitung, nicht die Zahl bereits angegriffener Seiten.
Prüfen müssen alle, deren Webserver PHP-Anfragen verarbeitet. Das gilt für einen eigenen Server genauso wie für Shared Hosting oder einen Managed-WordPress-Tarif. Beim Hosting übernimmt der Anbieter häufig das PHP-Update. Sie sollten sich den Patchstand trotzdem bestätigen lassen, statt nur davon auszugehen.
Ein aktuelles WordPress- oder Plugin-Update ersetzt das PHP-Update nicht. Umgekehrt macht ein gepatchtes PHP veraltete Plugins oder ein unsicheres Admin-Passwort nicht harmlos. Die Ebenen müssen getrennt geprüft werden.
Der offizielle PHP-Hinweis nennt 8.5.12, 8.4.27, 8.3.36 und 8.2.35 als korrigierte Versionen. PHP 8.1 und ältere Reihen erhalten vom PHP-Projekt regulär keine Updates mehr. Einige Linux-Distributionen und Langzeit-Support-Anbieter liefern eigene rückportierte Patches. Deshalb reicht die sichtbare Versionsnummer allein bei solchen Paketen nicht immer als Nachweis.
Fragen Sie Ihren Hoster oder Administrator konkret, ob CVE-2026-109618 und CVE-2026-109619 behoben sind. Wenn die Seite auf einer alten PHP-Reihe läuft, braucht es entweder einen bestätigten Hersteller-Patch oder einen Wechsel auf eine unterstützte Version. Ein Upgrade sollte vorab in einer Testumgebung geprüft werden, damit Theme, Plugins und Formulare weiter funktionieren.
1. Hoster oder Agentur anschreiben: Fragen Sie nach dem installierten Sicherheitsupdate und nennen Sie beide CVE-Nummern. Lassen Sie sich nicht nur bestätigen, dass automatische Updates grundsätzlich aktiviert sind.
2. PHP-Version prüfen: Im Hosting-Menü, in der Systemdiagnose des CMS oder über den Administrator lässt sich feststellen, welche PHP-Reihe läuft. Veröffentlichen Sie keine phpinfo-Datei dauerhaft im Netz, weil sie unnötig viele Serverdetails offenlegt.
3. System vollständig aktualisieren: Neben PHP gehören das CMS, Erweiterungen und Themes auf einen unterstützten Stand. Erstellen Sie vorher ein funktionierendes Backup von Dateien und Datenbank und prüfen Sie, wie es wiederhergestellt wird.
4. Protokolle kontrollieren: Prüfen Sie Webserver-, PHP- und Anwendungsprotokolle auf ungewöhnliche Anfragen, neue Dateien, unbekannte Benutzer oder auffällige ausgehende Verbindungen. Bei einem Verdacht reicht ein Update allein nicht. Dann muss die mögliche Kompromittierung untersucht werden.
5. Zuständigkeit festhalten: Dokumentieren Sie, wer PHP, CMS und Plugins künftig aktualisiert. Bei Kundendaten sollten außerdem Zugriffe, Datenabflüsse und mögliche Meldepflichten mit der zuständigen Datenschutzberatung bewertet werden.
Eine statisch erzeugte Website aus React oder Next.js besteht im Betrieb aus HTML, CSS, JavaScript und Bildern. Wird sie über ein CDN oder eine Edge-Plattform wie Netlify oder Cloudflare ausgeliefert, läuft für den Seitenaufruf kein PHP-Interpreter. Die beiden aktuellen PHP-Lücken können dort deshalb nicht angreifen.
Das gilt nur, wenn im tatsächlichen System kein PHP-Dienst beteiligt ist. Eine React-Oberfläche kann weiterhin mit einer PHP-API, einem WordPress-Backend oder einem alten Formularskript verbunden sein. Diese Teile müssen separat geprüft werden. Auch Node.js, Next.js, CDN-Konfigurationen und Abhängigkeiten brauchen Sicherheitsupdates. Keine Technik ist immun. Dieser Stack ist lediglich von dieser konkreten PHP-Lücke nicht betroffen.
Warum wir für viele Projekte mit offenen React- und Next.js-Codebasen arbeiten, erklären wir im Insight zu React und Next.js. Die technische Entscheidung sollte trotzdem immer zur Aufgabe, zum Betrieb und zum Team passen.
Wenn Ihre Website WordPress oder ein anderes PHP-System nutzt, brauchen Sie heute eine belastbare Antwort zum Patchstand. Fragen Sie zuerst den Hoster oder die betreuende Agentur. Prüfen Sie danach Backup, Erweiterungen und Protokolle. Eine vorschnelle Panik hilft nicht, eine unbelegte Annahme aber auch nicht.
Bei einem Verdacht auf einen Angriff sollten Zugangsdaten nicht einfach nur geändert werden. Sichern Sie zunächst verwertbare Protokolle und ziehen Sie fachkundige Unterstützung hinzu. Falls personenbezogene Daten betroffen sein könnten, gehört die datenschutzrechtliche Bewertung direkt in den Ablauf.
Wir prüfen den technischen Aufbau, den Patchstand und die nächsten sinnvollen Schritte Ihrer Website. Sie erhalten eine klare Einschätzung zum Handlungsbedarf.
Weiterführend: Webdesign Hamburg.