PHP hat das Internet schon wieder lahmgelegt. Warum WordPress 2015 in Rente gehört hätte, und was du stattdessen bauen solltest

Am 21. Oktober 2026 lautete der offizielle Rat: notfalls offline nehmen

Am 21. Oktober 2026 warnte das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) vor kritischen Schwachstellen in PHP, die "aktuell weltweit Webanwendungen" bedrohen. PHP ist die Programmiersprache unter WordPress, WooCommerce, Joomla, Drupal, TYPO3, Shopware, Magento und einer langen Reihe von Buchungs, Mitglieder und Shopsystemen. Nach dem Stand des BSI waren alle bekannten PHP Versionen bis mindestens PHP 5 verwundbar, Angreifer könnten also aus der Ferne eigenen Code auf Webservern ausführen. Der Vizepräsident des BSI, Thomas Caspers, hielt eine großflächige Ausnutzung innerhalb weniger Stunden nach Erscheinen der Updates für wahrscheinlich, auch weil Angreifer dafür KI Werkzeuge nutzen können. Das Fazit der Behörde: "Es besteht also unverzüglicher Handlungsbedarf!"¹

Am selben Tag riefen die Europäische Kommission, die EU Cybersicherheitsagentur ENISA, das Notfallteam der EU Institutionen, Europol und das Netzwerk der nationalen Notfallteams (CSIRTs Network), dem auch das österreichische CERT.at angehört, gemeinsam dazu auf, alle PHP Anwendungen zu finden, die Updates mit den Hostinganbietern einzuspielen, alles mit Zugang zum Internet zuerst zu behandeln und Anwendungen, die sich nicht sofort patchen lassen, vom öffentlichen Netz zu trennen.² Das britische National Cyber Security Centre schrieb in seiner Warnung, dass Organisationen mit "any version of PHP" betroffen seien, und empfahl, Systeme ohne Update oder Übergangslösung offline zu nehmen. Außerdem riet es, vor dem Patchen nach Spuren eines Einbruchs zu suchen, weil ein Angreifer, der zuerst drin war, eine Hintertür hinterlassen haben kann, die das Update überlebt.³

Die US Behörde CISA ging noch weiter: Systeme, die nicht sofort aktualisiert werden können oder noch auf PHP 8.1 oder älter laufen, sollen offline, bis sie gepatcht oder aktualisiert sind.⁴ Am 26. Oktober 2026 nahm die CISA beide Lücken in ihren Katalog der aktiv ausgenutzten Schwachstellen auf, was sie nur tut, wenn es Belege für Angriffe in freier Wildbahn gibt.⁵

Wenn deine Website auf PHP läuft und du seitdem nicht nachgesehen hast: Hör hier auf zu lesen und prüf sie jetzt. Der Rest des Artikels läuft dir nicht davon.

Was die beiden Lücken tatsächlich tun

Die beiden Schwachstellen tragen die Katalognummern CVE-2026-109618 und CVE-2026-109619, Sicherheitsforscher nennen das Paar PHP2Shell. Das PHP Projekt hat beide als kritisch eingestuft, mit 9,2 von 10 Punkten auf der aktuellen Bewertungsskala (CVSS Version 4).⁶⁷

Die Interna brauchst du nicht, aber die Form erklärt, warum es so eilig war. Die erste Lücke steckt darin, wie PHP mit Speichermangel umgeht. Erreicht eine Anfrage ihr Speicherlimit, bricht PHP sie hastig ab, und manche Teile von PHP halten danach Speicher, der nie sauber vorbereitet wurde. Die Aufräumroutine, die danach läuft, kann diesen Datenmüll lesen und darauf reagieren. Laut dem Advisory des PHP Projekts erreicht ein Angreifer diesen Zustand mit einer präparierten Anfrage an ein Upload Formular und bringt so Code unter dem Konto des Webserver Prozesses zur Ausführung. Gezeigt wurde das über ganz normales HTTP gegen Apache mit mod_php in Standardkonfiguration.⁶ Die zweite Lücke ist veralteter Zustand: Ein Teil der globalen Buchführung von PHP kann noch auf Speicher einer längst beendeten Anfrage zeigen, und die nächste Anfrage greift darauf zu, bevor er aufgeräumt ist.⁷

