PHP2Shell: Das PHP-Update ist da, doch WordPress-Seiten müssen auf ihren Hoster warten

Der Patch für PHP2Shell ist da – doch für die meisten betroffenen Websites gibt es keinen Knopf, den man einfach drücken könnte. Die Sicherheitslücken stecken in PHP selbst, der Engine, auf der jede WordPress-, Joomla- und Drupal-Seite läuft – unterhalb des CMS, seiner Plugins und seines Login-Bildschirms. Ein WordPress-Update ändert daran nichts. Die gepatchte Laufzeitumgebung muss von demjenigen kommen, der den Server betreibt: vom Hosting-Anbieter, über das Paket der Linux-Distribution oder als Container-Image. Bis das geschieht, muss die Website warten – ganz gleich, was ihr Betreiber unternimmt.

Genau diesen Teil der Geschichte lassen die Schlagzeilen nach dem Motto „Jetzt patchen“ aus. Das PHP-Team hat seine Arbeit erledigt. Ob sie auf einem bestimmten Server ankommt, hängt von einer Lieferkette ab, deren Tempo vom langsamsten Glied bestimmt wird. Schon am ersten Tag zeigte sich, wie weit die einzelnen Glieder auseinanderliegen. Wer nicht weiß, woher das eigene PHP stammt, kann nicht beurteilen, wie stark die Website weiterhin gefährdet ist.

Warum ein WordPress-Update das Problem nicht behebt

Da die Fehler in der Laufzeitumgebung liegen, betrifft der PHP-Hinweis jede Installation, die Webanfragen verarbeitet – von PHP-FPM und Apache mit mod_php bis hin zu php-cgi, FrankenPHP und LiteSpeed. Wie The Hacker News anmerkt, lässt sich sogar eine einfache „Hello World“-Seite mit einer verwundbaren Version angreifen. Am schlimmsten ist die Lage bei mod_php: Eine einzige Anfrage von jemandem ohne Benutzerkonto kann den Angriff auslösen, noch bevor Anwendungscode ausgeführt wird. Kein Sicherheits-Plugin und kein Login-Bildschirm bekommt davon etwas mit.

LeseempfehlungEin Login-Fehler ließ 70 Millionen cPanel-Webseiten für jedermann offen stehen

Wordfence, der Anbieter von Sicherheitslösungen für WordPress, teilte Website-Betreibern laut einem Bericht von The Verge mit, dass der Patch nicht über automatische Updates eingespielt werden könne. Sie müssten herausfinden, wer für ihr PHP zuständig ist. Laravel Forge sagte seinen Kunden dasselbe über die eigenen Server: Die automatischen Sicherheitsupdates des Dienstes patchen PHP nicht. Auch Ubuntus unbeaufsichtigte Aktualisierungen greifen nur auf Ubuntus eigenes Repository zu – nicht auf die Pakete von Drittanbietern, über die Forge PHP installiert.

Die Paketquellen wurden nicht gleichzeitig aktualisiert. Am Tag der Veröffentlichung meldete der Website-Verwaltungsdienst mySites.guru, dass cPanels EasyApache 4 innerhalb weniger Minuten nach den Hinweisen korrigierte Builds bereitgestellt hatte. Für das PPA von Ondřej Surý, auf das Laravel Forge selbst als Ubuntu-Paketquelle zurückgreift, und für Remis Repository gab es zu diesem Zeitpunkt noch keine. InMotion Hosting erklärte, seine Shared-Hosting- und WordPress-Server warteten auf Builds von CloudLinux. Unter den Live-Websites, die mySites.guru überwacht, meldeten um 13:52 UTC gerade einmal 0,08 Prozent eine gepatchte PHP-Version.

Die Versionsnummer kann in die Irre führen

Die Installation zu überprüfen ist nicht so einfach, wie nur eine Versionsnummer abzulesen. Ubuntu, Debian und Red Hat spielen Sicherheitskorrekturen zurück, ohne die Upstream-Versionsnummer zu ändern. Ein gepatchter Ubuntu-24.04-Server meldet deshalb weiterhin ein Paket der Version 8.3.6. The Hacker News empfiehlt unter Verweis auf Debian, im Änderungsprotokoll des Pakets nach der CVE zu suchen, statt sich auf die Versionsangabe zu verlassen. mySites.guru weist auf eine weitere Falle hin: Die PHP-Binärdatei, deren Version die Kommandozeile mit php -v ausgibt, ist häufig nicht diejenige, die die Seiten ausliefert. Entscheidend ist daher die Version, die von der Website selbst gemeldet wird.

Anschließend muss der Patch auch geladen werden. Sowohl der PHP-Sicherheitshinweis als auch Forge betonen, dass Apache, PHP-FPM und alle dauerhaft laufenden Worker neu gestartet werden müssen. Warteschlangen-Worker und ähnliche Hintergrundprozesse verwenden weiterhin die alte Laufzeitumgebung, bis sie neu gestartet werden – selbst wenn die gepatchten Dateien bereits auf der Festplatte liegen.

Wer keinen offiziellen Patch erhält

