PHP-Sicherheitslücken für WordPress

Am 21. Oktober 2026 hat das PHP-Projekt Sicherheitsupdates für zwei kritische Schwachstellen veröffentlicht. Unter dem Namen php2shell werden Fehler zusammengefasst, über die Angreifer unter bestimmten Bedingungen fremden Code auf einem Server ausführen können. Eine vorherige Anmeldung ist dafür nicht erforderlich. Das PHP-Projekt fordert Betreiber ausdrücklich zur sofortigen Aktualisierung auf.

Für Unternehmen stellt sich damit eine konkrete Frage: Läuft ihre Website tatsächlich mit einer korrigierten PHP-Version? Ein unauffälliges WordPress-Dashboard beantwortet diese Frage noch nicht. Die Sicherheit einer Website hängt auch von der Software ab, die außerhalb des Redaktionssystems arbeitet.

Der Fall zeigt außerdem, wie KI die Sicherheitsforschung verändert. Lange bestehende Fehler lassen sich mit ihrer Unterstützung genauer untersuchen und auf praktische Ausnutzbarkeit prüfen. Für den Betrieb Ihrer Website folgt daraus eine klare Aufgabe: Sicherheitsmeldungen müssen rechtzeitig bewertet und verfügbare Korrekturen zuverlässig eingespielt werden.

Die Schwachstellen tragen die Kennungen CVE-2026-109618 und CVE-2026-109619. Beide sind mit einem CVSS-4.0-Wert von 9,2 als kritisch eingestuft. Sie betreffen die interne Speicherverwaltung und die Verarbeitung von Fehlerzuständen in PHP.

Bei CVE-2026-109618 kann Speichermangel einen Vorgang unterbrechen, während interne Daten erst teilweise vorbereitet sind. Beim anschließenden Aufräumen verarbeitet PHP diese unvollständigen Daten unter Umständen so, als wären sie gültig. Daraus kann eine Ausführung eingeschleusten Codes entstehen.

CVE-2026-109619 betrifft interne Zustände, die noch auf Speicher einer bereits abgeschlossenen Anfrage verweisen. Dieser Speicher wurde inzwischen freigegeben. Bearbeitet derselbe PHP-Prozess eine weitere Anfrage, kann er auf den veralteten Zustand zugreifen. Auch dieser Fehler kann fremde Codeausführung ermöglichen.

Der Schadcode läuft dabei mit den Rechten des betroffenen Web-Prozesses. Welche Daten und Funktionen erreichbar sind, hängt von dessen Berechtigungen ab. Automatische Administratorrechte auf dem gesamten Server sind damit nicht verbunden. Bereits der Zugriff auf Anwendungsdaten oder Zugangsinformationen kann jedoch erheblichen Schaden verursachen.

Die offizielle Warnung umfasst PHP-Installationen, die Webanfragen verarbeiten. Sie nennt unter anderem PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Betreiber sollten deshalb alle entsprechenden Umgebungen prüfen.

Bei Apache mit mod_php ist ein besonders kritischer Angriffsweg dokumentiert: Die Verarbeitung kann bereits betroffen sein, bevor der eigentliche Anwendungscode startet. Eine Sicherheitsprüfung innerhalb der Website kommt für diesen Ablauf zu spät.

Wie sich ein konkreter Angriff ausführen lässt, hängt von Version, Konfiguration und Anwendung ab. Daraus lässt sich jedoch keine pauschale Entwarnung für andere Betriebsarten ableiten. Auch für PHP-FPM bestätigt das zweite Advisory einen erfolgreichen Angriffspfad.

Die folgenden Sicherheitsversionen vom 21. Oktober 2026 beheben beide Schwachstellen.

Entscheidend ist der vollständige Versionsstand. Die Angabe „PHP 8.4“ reicht für eine Sicherheitsbewertung nicht aus.

Bei Paketen von Linux-Distributionen oder spezialisierten Hosting-Anbietern können Sicherheitskorrekturen in ältere Paketstände zurückportiert worden sein. Dann ist die sichtbare PHP-Versionsnummer allein nicht aussagekräftig. Lassen Sie sich vom Anbieter bestätigen, dass beide CVEs im tatsächlich eingesetzten Paket behoben sind.

PHP 8.1 und ältere Zweige erhalten vom PHP-Projekt keine regulären Sicherheitsupdates mehr. Für diesen außergewöhnlichen Fall wurden zwar minimale Quellcodekorrekturen für PHP 7.4, 8.0 und 8.1 bereitgestellt. Ein regulärer Support entsteht dadurch nicht wieder. Auch für PHP 8.2 endet die Sicherheitsunterstützung bereits am 31. Dezember 2026.