Die korrigierten Versionen erschienen am selben Tag: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Das Advisory sagt klar, dass nur das Update vollständig schützt. Die Übergangsmaßnahmen, etwa ein geändertes Speicherlimit oder das Blockieren von Upload Anfragen vor dem Server, senken das Risiko, beseitigen es aber nicht.⁶

Warum eine Lücke in PHP so viel vom Web trifft

Die meisten Sicherheitsmeldungen betreffen ein Produkt mit einem Fehler. Diese betrifft ein Fundament.

Laut W3Techs ist PHP die Serversprache von 68,8 % der Websites, deren Serversprache sich erkennen lässt, und allein WordPress betreibt 39,3 % aller Websites, das sind 58,0 % der Seiten mit erkennbarem Content Management System (Stand 11. November 2026).⁸⁹ Der NVD Eintrag zur ersten Lücke führt außerdem Industrie und Gebäudetechnik von Siemens, die PHP mitliefert. Darum reicht es nicht, nur die Website anzusehen.⁷

Das Bild der Versionen macht es schlimmer. Unter den PHP Websites zählt W3Techs 66,8 % auf PHP 8, 25,6 % auf PHP 7 und 7,5 % auf PHP 5.⁹ Das PHP Projekt pflegt derzeit nur noch die Zweige 8.2, 8.3, 8.4 und 8.5. Jede Seite auf PHP 7 oder 5, und jede auf 8.0 oder 8.1, läuft also auf einer Version, für die das Projekt selbst keine Korrekturen mehr liefert.¹⁰

Rund ein Drittel der PHP Websites läuft also auf einer Hauptversion ganz ohne Korrekturen vom Projekt, bevor man überhaupt fragt, wie viele PHP 8 Seiten noch auf 8.0 oder 8.1 stehen. Wenn das halbe Web auf demselben Fundament steht, ist ein Riss darin das Problem aller, im selben Moment. Angreifer wissen das. Du wirst nicht angegriffen, weil jemand dein Geschäft nicht mag. Du wirst angegriffen, weil ein Skript, das das ganze Internet abklappert, deine Adresse gefunden hat und dein Server geantwortet hat.

Die Schwachstelle ist das Pluginmodell, nicht der WordPress Kern

Hier lohnt es sich, fair zu sein, denn Belege überzeugen mehr als eine Schimpftirade.

Der WordPress Kern wird sorgfältig gepflegt. Patchstack, eine Sicherheitsfirma, die das WordPress Ökosystem beobachtet, zählte für 2025 insgesamt 11.334 neue Schwachstellen in diesem Ökosystem, 42 % mehr als 2024. Nur sechs davon betrafen den WordPress Kern, alle mit niedriger Priorität. Auf Plugins entfielen 91 %, auf Themes 9 %.¹¹

Derselbe Bericht zeigt, warum das wichtig ist. In 46 % der Fälle hatte der Entwickler bis zur Veröffentlichung der Schwachstelle keine Korrektur geliefert, und bei den am stärksten angegriffenen Lücken lag der gewichtete Median zwischen Veröffentlichung und erstem Angriffsversuch bei fünf Stunden.¹¹ Eine typische Firmenwebsite ist nicht "WordPress". Sie ist WordPress plus Theme plus zwanzig oder vierzig Plugins von ebenso vielen Autoren, auf geteiltem Hosting, mit einem Adminzugang, den über die Jahre mehrere Leute benutzt haben. Ihre Sicherheit ist die Sicherheit des schwächsten Teils und desjenigen Autors, der als Letzter patcht.

PHP2Shell ist noch einmal eine andere Art Problem. Die Lücke steckt in keinem Plugin, sondern in der Sprache, auf der alle diese Teile laufen. Eine WordPress Seite trägt also zwei Schichten geteiltes Risiko: die Pluginschicht, die ständig leckt, und die Sprachschicht, die selten leckt, dann aber überall gleichzeitig.

Meine Meinung: Neue geschäftskritische Systeme auf diesem Modell hätten um 2015 aufhören sollen

