PHP: Neunundzwanzig Jahre mit offener Tür

PHP2Shell, diese Woche

Am 21. Oktober 2026 hat das PHP-Projekt vier Releases auf einmal veröffentlicht, 8.5.12, 8.4.27, 8.3.36 und 8.2.35, um zwei kritische Lücken im Interpreter selbst zu schließen¹. Nicht in WordPress. Nicht in einem Plugin. In PHP.

Beide sind mit 9,2 nach CVSS 4.0 bewertet. Beide erlauben Remote Code Execution ohne Login. Die Forscher, die sie gefunden haben, sagen klar, wie weit das reicht: „Every PHP version released in the last decade is affected by at least one of these vulnerabilities, going back to version 5.4.“²

Den Rest sagt das Advisory des PHP-Projekts selbst:

Und es wurde schon benutzt, bevor irgendwer Bescheid bekam. Amazons Honeypot-Netz hat am 17. Oktober einen Versuch aufgezeichnet, vier Tage vor der Offenlegung³. watchTowr sah es am 21. in freier Wildbahn, und funktionierende Proofs of Concept waren wenige Stunden nach dem Patch öffentlich⁴.

Beide Bugs sind Speichersicherheitsfehler. Einer steckt darin, wie der Interpreter aufräumt, nachdem ihm der Speicher ausgegangen ist. Der andere ist ein Use-after-free: Speicher, der einer Anfrage gehört, wird freigegeben und danach wieder gelesen, und die nächste Anfrage auf demselben Worker kann ihn sehen⁵⁶. Merk dir den zweiten. Er kommt später wieder.

Nichts davon ist neu. Genau darum geht es in diesem Beitrag. PHP2Shell ist kein Unfall, der einer sorgfältigen Sprache passiert ist. Es ist die neueste Seite in einer Bilanz von fast dreißig Jahren, und jede Zahl darin ist öffentlich.

Ein Prozess hält alles

Von November 2014 bis April 2017 war ich Third-Line-Linux-Engineer auf der Cloud- und Hosting-Plattform von Pulsant. Ein Teil des Jobs war, PHP-FPM-Umgebungen für E-Commerce-Kunden einzurichten und sie auf Geschwindigkeit zu trimmen.

PHP-Einbrüche waren an der Tagesordnung. Nicht gelegentlich. An der Tagesordnung. Und sie liefen auf zwei Ursachen hinaus: schlechter Betrieb und keine Trennung zwischen Frontend und Backend.

Die Sprache macht die zweite zum Normalfall. Eine typische PHP-Site ist ein Prozess. Das Seiten-Template, die Geschäftslogik und das SQL leben alle im selben Request-Handler, oft in derselben Datei. Dieser Prozess läuft als ein Betriebssystembenutzer. Er kann das Datenbankpasswort lesen, weil das Passwort in einer Datei neben dem Code liegt. Und er kann meistens in sein eigenes Web-Root schreiben, weil Uploads und Updates so funktionieren.

Das ist nicht meine Meinung darüber, wie PHP betrieben wird. Es ist das, was PHP und WordPress dokumentieren.

Lies die letzte Zeile noch einmal. Der Hersteller sagt dir, wie Least Privilege aussähe, und sagt dir dann, dass du es lassen sollst, weil Updates das Schema ändern.

Vergleich das mit der getrennten Variante. Das Frontend rendert Seiten und hält keine Geheimnisse. Das Backend ist ein eigener Dienst mit eigenem Benutzer, einer schmalen API und ohne Schreibrecht auf seinen eigenen Code. Das Datenbankkonto kann, was das Backend braucht, und sonst nichts. Die Empfehlungen von OWASP sagen dasselbe mit eigenen Worten: „The application’s backend database should be isolated from other servers“, in „a dedicated internal network segment“¹². PHPs eigenes Handbuch sagt, Anwendungen „should never connect to the database as its owner or a superuser“¹³.

Nichts davon ist exotisch. So sieht ein ordentlicher Prozess aus. Warum es hier zählt, ist einfach. Im getrennten Modell bringt ein Bug im Frontend einem Angreifer ein Frontend. Im üblichen PHP-Modell bringt ihm ein Bug irgendwo die Templates, den Code, die Zugangsdaten und die Daten, alles auf einmal.

