In der Fehler- und der Speicherverwaltung der Webskriptsprache PHP verbargen sich kritische Sicherheitsfehler, die zur Ausführung von Schadcode auf Millionen Webservern weltweit taugen. Alle PHP-Versionen der letzten Jahrzehnte sind betroffen, selbst das längst veraltete PHP 5. Wer einen Webserver mit der offenen Skriptsprache betreibt, sollte diesen schleunigst aktualisieren.

Die erste der beiden Schwachstellen mit dem gemeinsamen Namen php2shell ist CVE-2026-109618 (CVSS 9.2, kritisch). Sie lauert in der Speicherverwaltung der Skriptsprache. Sie ist ausnutzbar, wenn einige Vorbedingungen erfüllt sind und das in der PHP-Konfigurationsdatei eingestellte Speicherlimit (Direktive: memory_limit) anschlägt. Dann erzeugt die Sprache einen Ausführungsfehler – und sollte eigentlich alle Überbleibsel des fehlerhaft ausgeführten Skripts im Speicher wegräumen.

Ist jenes jedoch über ein vom Angreifer passend zurechtgebasteltes Upload-Formular oder eines mit besonders geschickt verschachtelten Arrays gestolpert, kommt PHP beim Aufräumen dieser Überreste aus dem Tritt. Das Resultat: Angreifer können Speicher auslesen, freigeben und eigenen Schadcode im Nutzerkontext des Webservers ausführen.

Ein zweiter Fehler fand sich im Error-Handling, also der Verarbeitung von Skriptfehlern. Um CVE-2026-109619 (CVSS 9.2, kritisch) erfolgreich auszunutzen, benötigt ein Angreifer neben ähnlichen Vorbedingungen wie bei CVE-2026-109618 mindestens zwei HTTP-Anfragen. Die erste erzeugt einen instabilen Zustand in PHPs Fehlerverwaltung, die zweite nutzt diesen aus. Dabei sind jedoch nicht alle „fatal errors“, also Fehler, die zum Skriptabbruch führen, ausnutzbar.

Beide Exploits sind nicht beim ersten oder zweiten Versuch erfolgreich, sondern benötigen mitunter mehrere Tausend Anfragen, bis sie eine der Schwachstellen auslösen. In einem kurzen Video zeigen die Entdecker von Calif, wie sie per php2shell nach 38 Sekunden Systemkommandos auf einem Webserver mit dem PHP-Framework Laravel ausführen.

Angriffe sind grundsätzlich ohne vorherige Anmeldung möglich – die Codeausführung aus der Ferne funktioniert innerhalb einiger Tausend bis Zehntausend HTTP-Anfragen zuverlässig und eignet sich daher für automatisierte Attacken à la Heartbleed. Dass sie bereits von Cyberkriminellen oder anderen Tunichtguten ausgenutzt wird, ist nicht bekannt – dürfte sich aber bald ändern.

Die zugrunde liegenden Sicherheitslücken sind in verschiedenen Webservern und SAPIs (Server APIs) ausnutzbar, die PHP anbietet. Sowohl Apaches mod_php als auch PHP per FPM (FastCGI Process Manager) sind verwundbar, LSAPI (LiteSpeed Server API) ebenfalls. Ob FrankenPHP betroffen ist, ist unklar, PHP-Webserver unter Windows sind hingegen definitiv angreifbar.

Die Veröffentlichung der Sicherheitslücken war ursprünglich für den 22. Oktober geplant, wurde jedoch wegen eines Leaks um einen Tag vorverlegt. Das PHP-Team gibt an, die Fehler in allen PHP-Versionen seit PHP 5 (das seit 21 Jahren sein Lebensende erreicht hat) gefunden zu haben. Einen vollständigen Schutz bieten nur die nun erschienenen Updates – zwar können Administratoren das Risiko eines erfolgreichen Exploits etwas mindern, aber nicht aus der Welt schaffen.

Die aktualisierten PHP-Versionen sind für verschiedene Betriebssysteme zum Download auf php.net verfügbar und erscheinen in den nächsten Stunden für die großen Linux-Distributionen. Sie tragen die Versionsnummern

• 8.5.12
• 8.4.27
• 8.3.36
• 8.2.35

Es wird zwar Backports für die Versionen 7.4, 8.0 und 8.1 geben, aber: Wer eine ältere PHP-Version nutzt, sollte die Gelegenheit dringend wahrnehmen und mindestens auf PHP 8.3 schwenken. Während dessen Produktunterstützung noch bis Ende 2027 andauert, geht bei PHP 8.2 bereits Ende 2026 das Licht aus. Wer sich das größtmögliche Zeitpolster schaffen möchte, aktualisiert gleich auf PHP 8.5.12.

Anwendungen, die in Docker-Containern laufen und eine verwundbare PHP-Version mitbringen, sind ebenfalls von den Sicherheitslücken betroffen und sollten schleunigst nach Verfügbarkeit aktualisiert werden (etwa mit „docker compose pull && docker compose up -d“).