Hier kommt die Meinung, und es ist meine. Spätestens um 2015 gab es ausgereifte, gut dokumentierte Alternativen, auf denen ernsthafte Unternehmen liefen. Ruby on Rails war damals seit einem Jahrzehnt im Einsatz, und heute nennt die offizielle Rails Seite GitHub, Shopify, Airbnb, Zendesk und 1Password unter den Firmen, die darauf bauen.¹² Ein neues, wichtiges System danach noch auf dem Modell aus PHP und Plugins zu starten, war eine Entscheidung, meist getroffen, weil es schnell und vertraut aussah, nicht weil es das stärkste Fundament für die lange Strecke war.

Das heißt nicht, dass WordPress wertlos wäre oder dass die Leute, die es bauen, schlampig arbeiten. Für eine einfache Visitenkartenseite, die man alle paar Jahre ohnehin neu macht, kann WordPress ein vernünftiges Werkzeug sein. Mein Einwand ist enger. Wenn der Teil deines Geschäfts, der Bestellungen annimmt, Kundendaten hält oder deinen Dienst betreibt, auf einem Stack steht, den das ganze Internet teilt, zusammengesetzt aus Plugins, deren Autoren du nie triffst, dann hängt "sicher" davon ab, dass Dutzende andere Leute rechtzeitig patchen. Eine Woche wie diese ist kein Pech. Es ist die Architektur, die tut, was sie tut.

Kein Stack ist immun, auch meiner nicht

Wer dir erzählt, seine Software sei nicht angreifbar, verkauft dir den nächsten Vorfallbericht. Darum hier die andere Seite.

Rails hatte eigene Sicherheitshinweise, und die JavaScript Welt, in der ich ebenfalls baue, auch. Im Dezember 2025 erlaubte eine Lücke in React Server Components das Ausführen von Code ohne jede Anmeldung, und sie traf Anwendungen, die mit Next.js auf dem neueren Modell für serverseitiges Rendern gebaut waren.¹³ Im März 2025 konnten Angreifer über eine andere Next.js Lücke Berechtigungsprüfungen umgehen, die in der Middleware saßen.¹⁴ Beide waren ernst, und beide mussten sofort gepatcht werden.

Der ehrliche Unterschied ist nicht, dass ein Framework zaubern kann. Er liegt darin, wie viel vom System du mit allen anderen teilst, wie viele Komponenten von Fremden im Weg jeder Anfrage stecken, wie schnell der Eigentümer patchen und neu ausliefern kann und ob jemand hinsieht. Das sind Entscheidungen im Entwurf, und man kann sie auf jedem Stack gut treffen. Mein Argument ist, dass das Pluginmodell es schwer macht, sie gut zu treffen.

Sicher durch Architektur, nicht durch Glück

Sicherheit entscheidet sich vor allem daran, wie etwas gebaut ist, nicht an einem Produkt, das man hinterher anschraubt. Vier Grundsätze leisten den Großteil der Arbeit.

Halte die Angriffsfläche klein. Jedes Plugin, jedes Theme und jede Erweiterung ist eine weitere Tür mit einem Schloss, das jemand anderes eingebaut hat. Eine maßgeschneiderte Anwendung, gebaut für das, was dein Geschäft wirklich tut, hat viel weniger Türen, und wer sie gebaut hat, weiß, wo jede ist.

Gib jedem Teil nur die Rechte, die es braucht. Einbrüche werden schlimmer, wenn eine kompromittierte Komponente alles erreicht. Die PHP Lücken geben dem Angreifer das Konto des Webserver Prozesses, also entscheidet das, was dieses Konto anfassen darf, wie schlimm der Tag wird. Ein Prozess, der seinen eigenen Code nicht ändern und keine Geheimnisse lesen kann, die er nicht braucht, ist eine viel kleinere Beute.

Beobachte die Anwendung im Betrieb. Jede Anwendung, die ich betreibe, hängt an einer Fehlerüberwachung, sodass ein ungewöhnlicher Absturz oder ein seltsames Anfragemuster noch am selben Tag sichtbar wird und nicht erst in der Beschwerde eines Kunden. Die CISA empfahl bei PHP2Shell, auf Webserver Prozesse zu achten, die eine Shell starten. Das geht nur, wenn jemand hinsieht.⁴

Besitze den Code und die Auslieferung. Wenn der Code dir gehört und die Auslieferung automatisiert ist, ist ein Sicherheitsupdate eine Entscheidung, die du heute triffst und heute ausrollst. Ist die Seite ein Turm aus fremden Plugins auf gemietetem Hosting, wartest du auf die Zeitpläne anderer.