PHP-FPM hilft, und PHPs eigene Installationsanleitung nennt es inzwischen den empfohlenen Weg, PHP unter Apache zu betreiben⁸. Seine Pools können Worker „with different uid/gid/chroot/environment“ starten¹⁴. Aber ein Pool pro Site ist immer noch eine Site pro Prozess, mit allem, was diese Site hat. Es ist eine bessere Wand zwischen Kunden. Es ist keine Wand innerhalb der Anwendung.

Behalte dieses Bild durch jeden Abschnitt unten im Kopf. Jeder Bug in der Bilanz landet auf diesem Prozess.

Neunundzwanzig Jahre CVEs

Die National Vulnerability Database führt jede CVE gegen den PHP-Interpreter unter einer Produktkennung, cpe:2.3:a:php:php. Frag sie, und sie antwortet 757¹⁵.

Diese Zahl betrifft nur den Interpreter. Kein WordPress, kein Drupal, keine Plugins, keine Frameworks. Nur das Programm, das dein PHP ausführt.

Zwei Spitzen fallen auf. Die erste ist März 2007, als ein ehemaliges Mitglied des PHP-Sicherheitsteams den Month of PHP Bugs veranstaltete und Lücken in der Zend Engine, im PHP-Kern und in seinen Erweiterungen „on a day by day basis“ offenlegte¹⁶. Er hatte das PHP Security Response Team gegründet, es dann verlassen und gesagt, warum: „I dislike the ways bugs are handled“¹⁷. Wenn der Gründer des Sicherheitsteams eines Projekts geht und jeden Tag einen Bug veröffentlicht, sagt dir das, wie es drinnen lief.

Die zweite Spitze ist 2016: 120 CVEs, 65 davon Speicherkorruption. Mehr dazu unten.

Die Speicherzahl ist eine Untergrenze, keine Schätzung. Die NVD markiert eine ganze Menge älterer Bugs als „Other“ statt mit einem Schwächetyp, darunter einige der Use-after-frees im nächsten Abschnitt. Die echte Zahl ist höher. Ich nehme die, die ich belegen kann.

Die Engine ist in C geschrieben

Hier muss das Argument zur Speichersicherheit sorgfältig gemacht werden, denn ein PHP-Entwickler wird völlig zu Recht darauf hinweisen, dass sein Code nie malloc aufruft. PHP-Skripte verwalten Speicher nicht von Hand. Du kannst in PHP keinen Pufferüberlauf so schreiben wie in C.

Musst du auch nicht. Der Interpreter, der dein Skript ausführt, ist in C geschrieben, und seine Erweiterungen sind in C geschrieben. Jedes Byte nicht vertrauenswürdiger Eingabe, das deine Site bekommt, jeder Header, jeder Upload, jedes Formularfeld, jedes Cookie, wird von diesem C geparst, bevor dein Code es sieht. Wenn dieses C falsch ist, spielt dein sorgfältiges PHP keine Rolle. PHP2Shell hat es bewiesen: Laut Advisory kann der Angriff „before any application code runs“ zünden¹.

Die Bilanz zeigt, was dieses C falsch gemacht hat:

Genau diese Klassen meinen die Sicherheitsbehörden, wenn sie von Speichersicherheit reden. Im November 2022 riet die NSA Organisationen, „to consider making a strategic shift from programming languages that provide little or no inherent memory protection, such as C/C++, to a memory safe language when possible“¹⁸. Im Dezember 2023 hat die CISA, mit dem britischen National Cyber Security Centre unter den Mitautoren, eine Zahl daran gehängt: „two-thirds of reported vulnerabilities in memory unsafe programming languages still relate to memory issues“¹⁹.

Keines der Dokumente nennt PHP. Müssen sie auch nicht. Sie nennen die Sprache, aus der PHP gebaut ist.

Das schlimmste wiederkehrende Beispiel ist unserialize(), die Funktion, die einen gespeicherten String wieder in PHP-Objekte verwandelt. Sie hatte dieselbe Klasse von Bug an derselben Stelle mehr als einmal:

Das PHP-Handbuch weiß es. Seine Seite zu der Funktion trägt die Warnung: „Do not pass untrusted user input to unserialize() regardless of the options value of allowed_classes.“²³ Da sagt dir eine Sprache, dass eine ihrer eigenen eingebauten Funktionen nicht sicher ist für genau das, womit der meiste Web-Code den ganzen Tag umgeht.

