Scheiß PHP …
*Seufz*
gerade [Nein, vorhin, wurde beim Schreiben dieses Artikels unterbrochen] notfallmäßig den Webserver gepatcht und rebootet, obwohl ich ihn eigentlich erst vergangene Nacht aktualisiert hatte. Ganz große Sicherheitslücke in PHP. Mal wieder.
Ein Leser fragte noch an
Charité nimmt Webseiten offline: Schutz vor IT-Sicherheitslücke | Berlin | BZ-BERLIN.de
Sorry, bin Dilettant wenn nicht sogar DAU, was bitte ist eine “weltweite IT-Sicherheitslücke”? Alien attack? Die Goldene Horde greift mal wieder an? Die “Nova Polizei”? Is Quality A Myth?
So dilettantisch, wie sich der Leser selbst einschätzt, ist das gar nicht. Die Frage ist mehr als berechtigt.
Heise: php2shell: Kritische Sicherheitslücken erlauben Codeeinschleusung in PHP
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.
Das BSI: PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit
In einer Vorab-Ankündigung informieren die Entwickler von PHP aktuell über die Veröffentlichung von Details und Patches zu zwei Schwachstellen in der Programmiersprache am 21. Oktober 2026 ab 16 Uhr [PHP26a]. Auch wenn zum aktuellen Zeitpunkt nur wenige Details verfügbar sind, legen die Bewertungen nach CVSS (Common Vulnerability Scoring System; Version 4.0) mit 9.2 von 10 nahe, dass es Angreifern auf Basis von CVE-2026-109618 und CVE-2026-109619 gelingen könnte, aus der Ferne schadhaften Code auf Webservern mit PHP-Anwendungen auszuführen [CEU26].
Weiterhin kann aus den CVSS-Scores abgeleitet werden, dass für eine Ausnutzung weder eine Authentifizierung noch eine Nutzerinteraktion erforderlich sind. Die Schwachstellen werden in aktuellen Berichtserstattungen auch als “PHP2Shell” bezeichnet, um die Ähnlichkeit mit der Schwachstelle “Log4Shell” aufzuzeigen.
Die Charité hat also durchaus richtig gehandelt, “weltweite IT-Sicherheitslücke” ist keineswegs übertrieben. Im Gegenteil, es zeigt, dass an der Charité jemand gut aufpasst und reagiert, unter diesen Umständen völlig richtig gehandelt. Dafür gibt es einen dicken Lob-Punkt.
PHP als Dauerdrama
Was mich viel mehr ärgert, ist, dass wir immer noch an diesem Scheiß-PHP hängen.
PHP war schon von Anfang an, per Konstruktion, ein Sicherheitsfiasko. Die ganze Grundidee ist bescheuert. In der Frühzeit meines Blogs hatten sie mir in WordPress mal eine Backdoor und einen Pornoproxy durch eine Sicherheitslücke automatisiert reingehauen. Ich hatte mal ein Plugin ausprobiert, es hatte mir aber nicht gefallen, weshalb ich es wieder rausgeworfen und deaktiviert, aber nicht gelöscht hatte. Und selbst dann, wenn man ein plugin gar nicht verwendet, kann ein Angreifer PHP-Skripte über den Pfad ausführen, einfach weil sie da sind. Und weil WordPress in einer Standardkonfiguration Schreibrechte hat, damit man Graphiken und so weiter hochladen kann, konnte ein Angreifer eigene PHP-Skripte dort ablegen, wo die Uploads liegen, und dann ausführen. Skripte und Inhalte zu mischen ist eine so katastrophale Fehlkonstruktion, dass es das nie hätte geben dürfen. Jede Menge anderer Sicherheitsprobleme noch oben drauf.
Es hat sich aber durchgesetzt wie Basic, weil es so einfach ist. Weil man das einfach mal so schnell hinmurksen, das einfach so in den HTML-Text schreiben kann. Ein dynamisch erzeugter Inhalt? Einfach irgendwo in den HTML-Text schreiben.
Ich habe seit mindestens 5 Jahren vor, WordPress vor allem aus diesem Grund zu ersetzen, hätte das auch längst getan, bin aber durch die ganzen Rechtsstreitigkeiten nie dazu gekommen, das hat mir viel zu viel Zeit weggenommen. Und das ist ein deutsches Problem: Wir sind nur noch mit juristischem Mist beschäftigt und kommen nicht mehr dazu, konstruktiv zu arbeiten.
Ich erzähle das zwar immer und oft von mir selbst, ich weiß aber, dass es vielen anderen genauso geht. In allen Branchen klagen sie, dass sie nur noch mit Bürokratie und Rechtssachen beschäftigt sind und zu ihrem eigentlichen Geschäft nicht mehr kommen. Ich nehme das Problem natürlich subjektiv wahr, aber es ist kein Danisch-, sondern ein Deutschlandproblem.
Wie dem auch sei: Meine Seite habe ich durchgepatcht, sobald der Patch verfügbar war. Und wenn sie zusammenfiele, wäre das auch nicht schlimm, dann ist halt ein Blog für einen Tag offline, und ich kann sie per Ansible und Datenbackup in geschätzten zwei Stunden reproduzieren, sofern und sobald ich Zugriff auf die nötigen Rechner habe. Und wenn mein Blog drei Tage weg wäre, ginge die Welt davon auch nicht unter.
Nun gibt es aber reichlich Webseiten, die deutlich wichtiger und zeitkritischer sind, und viele dieser Webseiten werden eben nicht gepflegt oder zeitnah gepatcht. Und damit stehen vermutlich Millionen angreifbare Server im Internet herum.
PHP hätte schon längst entsorgt werden müssen. Aber: Einen wirklich praktikablen Ersatz hat man dafür bisher auch nicht.