Für Ihre Planung bedeutet das: Zuerst müssen beide Sicherheitskorrekturen nachweislich installiert sein. Läuft die Website auf einem auslaufenden oder bereits abgekündigten Zweig, gehört zusätzlich der Wechsel auf eine länger unterstützte Version auf den Terminplan.

WordPress verwendet PHP zur serverseitigen Verarbeitung. Das Content-Management-System und seine Laufzeit werden jedoch auf unterschiedlichen Ebenen gepflegt. WordPress, Themes und Plugins aktualisieren Sie innerhalb der Anwendung oder über deren Verwaltungswerkzeuge. Die verfügbare PHP-Version wird durch die Hosting-Umgebung bestimmt und dort geändert.

Diese Trennung hat praktische Folgen. Sämtliche Plugins können aktuell sein, während der Server weiterhin eine verwundbare PHP-Version verwendet. Ebenso kann PHP auf dem neuesten Sicherheitsstand laufen, obwohl eine veraltete Erweiterung eine andere Schwachstelle enthält. Für eine verlässliche Betreuung müssen beide Ebenen erfasst werden.

Die Forscher von Wiz demonstrierten php2shell an WordPress-, Drupal– und Joomla-Installationen. Dabei lagen die untersuchten Fehler in PHP selbst. Ein entsprechender Programmierfehler im jeweiligen CMS war für diese Demonstrationen nicht erforderlich.

Das erklärt auch die Grenzen eines Sicherheitsplugins. Ein Schutzmechanismus, der erst innerhalb von WordPress ausgeführt wird, kann den dokumentierten Angriff vor Beginn des Anwendungscodes nicht abfangen. Diese Grenze ergibt sich unmittelbar aus dem im PHP-Advisory beschriebenen Ablauf.

Eine vorgeschaltete Web Application Firewall arbeitet an einer anderen Stelle und kann zusätzliche Angriffe abwehren. Sie ersetzt die Korrektur der PHP-Laufzeit trotzdem nicht. Cloudflare berichtete am 21. Oktober über beobachteten Angriffsverkehr und Versuche, Schutzregeln zu umgehen. Der Anbieter empfiehlt ausdrücklich, PHP auch bei aktivem Firewall-Schutz zu aktualisieren.

Bei php2shell wäre die Aussage zu einfach, eine KI habe aus dem Nichts zwei zuvor völlig unbekannte Probleme entdeckt. Die PHP Foundation beschreibt, dass erste Hinweise auf das Speicherproblem hinter CVE-2026-109618 bereits 2024 vorlagen. Das volle Gefahrenpotenzial wurde 2026 durch weitere Forschung von Calif, OpenAI und Wiz deutlich.

Wiz dokumentiert den Einsatz mehrerer KI-Systeme bei der Untersuchung, der Entwicklung von Angriffsnachweisen und der Überprüfung der Korrekturen. Die Unterstützung half auch dabei, komplexe Zusammenhänge zwischen Speicherverwaltung, Anfrageverarbeitung und unterschiedlichen Konfigurationen zu untersuchen.

Darin liegt eine wesentliche Veränderung: Ein Fehler, dessen praktische Ausnutzung bislang sehr aufwendig erschien, kann durch bessere Analysewerkzeuge neu bewertet werden. KI kann Forschenden helfen, Varianten zu finden, Annahmen zu überprüfen und technische Zusammenhänge schneller nachzuvollziehen.

Für Unternehmen ist daher die Annahme riskant, eine seit Jahren unveränderte Software sei allein durch ihren langen Einsatz ausreichend geprüft. Ein stabiler Betrieb sagt zunächst aus, dass die beobachteten Funktionen arbeiten. Eine vollständige Sicherheitsbewertung ersetzt er nicht.

Ein weiterer belegter Fall betrifft Firefox. Anthropic berichtete im März 2026, dass Claude innerhalb einer zweiwöchigen Zusammenarbeit mit Mozilla 22 Schwachstellen gefunden hatte. Mozilla stufte 14 davon mit hohem Schweregrad ein. Die offiziellen Firefox-Sicherheitsmeldungen nennen bei mehreren behobenen Fehlern ausdrücklich den Einsatz von Claude.