Dann ist da PHP-FPM, der Prozessmanager, den PHPs eigene Installationsanleitung gegenüber mod_php empfiehlt. Im Oktober 2019 zeigte CVE-2019-11043, dass „in certain configurations of FPM setup it is possible to cause FPM module to write past allocated buffers … opening the possibility of remote code execution“²⁴. Die fragliche Konfiguration war ein gängiges nginx-Setup. Behoben wurde es am 24. Oktober 2019²⁵. Die CISA nahm es später in ihren Katalog der nachweislich ausgenutzten Schwachstellen auf, markiert als in Ransomware-Kampagnen verwendet²⁶.

Die PHP Foundation hat tatsächlich ein ordentliches Sicherheitsaudit des Interpreter-Quellcodes beauftragt, und das muss man ihr anrechnen. Die Ergebnisse, veröffentlicht am 10. April 2025, fanden 27 Probleme, 17 davon mit Sicherheitsrelevanz²⁷. Das ist gute Praxis, und es sollte normal sein. Es sind aber auch 17 weitere, in einem Audit einer Codebasis, die schon fast drei Jahrzehnte öffentlicher Bug-Reports hinter sich hatte.

Die Sprache machte dieselben Fehler ein Stockwerk höher

Das C ist eine Schicht. Die Sprache darüber hat dieselbe Art Fehler in ihrem Design gemacht: Eingaben vertraut, denen sie nicht zu vertrauen hatte, und Jahre gebraucht, um damit aufzuhören.

register_globals verdient eine eigene Zeile. Jahrelang wurde jeder Parameter in der Anfrage, sagen wir ?admin=1, zu einer Variable in deinem Skript, und wenn dein Code $admin prüfte, bevor er es gesetzt hatte, hatte der Angreifer es für dich gesetzt. Das PHP-Handbuch selbst nannte das Abschalten „the most controversial change in PHP“²⁹. Zehn Jahre von standardmäßig aus bis weg. So lange hat das Projekt ein Feature geduldet, von dem es wusste, dass es gefährlich ist, weil das Entfernen Sites kaputt gemacht hätte.

Der Phar-Fall ist dasselbe Muster eine Schicht tiefer. 2018 zeigte Sam Thomas auf der Black Hat, dass ganz gewöhnliche Dateioperationen auf einem phar://-Pfad vom Angreifer gelieferte Metadaten deserialisierten, und damit das unserialize()-Problem in Funktionen brachten, die niemand für gefährlich hielt³⁶. PHP 8.0 hörte Ende 2020 auf, das automatisch zu tun, „to fix potential security vulnerabilities due to object instantiation, autoloading, etc.“³⁴.

Dann Type Juggling. PHPs == wandelt Typen vor dem Vergleich um, also werden Strings, die wie Zahlen aussehen, als Zahlen verglichen. Der RFC, der einen Teil davon in PHP 8.0 behoben hat, sagte es klar: „This results in many surprising comparison results, the most notable of which is that 0 == ‚foobar‘ returns true.“³⁵

Der Fix war echt. Er war auch nur halb. Hier ist dieselbe Prüfung, ausgeführt in den offiziellen Containern php:7.4-cli und php:8.5-cli, Letzterer ist 8.5.12, das Release, das diese Woche gegen PHP2Shell gepatcht wurde, mit beiden Ausgaben nebeneinander:

$ php -r 'var_dump(0 == "foobar");'
bool(true)            # 7.4.33
bool(false)           # 8.5.12

$ php -r 'var_dump("0e462097431906509019562988736854" == "0e830400451993494058024219903391");'
bool(true)            # 7.4.33
bool(true)            # 8.5.12

Zwei verschiedene Strings, gleich. Beide fangen mit 0e und Ziffern an, also liest PHP beide als null mal zehn hoch irgendwas, und null ist gleich null. Beide haben die Form eines MD5-Hashes. Vergleich einen gespeicherten Passwort-Hash mit == statt mit === oder hash_equals(), und jede Eingabe, deren Hash zufällig so anfängt, passt. Das ist seit Jahren dokumentiert. Es funktioniert im neuesten Release immer noch.

Das ist die Sprache in einem Beispiel. Ein Fix, der reinging, die Hälfte des Problems zurückgelassen, und die sichere Variante setzt voraus, dass du weißt, dass es einen anderen Operator gibt.

Fast jedes Jahr eine Shell

