PHP: Warum die jüngste Lücke nicht das Ende der Sprache bedeutet
Für wenige Tage im Oktober 2026 schien die Internetwelt zu bebenden: Zwei extrem kritische Schwachstellen in PHP führten dazu, dass Behörden, Universitäten und Krankenhäuser weltweit vorsorglich ihre Webseiten vom Netz nahmen. Prompt war wieder vom "Ende von PHP" die Rede – ein Reflex, der seit Jahren den Sprachstreiten im Web dient. Doch wer die Fakten betrachtet, kommt zu einem anderen Schluss, denn die Lücke ist vor allem so gravierend, weil PHP schlicht so erfolgreich ist – und genau das ist auch der Grund, warum PHP auch danach weiter das Web tragen wird.
Was passiert ist: "PHP2Shell"
Am 21. Oktober 2026 wurden zwei Schwachstellen im Kern der Programmiersprache öffentlich, die unter dem Sammelnamen "PHP2Shell" laufen und als CVE-2026-109618 und CVE-2026-109619 registriert wurden. Beide wurden mit einem CVSS-Score von 9,2 von 10 als kritisch eingestuft. Die Folgen eines erfolgreichen Angriffs wären gravierend: Angreifer könnten ohne Anmeldung und ohne Nutzerinteraktion aus der Ferne Schadcode auf Webservern ausführen – im schlimmsten Fall mit vollständiger Kontrolle über Website, Datenbank und Kundendaten.
Technisch lagen den beiden Lücken Fehler in der Speicher- und Fehlerverwaltung zugrunde. Bei CVE-2026-109618 kann die Out-of-Memory-Behandlung PHP unterbrechen, während interne Anfragedaten nur teilweise initialisiert sind – die anschließende Bereinigung behandelt die ungültigen Daten dann als gültig. Bei CVE-2026-109619 überlebt interner Zustand einer Anfrage im Speicher eines Worker-Prozesses, obwohl der Speicher bereits freigegeben wurde.
Betroffen waren praktisch alle PHP-Installationen, die Webanfragen verarbeiten – von PHP 5.4 bis 8.5.11, also Versionen aus zwei Jahrzehnten. Gefährdet waren dabei alle gängigen Betriebsarten: PHP-FPM, Apaches mod_php, php-cgi, FrankenPHP und LiteSpeed. Das PHP-Projekt reagierte deshalb innerhalb von Stunden mit gepatchten Versionen: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Die Veröffentlichung war eigentlich erst für den 22. Oktober geplant, wurde aber wegen eines vorzeitigen Leaks der Details um einen Tag vorgezogen.
Die Reaktion war heftig, aber angemessen - so stufte etwa das BSI das Risiko mit der Warnstufe "3 / Orange" ein, mehrere Bundesländer, Kommunen, Behörden, Universitäten und Krankenhäuser nahmen daraufhin ihre Seiten vorübergehend offline und laut Cloudflare gab es binnen weniger Stunden Millionen von Ausnutzungsversuchen. Bemerkenswert: Entdeckt wurden die Lücken mit Unterstützung von KI und bislang gab es keine bestätigten erfolgreichen Angriffe. IT-Experten empfehlen Betreibern nun, neben dem Update auch die Logdaten rückwirkend bis zum 17. Oktober 2026 zu prüfen, als auf einem Amazon-Honeypot erste Angriffsversuche registriert wurden.
PHP betreibt das Web
Der eigentliche Grund, warum diese Lücke solche Wellen schlug, ist schlicht, dass PHP quasi überall im Einsatz ist. Laut W3Techs setzen rund 69,3 Prozent aller Websites weltweit auf PHP. Das ist also längst keine Nische, sondern das Fundament des halben Internets – von simplen Blogs über Nachrichtenportale bis zu Onlineshops und Content-Management-Systemen.
Dazu kommt auch das große WordPress-Ökosystem: Rund 40 Prozent aller Websites weltweit laufen auf WordPress, Experten schätzen deren Zahl auf 400 bis 500 Millionen. Unter den Websites, die überhaupt ein CMS einsetzen, liegt WordPress sogar bei etwa 58 Prozent. Und WordPress, WooCommerce, Drupal, Typo3 und viele weitere Systeme haben eines gemeinsam: Sie sind in PHP geschrieben. Die Lücke betraf also nicht irgendein Nischenprodukt, sondern die technische Basis, auf der ein Großteil der öffentlichen Webpräsenzen steht – von dem Moment an, in dem ein Webserver eine Anfrage bearbeitet, noch bevor der eigentliche Anwendungscode läuft.
Auch andere Sprachen hatten massive Lücken
Wer jetzt argumentiert, so etwas beweise die technische Rückständigkeit von PHP, verkennt allerdings auch die Geschichte der letzten Jahre. Schwere Sicherheitslücken gab es nämlich in so gut wie allen großen Ökosystemen – teils mit deutlich dramatischeren Ausmaßen als PHP2Shell:
| Vorfall | Jahr | Betroffene Technologie | Auswirkung |
|---|---|---|---|
| Log4Shell | 2021 | Java (Log4j-Bibliothek) | Potenzielle Verwundbarkeit von Milliarden Computern, 93 Prozent aller Cloud-Umgebungen gefährdet |
| XZ-Utils-Backdoor | 2024 | C (Linux-Kompressionsbibliothek) | CVSS 10,0, gezielte Backdoor zur SSH-Authentifizierungs-Umgehung |
| npm/PyPI-Angriffe | 2026 | JavaScript und Python | Hunderte kompromittierte Pakete, selbstverbreitender Supply-Chain-Wurm |
Die Log4Shell-Lücke in der Java-Bibliothek Log4j von Dezember 2021 (CVE-2021-44228) machte laut BSI potenziell weltweit mehrere Milliarden Computer verwundbar und traf die Produkte zahlreicher Internetkonzerne. IBM zufolge waren 93 Prozent aller Cloud-Umgebungen gefährdet, und das US-Heimatschutzministerium schätzte, dass es mindestens ein Jahrzehnt dauern könnte, jede betroffene Stelle zu finden und zu beheben. Das war mit Abstand schwerwiegender als PHP2Shell und niemand hat seither ernsthaft behauptet, Java sei deshalb "am Ende".
Die XZ-Utils-Backdoor von 2024 zeigte zudem ein noch unheimlicheres Szenario: Ein Angreifer schlich sich über Jahre in ein Open-Source-Projekt ein und platzierte eine Backdoor in einer weit verbreiteten C-Bibliothek, mit der sich die SSH-Authentifizierung auf Linux-Systemen umgehen ließ – bewertet mit dem Höchstscore von 10,0. Entdeckt wurde sie nur durch Zufall, weil ein Entwickler eine um eine halbe Sekunde verlangsamte SSH-Anmeldung auffiel.
Und im Mai 2026 wurden Hunderte npm- und PyPI-Pakete für JavaScript und Python mit Credential-Stealern verseucht – ein Supply-Chain-Wurm, der sich über gestohlene Tokens selbst verbreitete und sogar die Deinstallation überlebte. Die Liste ließe sich fortsetzen: Heartbleed in OpenSSL, die Equifax-Panne, links-pad in npm. Die Lehre daraus ist einfach: Massives Auftreten und kritische Lücken sind kein alleiniges PHP-Problem, sondern ein Problem aller verbreiteter Software. Wer viel verbreitet ist, wird mehr angegriffen, genauer geprüft und fällt entsprechend härter auf.
PHP 2026: moderner als sein Ruf
Das Bild vom "schlechten PHP" stammt meist aus der PHP-5-Ära und die ist bereits lange vorbei. Seit PHP 8.0 (November 2020) hat sich die Sprache technisch dramatisch weiterentwickelt: Union Types, Enums, Fibers, Readonly Properties und Klassen, Property Hooks, ein JIT-Compiler, striktere Typen – über 50 neue Features allein in der 8er-Reihe. PHP 8.5, veröffentlicht im November 2025, brachte zudem den Pipe-Operator, eine neue URI-Extension und detaillierte Fatal-Error-Backtraces für deutlich besseres Debugging.
Auch in den Beliebtheitsrankings hält sich PHP weiter vorne: Im Oktober 2026 liegt es im TIOBE Index auf Platz 12, zuletzt sogar vor Go. Dahinter steht ein vitales Ökosystem – von Laravel über Symfony bis WordPress – sowie die PHP Foundation, die die Weiterentwicklung der Sprache institutionalisiert und durch die aktuellen Ereignisse nicht weggebrochen, sondern ins öffentliche Bewusstsein gerückt ist.
Der vielleicht stärkste Punkt für PHP stammt aber aus dem Oktober 2026 selbst: Der Vorfall zeigte nicht Schwäche, sondern Handlungsfähigkeit. Die Lücken wurden proaktiv von Sicherheitsforschern (mit KI-Unterstützung) gefunden und verantwortungsvoll mit vorab angekündigter Patch-Koordination veröffentlicht. Innerhalb eines Tages lagen Updates für vier Support-Zweige vor, weltweit wurde schnell gepatcht und die meisten Seiten sind inzwischen wieder online. Genau dieses Zusammenspiel aus sauberer Disclosure, schneller Patch-Infrastruktur und wachsamer Community zeugt von einem ausgereiften, professionell betreuten Projekt.
Fazit: Ein schwierischer Monat, aber kein Todesstoß
PHP2Shell war der schwerste Sicherheitsschock in der Geschichte der Sprache – aber die Reaktion darauf hat gezeigt, was PHP stark macht: eine enorme Verbreitung, die jede Schwachstelle sofort sichtbar und relevant macht, und gleichzeitig eine Community und Infrastruktur, die innerhalb von Tagen weltweit für Abhilfe sorgt. Log4Shell hat Java nicht begraben, die XZ-Backdoor nicht C, und die npm-Angriffe nicht JavaScript. Warum also sollte ausgerechnet PHP an einer Lücke scheitern, die schon nach wenigen Tagen gepatcht war?
Solange zwei von drei Websites der Welt auf PHP laufen und WordPress rund 40 Prozent des gesamten Webs ausmacht, ist die Frage nicht, ob PHP überlebt – sondern wie schnell wir alle unsere Server aktualisieren. Wer heute noch behauptet, PHP sei tot, hat einfach nicht verstanden, dass genau diese Sprache unter der Oberfläche unseres Internets arbeitet - auch und gerade nach dem Oktober 2026.
Ja, der typische Reflex wie oft. Ich hasse es!