Damit gibt es konkrete Beispiele aus unterschiedlichen Softwareprojekten. Auch der Code von WordPress, seinen Erweiterungen und individuellen Webanwendungen kann Gegenstand KI-gestützter Sicherheitsanalysen sein. Daraus folgt jedoch keine Aussage darüber, dass jedes Produkt bereits erfolgreich angegriffen wurde oder jede automatisch erzeugte Meldung eine echte Sicherheitslücke beschreibt.

Die PHP Foundation berichtet zugleich von ungültigen, doppelten und nicht reproduzierbaren Meldungen. KI unterstützt dort die Prüfung. Die Entscheidungen über Befunde und Korrekturen treffen weiterhin Menschen.

Mehr gefundene Schwachstellen können die Sicherheit langfristig verbessern, wenn daraus belastbare Korrekturen entstehen. Für Betreiber beginnt die entscheidende Arbeit anschließend: Die Korrektur muss die laufenden Systeme erreichen.

Die technischen Möglichkeiten stehen grundsätzlich auch Angreifern zur Verfügung. Wiz beschreibt, wie KI den Aufwand reduzieren kann, komplexe Angriffe an unterschiedliche PHP-Versionen und Konfigurationen anzupassen.

Für Ihre Website leiten wir daraus eine betriebliche Konsequenz ab: Ein Wartungsprozess braucht einen Weg für dringende Sicherheitsmeldungen außerhalb des üblichen Aktualisierungsrhythmus. Wer ausschließlich auf den nächsten monatlichen Termin wartet, kann eine bereits verfügbare Korrektur unnötig lange ungenutzt lassen.

Gleichzeitig braucht jede Änderung eine verantwortliche Person. Automatische Benachrichtigungen helfen wenig, wenn niemand prüft, ob die Meldung die eigene Umgebung betrifft und ob das Update tatsächlich umgesetzt wurde.

Beginnen Sie bei der konkreten Website. In WordPress finden Sie die PHP-Version üblicherweise unter „Werkzeuge“, „Website-Zustand“, „Bericht“ und dort im Bereich „Server“. Halten Sie die vollständige Versionsnummer fest.

Weicht diese Anzeige von der Auswahl im Hosting-Portal ab, sollte der Anbieter die Zuordnung Ihrer Domain prüfen. Solche Abweichungen sind in WordPress-Supportfällen dokumentiert. Maßgeblich ist die Laufzeit, mit der die betreffende Website tatsächlich arbeitet.

Beziehen Sie auch weitere Installationen ein, etwa öffentlich erreichbare Testsysteme, Subdomains und ältere Projektkopien. Bei Container-Umgebungen müssen zudem die verwendeten Images und die Bereitstellung berücksichtigt werden. Google fordert in seinen Hinweisen zu php2shell ausdrücklich, Serverumgebungen, Container-Images und Bereitstellungsprozesse zu aktualisieren.

Vor einer Änderung benötigen Sie eine verwendbare Sicherung. Zu einer vollständigen WordPress-Sicherung gehören die Dateien und die Datenbank. Das WordPress-Handbuch empfiehlt regelmäßige Backups sowie eine Sicherung vor Aktualisierungen. Kopien sollten an getrennten Orten liegen.

Für die praktische Umsetzung empfehlen wir, den Wiederherstellungsweg vorab zu klären. Wer kann eine Sicherung einspielen? Sind die erforderlichen Zugänge verfügbar? Welche seit dem Backup eingegangenen Bestellungen oder Anfragen müssten berücksichtigt werden?

Anschließend sollten Sie das passende Sicherheitsupdate mit dem Hosting-Anbieter oder Ihrer technischen Betreuung umsetzen. Ein Wechsel auf einen ganz anderen PHP-Zweig ist für die kurzfristige Behebung nicht grundsätzlich erforderlich, wenn für den vorhandenen, unterstützten Zweig bereits eine korrigierte Version verfügbar ist.

Prüfen Sie die Funktionen, von denen Ihr Geschäft abhängt. Dazu zählen beispielsweise Anmeldung, Kontaktformular, Suche, Datei-Uploads und bei einem Shop der Bestellprozess. Diese gezielte Kontrolle sollte Bestandteil des dringenden Updates sein. Eine umfangreichere technische Modernisierung lässt sich gesondert planen.

Eine erfolgreiche Installation ist noch kein vollständiger Nachweis für den Zustand aller Systeme. Lassen Sie prüfen, ob die produktive Website die aktualisierte Laufzeit verwendet und ob erforderliche Neustarts oder neue Bereitstellungen erfolgt sind.