Die Frage, die man jeder Plattform stellen sollte, ist nicht, wie viele Bugs sie hatte. Sondern wie oft jemand den ganzen Server übernehmen konnte, ohne Passwort und ohne dass irgendwer irgendwas anklickt.

Die NVD bewertet jede CVE. Filter die 757 nach der Bewertung, die genau das bedeutet, Angriff übers Netz, keine Rechte, keine Benutzerinteraktion, hohe Auswirkung auf Vertraulichkeit und Integrität, und du bekommst 172¹⁵.

172 verteilt auf 23 der 28 Jahre, in denen es überhaupt eine PHP-CVE gibt. Nur fünf sind leer. 2016 allein hat 65.

Eine Schweregradbewertung ist eine Einstufung, kein Einbruch. Die zweite Hälfte des Bildes ist deshalb der CISA-Katalog Known Exploited Vulnerabilities, der nur Lücken mit bestätigter Ausnutzung in freier Wildbahn listet²⁶. Von seinen 1.754 Einträgen mit Stand 21. Oktober 2026 betreffen 81 PHP selbst oder in PHP geschriebene Anwendungen:

2026 ist schon jetzt das schlimmste Jahr für PHP im Katalog, und PHP2Shell ist noch gar nicht drin. Drei der diesjährigen stecken im WordPress-Kern selbst: zwei aufgenommen am 21. Juli und eine Remote File Inclusion am 25. September.

Und der Katalog zählt PHP viel zu niedrig. Er ist auf die Systeme der US-Bundesbehörden zugeschnitten und braucht eine CVE plus bestätigte Ausnutzung. Er enthält 3 Einträge zu WordPress-Plugins. Das WordPress-Plugin-Ökosystem verzeichnete allein 2025 11.334 Schwachstellen³⁷. Die 81 sind der Teil, den jemand Offizielles aufgeschrieben hat.

WordPress vervielfacht es

WordPress macht 39,6 % aller Websites aus, und 58,3 % der Sites, deren Content-Management-System sich erkennen lässt³⁸. PHP ist die serverseitige Sprache von 69,3 % der Sites, bei denen sich das sehen lässt³⁹. Was auch immer PHPs Bilanz ist, WordPress trägt sie also in einen sehr großen Teil des Webs und legt dann seine eigene obendrauf.

Der Kern ist nicht das Hauptproblem. Die Plugins sind es.

Wordfence zählte mit seiner eigenen Datenbank 8.223 für 2024, ein Anstieg um 68 % gegenüber 2023, und stellte fest: „Roughly 35% of the vulnerabilities disclosed in 2024 remain unpatched in 2025“⁴¹. Andere Datenbanken, andere Summen, gleiche Form.

Lass die Zahlen von 2025 einen Moment wirken. Fast die Hälfte der Schwachstellen hatte keinen Fix vom Entwickler, als sie öffentlich wurden. Und bei denen, auf die Angreifer tatsächlich losgehen, liegen im Median fünf Stunden zwischen Offenlegung und Massenausnutzung. Die meisten Leute prüfen ihre Plugin-Updates nicht alle fünf Stunden. Die meisten Leute können das gar nicht.

Das Plugin-Modell ist der Multiplikator. Die Sicherheit einer Site hängt vom unvorsichtigsten Autor von irgendetwas ab, das darauf installiert ist, und Wordfence fand heraus, dass „over one third of developers are unreachable or unresponsive“, wenn man ihnen eine Lücke meldet⁴¹. Patchstack zählte 1.614 Plugins und Themes, die 2024 wegen Sicherheitsproblemen, die niemand behob, aus dem Verzeichnis entfernt wurden⁴⁰. Und wegen des Ein-Prozess-Modells läuft jedes Plugin mit den vollen Rechten der Site.

Die Vorfälle sind eine lange Liste. Das hier sind die mit Primärquellen dahinter:

Bei der Zeile von 2016 war ich vorsichtig. Wordfence zeigte, dass die Site der Kanzlei eine Slider-Version fuhr, die trivial ausnutzbar war. Es zeigte nicht, dass die Dokumente auf diesem Weg abgezogen wurden, und ich werde nicht mehr behaupten, als die Belege hergeben.

Wie die Malware bleibt

Reinkommen ist die eine Hälfte. Drinbleiben ist die andere, und PHP macht das leicht, aus einem Grund, der direkt auf das Ein-Prozess-Bild zurückgeht.