Rails hilft bei den Grundlagen von Haus aus. Sein Sicherheitsleitfaden beschreibt einen Schutz gegen gefälschte Formularanfragen, den neue Anwendungen automatisch einschalten, und Abfragemethoden, die Eingaben maskieren, bevor sie die Datenbank erreichen.¹⁵ Das macht eine Rails Anwendung nicht von allein sicher, aber der sichere Weg ist der normale Weg. Auf den Seiten, die ich baue, läuft vor jedem Release eine automatisierte Testsuite, bevor etwas live gehen kann. Wie das aussieht, beschreibe ich im Leitfaden zu TDD und BDD.

Ein durchgerechnetes Beispiel: ein Grazer Shop am Morgen nach der Warnung

Nimm ein erfundenes Geschäft: Murufer Keramik in Graz, muruferkeramik.example, das handgemachtes Geschirr über WordPress und WooCommerce auf geteiltem Hosting verkauft. Die Seite hat 27 aktive Plugins, darunter ein Zahlungsmodul, einen Buchungskalender für Töpferkurse und einen Pagebuilder.

Am Morgen des 22. Oktober meldet sich die Inhaberin im Hostingpanel an und sieht: Die Seite läuft auf PHP 8.1. Für diesen Zweig liefert das PHP Projekt keine Korrekturen mehr, es gibt also nichts einzuspielen, und die CISA rät bei 8.1 oder älter, das System offline zu nehmen, bis es aktualisiert ist.⁴¹⁰ Der Hoster bietet PHP 8.3 an, aber der Pagebuilder wurde seit zwei Jahren nicht mehr aktualisiert, und niemand weiß, ob er darauf läuft.

Die vernünftige Reihenfolge ist die aus den Warnungen. Erstens herausfinden, ob schon etwas passiert ist: beim Hoster die Zugriffsprotokolle seit dem 21. Oktober und einen Scan der Dateien auf kürzlich hinzugefügte Dateien anfordern. Zweitens den Shop in den Wartungsmodus schalten, auf die gepatchte 8.3.36 wechseln und Kasse, Zahlung und Buchungskalender auf einer Kopie testen, bevor er wieder öffnet. Drittens den verwaisten Pagebuilder und jedes Plugin entfernen, für das niemand einen Grund nennen kann. Wenn das zwei Tage dauert, sind das zwei Tage ohne Bestellungen, deutlich weniger als der Schaden einer abgeschöpften Kasse.

Die größere Frage kommt, wenn das Feuer aus ist. Für Murufer Keramik ist der Shop das Geschäft. Ein Shop, der vom Netz muss, weil ein Designplugin ein Update der Sprache blockiert, sagt der Inhaberin etwas.

Die rechtliche Rechnung, wenn Kundendaten abgeflossen sind

Nach der technischen Rechnung kommt eine zweite. Hat ein Angreifer Kundendaten erreicht, ist das eine Verletzung des Schutzes personenbezogener Daten. Nach Artikel 33 DSGVO musst du sie innerhalb von 72 Stunden, nachdem sie dir bekannt wurde, der zuständigen Aufsichtsbehörde melden, außer sie führt voraussichtlich nicht zu einem Risiko für die Betroffenen.¹⁶ Für ein Unternehmen in Österreich ist das die Datenschutzbehörde in Wien. Nach Artikel 83 reichen die Bußgelder der oberen Stufe bis 20 Millionen Euro oder 4 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.¹⁷ Ein gehackter Shop ist also nicht nur ein IT Problem.

Was ich stattdessen baue

Nichts davon heißt, dass jedes Unternehmen maßgeschneiderte Software braucht. Es heißt, dass die Systeme, mit denen du dein Geld verdienst, ein Fundament verdienen, das du kontrollierst. Auf Ruby on Rails baue ich drei Dinge.

• Einen eigenen Onlineshop auf Solidus und Rails, einem Open Source Framework für eCommerce, bei dem der für dich geschriebene Code mit vollständiger Bezahlung dir gehört und kein Template ist, das deine Mitbewerber auch nutzen.
• Ein SaaS Produkt, dessen Datenmodell, Abrechnung und Berechtigungen für den tausendsten Kunden ausgelegt sind, nicht nur für die Demo. Braucht ein Produkt eine aufwendige interaktive Oberfläche, setze ich Next.js auf ein Rails Backend.
• Eine Smart Website auf einem Rails Stack statt auf einem Turm aus Plugins, deren Seiten sich an die Kampagne anpassen, über die jemand kommt, und an das, was die Seite rechtmäßig über die Person wissen darf.