Bei selbst verwalteten Containern kann es notwendig sein, das Image neu zu bauen und die Anwendung damit erneut bereitzustellen. Google nennt diesen Schritt in seinen Hinweisen ausdrücklich. Ein korrigiertes Basis-Image behebt keinen unverändert weiterlaufenden Container.

Für die Betriebsdokumentation empfehlen wir, Version beziehungsweise Paketstand, Zeitpunkt und Ergebnis der Funktionsprüfung festzuhalten. So können Sie später nachvollziehen, welche Umgebung wann korrigiert wurde.

Die Dringlichkeit ergibt sich auch aus den von Cloudflare gemeldeten Angriffsversuchen. Diese Beobachtungen sind kein Beleg dafür, dass Ihre Website kompromittiert wurde. Sie sprechen aber dafür, die Umsetzung nicht aufzuschieben.

Falls es bereits Hinweise auf unbefugte Änderungen gibt, sollte die technische Betreuung zusätzlich eine Untersuchung veranlassen. Das Schließen einer Schwachstelle und das Bereinigen eines möglicherweise bereits veränderten Systems sind unterschiedliche Aufgaben. Eine neue Versionsnummer allein beantwortet die Frage nach einem früheren Zugriff nicht.

Bei der Sodah Online Marketing Agentur arbeiten zehn Personen. Fünf davon sind spezialisierte Entwickler aus den Bereichen Full-Stack, Frontend und Backend. Diese Zusammensetzung ermöglicht uns, Sicherheits- und Kompatibilitätsfragen bis in den Code und die zugrunde liegenden Systeme zu verfolgen.

Gerade bei einem PHP-Update ist das relevant. Zeigt eine Website anschließend einen Fehler, muss dessen Ursache eingegrenzt werden: Betrifft er eine Erweiterung, individuellen Anwendungscode oder die Serverkonfiguration? Welche Abhängigkeit verhindert den Wechsel? Welche Anpassung ist erforderlich, damit die Anwendung mit dem Sicherheitsupdate zuverlässig weiterläuft?

Ein Beispiel verdeutlicht den Nutzen. Wenn ein individuell entwickeltes Formular nach einer Laufzeitumstellung keine Anfragen mehr verarbeitet, braucht es eine Prüfung des betroffenen Codes und der Fehlerprotokolle. Eine weiterhin erreichbare Startseite wäre hier kein ausreichendes Erfolgskriterium.

Unser technischer Blick verbindet sich dabei mit dem Zweck Ihrer Website. Ein Kontaktformular muss Anfragen zustellen. Ein Buchungsprozess muss abschließbar bleiben. Der Umfang der Funktionsprüfung sollte sich deshalb an den Abläufen orientieren, auf die Ihr Unternehmen angewiesen ist.

Aus diesem Grund bieten wir unseren Kunden Service- und Wartungsverträge an. Sie schaffen einen vereinbarten Rahmen für wiederkehrende technische Aufgaben und die Abstimmung bei Handlungsbedarf.

Unsere Leistungen für umfassen unter anderem Aktualisierungen von WordPress, Themes und Plugins mit Kompatibilitätsprüfung, externe Datensicherungen, die Überwachung und Aktualisierung von PHP-Versionen sowie Sicherheitskontrollen. Hinzu kommen die Überwachung der Erreichbarkeit und stichprobenartige Prüfungen wichtiger Funktionen wie Anfrageformulare.

Für eine wirksame Betreuung sollte konkret vereinbart sein, wer neue Sicherheitsmeldungen bewertet, wer notwendige Änderungen mit dem Hoster abstimmt und wie dringende Fälle bearbeitet werden. Ebenso sollten Sie wissen, welche Systeme und Funktionen vom vereinbarten Leistungsumfang erfasst werden.

Der wirtschaftliche Nutzen liegt auch in dieser Vorbereitung. Wenn Versionen, Zuständigkeiten und Wiederherstellungswege bekannt sind, müssen sie bei einer kritischen Meldung nicht erst unter Zeitdruck zusammengesucht werden.

Falls Sie den PHP-Sicherheitsstand Ihrer Website aktuell nicht verlässlich benennen können, ist eine technische Bestandsaufnahme der nächste sinnvolle Schritt. Auf dieser Grundlage lässt sich festlegen, welche Korrekturen sofort erforderlich sind und wie die laufende Betreuung organisiert werden sollte.