Der Interpreter führt jede .php-Datei aus, die er erreichen kann. Das Web-Root ist meist von demselben Benutzer beschreibbar, der den Code ausführt. Sobald ein Angreifer also irgendeinen Weg hat, eine Datei zu schreiben, ein Upload-Formular, einen Plugin-Bug, einen Dateimanager, kann er ein Skript schreiben, das jedes Mal läuft, wenn jemand es aufruft. Das ist eine Web-Shell: eine kleine Datei, die in deiner Site sitzt und Befehle annimmt.

Die CISA sagt seit Jahren, in welchen Sprachen die meistens geschrieben sind: „The most commonly observed web shells are written in languages that are widely supported, such as PHP and ASP.“⁵⁰ Die gemeinsame Empfehlung von NSA und Australian Signals Directorate nennt sie „a long-standing, pervasive threat that continues to evade many security tools“, und schwer zu erkennen, weil sie „easily modified by attackers and often employ encryption, encoding, and obfuscation“ sind⁵¹.

Die Zahlen aus den Bereinigungen zeigen, wie oft sie da sind:

Im jüngsten Bereinigungsjahr hatte also die Hälfte der gehackten Sites noch einen Weg zurück auf der Platte liegen. Stell die Datenbank wieder her, patche das Plugin, und der Angreifer spaziert durch die Datei wieder rein, die er dagelassen hat.

Dafür gibt es keinen cleveren Fix. Es gibt den langweiligen, ordentlichen, und die NSA hat ihn aufgeschrieben: „web applications should not have permission to write directly to a web accessible directory or modify web accessible code“⁵¹. Dieser eine Satz ist das Schichtenmodell vom Anfang dieses Beitrags, gesagt von einem Nachrichtendienst.

WordPress’ Härtungsanleitung erwähnt, wenn’s interessiert, überhaupt nicht, dass man PHP im Upload-Verzeichnis an der Ausführung hindern sollte¹¹. Deshalb zitiert die Tabelle stattdessen OWASP und die NSA.

Schau, was nicht in dieser Tabelle steht. PHPs eigene Härtungseinstellungen. Das Handbuch ist da ehrlich. disable_functions „can be circumvented and should not be considered a sufficient security measure for shared hosting environments“, und open_basedir „is just an extra safety net, that is in no way comprehensive, and can therefore not be relied upon when security is needed“⁵⁵. Wenn die eigene Dokumentation einer Sprache dir sagt, dass ihre Sicherheitsschalter keine Sicherheitsgrenzen sind, dann glaub ihr. Die Grenze muss deshalb von außerhalb des Prozesses kommen.

Sogar bei php.net wurde eingebrochen

Wäre die Infrastruktur des Projekts selbst solide, könnte man argumentieren, die Bilanz gehe auf ein schweres Problem zurück, das gut gehandhabt wurde. Es wurde zweimal eingebrochen.

Der von 2021 ist der, der zählt. Jemand hat Code in den Quellbaum der Sprache selbst geschoben und sich dabei als die Leute ausgegeben, die sie pflegen. Es wurde entdeckt. Die Antwort des Projekts ist zitierwürdig, weil sie die richtige ist, klar gesagt: „maintaining our own git infrastructure is an unnecessary security risk“, und die Repositories zogen zu GitHub um⁵⁷.

Ehre, wem Ehre gebührt: Das war eine gute Entscheidung, schnell getroffen und offen erklärt. Aber schau, was sie eingesteht. Jahrelang lag die maßgebliche Quelle einer Sprache, die den Großteil des Webs betreibt, auf selbst betriebener Infrastruktur, die das Projekt selbst für ein Risiko hielt, das es nicht tragen sollte.

Das halbe Web läuft auf einer Version, die niemand patcht

Alles oben setzt voraus, dass die Site aktuell ist. Sehr viele sind es nicht.

php.net unterstützt derzeit vier Zweige. 8.2 bekommt nur noch Sicherheitsfixes, bis 31. Dezember 2026. 8.3, 8.4 und 8.5 sind der Rest⁵⁸. Alles Ältere ist End of Life: 8.1 seit 31. Dezember 2025, 8.0 seit November 2023, 7.4 seit November 2022⁵⁹.

Jetzt der gemessene Anteil dessen, was tatsächlich läuft:

PHP 7.4 allein, seit fast vier Jahren ohne Support, macht etwa ein Fünftel aller PHP-Sites aus, die ihre Version zeigen. Die Anforderungsseite von WordPress verlangt PHP 8.3 und sagt dann, WordPress „also works with PHP 7.4+“, während sie anmerkt, dass diese Versionen „have reached their official End Of Life“⁶³. Ein Hersteller, der weiter auf einer toten Version läuft, ist ein Hersteller, der beschlossen hat, dich nicht zum Umzug zu bewegen.

Zwei ehrliche Einschränkungen. W3Techs sieht die Version nur auf Sites, die sie mitteilen. Und manche Linux-Distributionen portieren Fixes in alte PHP-Builds zurück, also heißt „von php.net nicht unterstützt“ nicht immer „ungepatcht“. Aber PHP2Shell ist genau der Test dafür. Das Projekt hat diesmal Quell-Patches für 7.4, 8.0 und 8.1 veröffentlicht¹, und irgendwer muss sie trotzdem bauen, ausliefern und installieren. Auf einem Shared Host mit einer Version, die niemandem gehört, ist dieser Irgendwer niemand.

Ich habe PHP aufgegeben. Du solltest auch über den Ausstieg nachdenken.

Ich habe früher PHP geschrieben. Nach Pulsant habe ich die Sprache aufgegeben, wegen der Probleme, die sie verursacht hat, und der Arbeit, die diese Probleme gemacht haben. Kein einzelner schlimmer Vorfall. Jahre derselben zwei Ursachen, Site für Site, und die Aufräumarbeit landete bei dem, der gerade Schicht hatte.

Also sage ich es klar. Wenn du die Wahl hast, schau dir an, wie du davon wegkommst. Es gibt inzwischen bessere Werkzeuge dafür, und Go ist das, auf das ich dich zuerst verweisen würde.

Nicht weil es gerade in Mode ist. Sondern weil es standardmäßig das meiste von dem entfernt, was dieser Beitrag gezählt hat:

Kompiliert zählt doppelt. Es ist schneller: Go-Programme „are compiled ahead of time to native machine code“, ohne virtuelle Maschine darunter, und eines der erklärten Designziele ist „to approach the performance of C for comparable programs“⁶⁶. Und es ist sicherer, weil kein Interpreter im Request-Pfad zur Laufzeit Code parst und keine C-Engine mit 757 CVEs zwischen dem Netz und deinem Programm steht. PHP macht, sich selbst überlassen, das Gegenteil. Ohne OPcache lädt, parst und kompiliert es jedes Skript bei jeder Anfrage, unnötig, tausende Male pro Minute auf einer gut besuchten Site. OPcache gibt es, um genau das zu verhindern, „removing the need for PHP to load and parse scripts on each request“⁶⁴. Aber es ist ab Werk nicht an. Bis einschließlich 8.4 ist es eine separate Shared Extension, die jemand mit zend_extension laden und konfigurieren muss. Erst PHP 8.5 baut es fest ein: „The Opcache extension is now always built into the PHP binary and is always loaded“⁷⁰. Der eigene RFC des Projekts zu dieser Änderung sagt „running PHP in production without OPcache is generally considered a mistake“⁷¹. W3Techs sieht 8.5 auf 4,5 % der PHP-8-Sites⁶⁰, also ist für fast alles, was heute läuft, die Lösung gegen das Kompilieren jedes Skripts bei jeder Anfrage immer noch ein Zusatz, an den jemand denken musste. Und selbst geladen ist das, was es cacht, Bytecode, den der C-Interpreter ausführt. Go erledigt das Kompilieren einmal, bevor das Programm überhaupt eine Anfrage sieht.

Schneller und sicherer, vorausgesetzt, es ist ordentlich programmiert. Diese letzte Bedingung ist der ganze Inhalt der nächsten Absätze.

Gos Template-Paket fasst sein Design in einem Satz: Es erzeugt „HTML output safe against code injection“, und „The escaping is contextual, so actions can appear within JavaScript, CSS, and URI contexts.“⁶⁷ Sein Datenbank-Leitfaden ist genauso klar: „You can avoid an SQL injection risk by providing SQL parameter values as sql package function arguments.“⁶⁸ Das sind die Standards. In PHP sind das Dinge, von denen du wissen musst, dass du sie dir holen musst.