Wer seine Webanwendungen bei einem Hoster betreibt, sollte prüfen, ob dieser die Updates zeitnah zu installieren plant, etwa mittels Blick auf die Wartungsseite. Einige der von heise security im Laufe des Mittwochvormittag kontaktierten Hoster waren bereits gewarnt und gaben ihrerseits Warnungen an Kunden ewiter; Uberspace kündigte gar an, PHP-Dienste um 15:45 zeitweise komplett zu deaktivieren. CDN- und Netzbetreiber Cloudflare hingegen hat Regeln für seine Web Application Firewall (WAF) implementiert, die alle bekannten Angriffsvektoren schlössen. Diese Regeln stünden auch Nutzern der kostenlosen Cloudflare-Variante zur Verfügung, seien aber nur ein vorübergehender Flicken, so Cloudflare-CTO Knecht auf Social Media.

Das PHP-Team hat eine Reihe von Konfigurationseinstellungen veröffentlicht, die den Missbrauch etwas eindämmen können, warnt aber: „Sie sollten als nichts Anderes als eine temporäre Krücke betrachtet werden“.

• memory_limit=-1
• post_max_size kleiner als 1/4 des Speicherlimits, hilfsweise 8M
• max_input_nesting_level auf einen Wert wie etwa 8 beschränken
• session.upload-progress.enabled=0
• Bei PHP-FPM: pm.max_requests auf einen niedrigen Wert festlegen
• SELinux / AppArmor nutzen,
• apparmor_hat setzen,
• fatal_error_backtraces=0 setzen und
• mit expose_php=0 das Vorhandensein von PHP verschleiern.

Alle Maßnahmen können negative Auswirkungen auf die Geschwindigkeit oder Funktionalität der PHP-Installation haben; sie sollten daher wohldosiert eingesetzt werden. Und: Sie ersetzen keinesfalls ein zügiges Update.

Nicht nur Web- und Applikationsserver, auch verschiedene vernetzte Geräte nutzen PHP, etwa für ihre webbasierte Verwaltungsoberfläche. All diese Geräte müssen Admins bei der Aktualisierung im Blick haben, etwa von folgenden Herstellern (Quelle)

• pfSense
• OPNsense
• QNAP NAS
• DrayTek
• ZyXEL
• D-Link
• TP-Link
• Netgear
• Tenda
• Synology

Auch Security-Appliances der Hersteller Citrix, Palo Alto und Ivanti nutzen PHP, sowie BIGIP-Loadbalancer von F5. Netzwerkverwalter sollten sie als Teil der Angriffsfläche, nicht als Teil der Verteidigungsmaßnahmen begreifen, sofern die Management- oder Webinterfaces zum Internet hin geöffnet sind.

Wer PHP lediglich für interne Anwendungen verwendet, darf sich dennoch nicht in Sicherheit wiegen. Veraltete PHP-Installationen oder mit PHP ausgestattete Appliances können Angreifern, die etwa über eine Windows-Malware ins Netzwerk eingedrungen sind, nützlich sein, um sich dauerhaft dort einzunisten.

Die PHP Group bemüht sich intensiv um die Absicherung des Ökosystems. So hat sie nach langen Jahren 2024 wieder eine Überprüfung des Quellcodes beauftragt, der bereits eine ähliche wie die nun publizierten Sicherheitslücken zutage förderte. Wie diese zu beheben sei, darüber herrschte damals offenbar Uneinigkeit, wie die Entwickler selbstkritisch im PHP-Blog erwähnen. Im Mai 2026 rief die PHP-Stiftung das Ecosystem Security Team ins Leben und stellte drei Sicherheitsexperten an. Auch KI hält im Arbeitsalltag des PHP-Sicherheitsteams Einzug.

Über die nun veröffentlichten Sicherheitslücken sind gleich zwei Forscherteams gestolpert: Zunächst jenes von Calif, das erst kürzlich einen iOS-Jailbreak auf offener Bühne präsentierte. Das Unternehmen führte gemeinsam mit dem PHP Ecosystem Security Team einen Code-Audit durch, der von OpenAI im Rahmen der Initiative „Patch the Planet“ gesponsort wurde. Auch die Google-Tochter Wiz und OpenAI konnten die Sicherheitslücken mittels LLMs nachvollziehen und bei der Überprüfung des Sicherheitsflickens assistieren.

PHP-Release-Manager Volker Dusch sagte heise security: „Nach vielen Wochen Arbeit bin ich sehr froh, dass wir den Release geschafft haben.“ Zwar sei das Leak bedauerlich, aber: „Durch die Arbeit bis dahin wir waren gut vorbereitet, hatten Zeit für die Koordination und die Möglichkeit, Nutzer bestmöglich zu schützen“, so Dusch weiter.

PHP ist als unsichere Sprache verschrien, da sie es Anfängern vor allem in älteren Versionen allzu leicht machte, Webapplikationen mit brandgefährlichen Sicherheitslücken zusammenzuschustern – das in PHP geschriebene WordPress hatte eine solche erst vor knapp vier Wochen. Im Kern der Skriptsprache sind kritische sicherheitsrelevante Fehler jedoch vergleichsweise selten geworden. Im Sprachkern selbst gab es zuletzt im Jahr 2017 mit CVE-2017-5340 ein Problem bei der Deserialisierung von Nutzereingaben, das Angreifer ebenfalls zur Einschleusung eigener Programme hätten nutzen können.

(cku)