Weil diese Systeme eine saubere Programmierschnittstelle haben, kann dasselbe Backend später eine native App versorgen, wie ich im Artikel über API First Solidus erkläre. Das längere Argument, warum ich für langlebige Software Rails statt PHP Frameworks wähle, steht in warum Rapid Development Frameworks PHP langfristig zerstören, der Vergleich mit Next.js im Artikel über die Wahl des Web Frameworks.

Maßgeschneidert heißt nicht langsam. Ich nutze jeden Tag KI, um schneller zu bauen, und ich stehe für jede Zeile ein, die in Produktion geht. Tempo ist nicht das Risiko. Code, den niemand versteht und der niemandem gehört, ist das Risiko.

Wo dich das hinführt

Alle paar Jahre bekommt das geteilte Fundament einen Riss, alle rennen, die Seiten kommen zurück, und alle nehmen sich vor, sich beim nächsten Mal Sorgen zu machen. Zuerst patchen. Das ist das Verantwortungsvolle, und es hat nichts damit zu tun, bei mir etwas zu kaufen. Dann frag dich, ob der Teil deines Geschäfts, der das Geld wirklich einnimmt, weiter auf einem Fundament stehen soll, das das ganze Internet teilt.

Wenn dich diese Woche nervös gemacht hat, ist das ein nützliches Gefühl. Machen wir in einem Gratis Workshop einen Plan daraus.

Footnotes

1. Bundesamt für Sicherheit in der Informationstechnik, PHP: BSI warnt vor kritischen Schwachstellen, Pressemitteilung, 21. Oktober 2026, https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2026/261021_PHP-kritische-Schwachstelle.html

2. Europäische Kommission, ENISA, CERT-EU, Europol EC3 und CSIRTs Network, Joint statement on critical PHP vulnerabilities, 21. Oktober 2026, https://enisa.europa.eu/news/joint-statement-on-critical-php-vulnerabilities

3. National Cyber Security Centre (UK), Critical security issue affecting PHP, 21. Oktober 2026, aktualisiert am 23. Oktober 2026, https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php

4. CISA, Critical vulnerabilities in PHP require immediate patching, 21. Oktober 2026, https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching

5. CISA, Known Exploited Vulnerabilities Catalog, CVE-2026-109618 und CVE-2026-109619 aufgenommen am 26. Oktober 2026, https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-109618

6. PHP Group, RCE via OOM corruption, Security Advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618), 21. Oktober 2026, https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w

7. NIST National Vulnerability Database, CVE-2026-109618 und CVE-2026-109619, https://nvd.nist.gov/vuln/detail/CVE-2026-109618 und https://nvd.nist.gov/vuln/detail/CVE-2026-109619

8. W3Techs, Usage statistics and market share of WordPress, 11. November 2026, https://w3techs.com/technologies/details/cm-wordpress

9. W3Techs, Usage statistics of PHP for websites, 11. November 2026, https://w3techs.com/technologies/details/pl-php

10. PHP Group, Supported versions, https://www.php.net/supported-versions.php

11. Patchstack, State of WordPress Security in 2026, https://patchstack.com/whitepaper/state-of-wordpress-security-in-2026/

12. Ruby on Rails, offizielle Seite (Firmen, die Rails nutzen), https://rubyonrails.org/

13. NIST National Vulnerability Database, CVE-2025-55182 (React Server Components), veröffentlicht am 3. Dezember 2025, https://nvd.nist.gov/vuln/detail/CVE-2025-55182

14. NIST National Vulnerability Database, CVE-2025-29927 (Next.js Middleware), veröffentlicht am 21. März 2025, https://nvd.nist.gov/vuln/detail/CVE-2025-29927

15. Rails Guides, Securing Rails Applications, https://guides.rubyonrails.org/security.html

16. Verordnung (EU) 2016/679 (DSGVO), Artikel 33, EUR-Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679

17. Verordnung (EU) 2016/679 (DSGVO), Artikel 83 Absatz 5, EUR-Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679