Die Zeile, die ich unterstreichen würde, ist die abgelegte Datei. Die Hälfte der gehackten Sites, die Sucuri 2023 bereinigt hat, hatte noch eine Hintertür auf der Platte⁵³, und das funktioniert nur, weil der Interpreter jedes Skript ausführt, das er erreichen kann. Ein kompilierter Dienst sucht nicht nach Skripten. Da ist nichts, woran eine abgelegte Datei andocken könnte.

Jetzt der ehrliche Teil, denn eine Sprache ist kein Heilmittel. Go ist speichersicherer, nicht perfekt speichersicher. Sein eigenes Speichermodell sagt, ein Data Race auf einem Slice, einer Map oder einem Interface-Wert „can in turn lead to arbitrary memory corruption“⁷², und Go liefert das Werkzeug mit, um das zu fangen. Bau mit -race oder führ go test -race aus, und das Binary wird mit einem Detektor kompiliert, der ein Race in dem Moment meldet, in dem es passiert. Er fängt Races zur Laufzeit statt zur Kompilierzeit und „can’t find races in code paths that are not executed“, also gehört er in jeden Testlauf und unter realistische Last⁷³. PHP hat nichts dergleichen. Den Speicher einer Anfrage von der nächsten fernzuhalten, bleibt komplett der Engine überlassen, und PHP2Shell ist genau diese Engine, die es falsch macht: Speicher, freigegeben von einer Anfrage, gelesen von der nächsten auf demselben Worker⁶. Abgesehen davon stoppt Go die Klasse der Speicherkorruption, die dieser Beitrag gezählt hat, und macht bei zwei weiteren den sicheren Weg zum einfachen. Es stoppt keine kaputte Login-Prüfung, keinen fehlenden Berechtigungstest und keine Abfrage, die aus zusammengeklebten Strings gebaut wird, wenn du darauf bestehst. Go veröffentlicht auch eigene Sicherheits-Advisories, über seine Schwachstellendatenbank⁶⁹. Und ein Go-Dienst, der als root aus einem beschreibbaren Verzeichnis läuft, ist immer noch schlecht betrieben.

Was es ändert, ist der Standard. PHPs Standard ist ein Prozess, der alles hält. Gos Standard ist ein Programm, das eine Aufgabe erledigt, und das ist die Trennung vom Anfang dieses Beitrags, mit dem Großteil der Arbeit schon erledigt. Wenn Go nicht zu deinem Team passt, ist Rust der andere Ausweg. Beide werden vorab in nativen Maschinencode kompiliert. Rust läuft „with no runtime or garbage collector“⁷⁴, und Compiler und Laufzeit von Go sind seit Go 1.5 „implemented in Go and assembler, without C“⁷⁵.

C# und Java stehen ebenfalls auf der Liste speichersicherer Sprachen der Behörden¹⁸, aber sie sind kein Ausweg aus dem Problem, mit dem dieser Beitrag angefangen hat. Beide laufen auf einer virtuellen Maschine, die in C++ geschrieben ist. HotSpot von OpenJDK umfasst „around 3000 C/C++ header and source files, comprising more than 1.2 million lines of code“⁷⁶, und Garbage Collector und JIT-Compiler von .NET sind C++-Quellcode im CoreCLR-Baum⁷⁷. Das ist dieselbe Form wie bei PHP: eine große native Engine zwischen dem Netz und deinem Code. Und Java lädt Code absichtlich in eine laufende Anwendung nach. Sein Standard-Classloader ist dazu da, „to load classes and resources from a search path of URLs referring to both JAR files and directories“⁷⁸, und Log4Shell hat daraus Remote Code Execution gemacht: Wer eine Logmeldung kontrollierte, „can execute arbitrary code loaded from LDAP servers“⁷⁹. Die Lücke landete direkt im Katalog der CISA²⁶. Es ist dieselbe Tür wie bei PHP, nur mit mehr Zeremonie davor.

Also nimm Go oder Rust. Zieh zuerst das Backend um, einen Endpunkt nach dem anderen, und lass das PHP-Frontend nichts halten, was sich zu stehlen lohnt, bis es auch gehen kann.

Wenn du es immer noch so ausrollst, kannst du dich dann Profi nennen?

Oben steht genug Beweismaterial, dass das keine Meinung mehr ist. Also hier die Frage, direkt gestellt. Wenn du PHP immer noch als einen Prozess ausrollst, der den Code, die Zugangsdaten und ein beschreibbares Web-Root hält, kannst du dich dann Profi nennen?