Die korrigierten Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Sie beheben CVE-2026-109618 und CVE-2026-109619, die beide nach CVSS v4.0 mit 9,2 bewertet wurden. Für PHP 8.1 und ältere Versionen gibt es vom PHP-Projekt nichts – abgesehen von minimalen Rückportierungen des Quellcodes für 7.4, 8.0 und 8.1, die sich an diejenigen richten, die PHP selbst kompilieren. Einige Anbieter schließen die Lücke: InMotion zufolge hat cPanel Korrekturen für seine Pakete der Versionen 7.4 bis 8.1 zurückportiert, und CloudLinux patcht alle von ihm ausgelieferten Versionen. Für CentOS 7 gibt es dagegen überhaupt keinen Patch.

Diese Gruppe veralteter Installationen ist nicht klein. Am Tag vor der Veröffentlichung liefen 22,7 Prozent der Live-Joomla- und WordPress-Websites, die mySites.guru überwacht, mit PHP 8.1 oder älter; 16,6 Prozent verwendeten noch PHP 7 oder eine frühere Version. Das Unternehmen führt einen Teil des Problems auf WordPress selbst zurück: Die Plattform empfiehlt zwar PHP 8.3, führt aber auch das längst ausgediente PHP 7.4 weiterhin als kompatibel auf. Für PHP 8.2 gibt es diesen Patch noch, doch der Sicherheitssupport für die Version endet am 31. Dezember 2026.

Was die Übergangslösung verhindert

Die vor der Veröffentlichung verbreitete Übergangslösung, session.upload_progress.enabled=0 zu setzen, ist wirksam, aber nur teilweise. PHP zufolge blockiert sie die bestätigten Angriffswege über Sitzungen bei CVE-2026-109619, nicht jedoch andere Varianten. Die Einstellung muss in der php.ini oder in der Server- beziehungsweise Pool-Konfiguration gesetzt werden; anschließend müssen alle Worker neu gestartet werden. Unter PHP 8.5 schließt fatal_error_backtraces=0 einen weiteren bestätigten Angriffsweg. CVE-2026-109618 wird von keiner der beiden Einstellungen erfasst. Dafür empfiehlt PHP ein nicht überschreibbares memory_limit=-1, einen niedrigen Wert für post_max_size sowie Begrenzungen der Anfragedaten am Webserver oder Proxy. PHP stellt ausdrücklich fest, dass es keine vollständigen Abwehrmaßnahmen gibt. InMotion weist darauf hin, dass WordPress, Joomla, Drupal, Magento und PrestaShop keinen Upload-Fortschritt verwenden. Wird die Funktion deaktiviert, geht für diese Systeme also nichts verloren.

Cloudflare aktivierte Firewall-Regeln für alle Tarife. Der Chief Technology Officer des Unternehmens, Dane Knecht, bezeichnete sie als Übergangslösung. Wie mySites.guru anmerkt, helfen die Regeln allerdings nur, wenn der dahinterliegende Server Zugriffe blockiert, die Cloudflare umgehen und direkt an seine IP-Adresse gerichtet sind.

Bisherige Angriffe

watchTowr zufolge registrierten die Honeypots des Unternehmens am Tag der Veröffentlichung Angriffsversuche auf beide Sicherheitslücken. Cloudflare beobachtete, dass Angreifer ihre Payloads veränderten, um die Regeln zu umgehen. Keine Quelle hat einen erfolgreichen Einbruch in einen konkreten Server bestätigt. Einige Betreiber gingen dennoch kein Risiko ein: The Hacker News berichtet, dass BambooHR seinen Dienst vorübergehend abschaltete und öffentliche Dienste in den Niederlanden, darunter DigiD, vorsorglich nicht erreichbar waren. Das CERT der EU und das britische National Cyber Security Centre rieten Organisationen, die nicht patchen können, dazu, exponierte Anwendungen zu isolieren oder vom Netz zu nehmen.

Entdeckt wurden die Sicherheitslücken von Wiz Research, Calif und dem Codex-Security-Team von OpenAI. Der PHP Foundation zufolge gab es bereits bei einer Prüfung im Jahr 2024 erste Hinweise auf die Speicherlücke. Eine Korrektur kam jedoch monatelang nicht voran – eine Verzögerung, die die Stiftung als „strukturelles Versagen“ bezeichnete. Die Forschenden sagen, dass KI-Modelle dabei halfen, aus den zehn Jahre alten Fehlern innerhalb von etwa einer Woche funktionierende Exploits zu machen.

Für diesen Patch brauchte PHP eine Sicherheitsprüfung, monatelangen Stillstand und ein Datenleck. Wer eine Website auf Shared Hosting betreibt, muss als letzten Schritt ein Support-Ticket eröffnen.

Schlagwörter: Cloudflare, PHP, PHP2Shell, Sicherheitslücken, WordPress

Ähnliche Beiträge

iOS 26.7.1 stopft die Lücke, über die eine präparierte Datei das iPhone übernehmen konnte

Linus Torvalds erklärt KI-generierten Kernel-Code zur neuen Normalität in Linux 7.1

Wie sich Schadcode über die Lieferkette in vertrauenswürdige Software einschleicht

Microsoft hat 570 Windows-Sicherheitslücken in einem Monat behoben. KI fand die meisten

TypeScript 7.0 ist 10-mal schneller — Vue, Svelte und Angular müssen warten

Ein eMudhra-Zertifikatsschlüssel war die Zahl 4, damit ließ sich jede Website fälschen