Es kommt darauf an, welcher von drei Leuten du bist. Und zu wissen, welcher, ist nichts, was dir passiert. Dafür zu sorgen, dass du es weißt, ist der Job.

Du hast eine echte Einschränkung, und du hast sie aufgeschrieben. Ein Produkt, von dem das Geschäft abhängt, gibt es nur in PHP. Eine Migration ist kalkuliert und steht im Budget fürs nächste Jahr. Gut. Das ist professionell, vorausgesetzt, der Grund steht auf Papier mit einem Datum daneben, der Laufzeitbenutzer kann den Code nicht schreiben, Uploads können nicht ausgeführt werden, das Datenbankkonto ist zurechtgestutzt, und du hast diese Woche PHP2Shell gepatcht. Du fährst ein bekanntes Risiko mit Absicht, mit den Wänden, die du drumherum ziehen kannst.

Es hat dir nie jemand gesagt. Niemand hat dir die Bilanz gezeigt, und das Tutorial, aus dem du gelernt hast, hat alles in ein Verzeichnis gepackt. Das ist eine Lücke, und jeder hat Lücken. Es hört auf, eine Lücke zu sein, in dem Moment, in dem du bis hierher gelesen hast.

Du weißt es und baust es trotzdem so. Du hast die Zahlen gesehen, oder genug davon. Du weißt, dass das Datenbankpasswort im Web-Root liegt und das Web-Root beschreibbar ist. Du rollst es so aus, weil es schneller geht, weil der Kunde nicht für Besseres zahlt, und weil niemand dich gezwungen hat, es zu rechtfertigen. Auf diesen Fall zielt die Frage. Das Versagen ist nicht die Lücke in deinem Wissen. Es ist, über eine Lücke hinwegzubauen, die du schon gesehen hast und nie zurückgegangen bist, um sie zu schließen.

Jeder war mal da. Aus freien Stücken dort zu bleiben, ist der Teil, der sich nicht verteidigen lässt.

Die Tür stand immer offen

Was mir beim Lesen dieser Bilanz auffällt, ist nicht, dass PHP Bugs hat. Jede Sprache hat welche. Sondern wie wenig davon je eine Überraschung war.

Das Projekt wusste 2002, dass register_globals gefährlich ist, und hat es 2012 entfernt. Sein Handbuch sagt dir, du sollst unserialize() nicht trauen, disable_functions nicht trauen, open_basedir nicht trauen. Seine eigene Dokumentation sagt, ein Skript unter mod_php kann ohne Passwort an die Datenbank. Die Behörden sagen seit Jahren, dass die Sprache, aus der es gebaut ist, die Quelle von zwei Dritteln der Speicherfehler ist. Jede Warnung ist da, schriftlich, von den Leuten, die es wissen müssten.

Und es hat trotzdem immer weiter gewonnen, weil es billig war. Billig zu hosten, billig zu lernen, billig an einen Kunden zu verkaufen, der bis Freitag eine Website wollte. Ein Verzeichnis, ein Prozess, ein Passwort in einer Datei, und eine Site, die lief. Der Preis war ein Shared-Hosting-Tarif. Was es gekostet hat, stand nie auf der Rechnung: die Aufräumarbeiten, die Hintertüren auf der Platte, die Kartennummern der Kunden, abgegriffen von bösartigem PHP, das Fünf-Stunden-Fenster zwischen Offenlegung und Angriff.

Das ist der Teil, für den ich keine Geduld habe. Nicht die Bugs. Die Entscheidung, immer und immer wieder getroffen von Leuten, die es besser wussten, dass der billige Weg gut genug war, weil niemand nachgeschaut hat. Ein Standard ist das, was du einhältst, wenn niemand nachschaut. Die Trennung zwischen Frontend und Backend, der schreibgeschützte Code, das zurechtgestutzte Datenbankkonto: Nichts davon ist neu, nichts davon ist teuer, und all das hätte einen guten Teil der Vorfälle oben zu nichts gemacht, worüber man schreiben müsste.

PHP2Shell ist nicht das Ende dieser Bilanz. Es ist nur der Eintrag dieser Woche. Die Sprache wird es patchen, die Hoster werden das Update irgendwann ausrollen, und der Versionsanteil wird nach oben driften, wie er es immer tut, langsam. Ob dich der nächste etwas kostet, entscheidet nicht PHP. Sondern ob du die Wände gebaut hast, die es dir nie gegeben hat, oder zu etwas umgezogen bist, das sie mitbringt.