PHP hat das Internet schon wieder lahmgelegt. Warum WordPress 2015 in Rente gehört hätte, und was du stattdessen bauen solltest
Wenn deine Website auf WordPress, Joomla, TYPO3 oder einem anderen PHP System läuft, ist das dringend. Am 21. Oktober 2026 warnte das britische National Cyber Security Centre vor zwei kritischen Lücken in PHP, die einem Angreifer einen direkten Weg zu den Dateien und zur Datenbank deines Servers geben können, ohne Passwort und ohne Login. Jede PHP Version ist betroffen, und der offizielle Rat ist unmissverständlich: sofort patchen, und wenn du nicht kannst, die Website offline nehmen. Allein WordPress betreibt rund vier von zehn Websites weltweit, und es läuft auf PHP. Hier ist die Version in einfachen Worten: was das Risiko wirklich ist, warum demselben Stack immer wieder dasselbe passiert, und die moderne, sichere Alternative, die dir gehört und die ich stattdessen baue.
Wenn du WordPress, Joomla oder TYPO3 betreibst, lies das heute
Zuerst die Kurzfassung, dann die Details. WordPress, Joomla, TYPO3, Drupal, Magento und die meisten Buchungs und Shop Plugins, die du nennen kannst, sind alle auf PHP gebaut. Am 21. Oktober 2026 hat das britische National Cyber Security Centre eine kritische Warnung zu zwei Lücken in PHP selbst herausgegeben, CVE-2026-109618 und CVE-2026-109619. Weil die Lücke in PHP steckt, ist jedes dieser Systeme betroffen, nicht nur die alten. Die Warnung sagt klar: jede PHP Version ist betroffen.
Was wirklich passieren kann, in einfachen Worten: ein Angreifer bekommt einen direkten Weg zu den Dateien und zur Datenbank deines Servers. Er kann eigene Befehle ausführen, deine Daten lesen oder stehlen und deine Seite verändern, ohne Passwort und ohne Login. In der Praxis heißt das gestohlene Kundendaten, eine gekaperte oder verunstaltete Website, Ransomware, oder ein Shop, der still Kartendaten an deiner Kasse abgreift. Wenn du nicht sofort aktualisieren kannst, lautet der offizielle Rat, das System offline zu nehmen, bis es behoben ist. Eine nationale Cyberbehörde, die Unternehmen rät, der eigenen Website den Stecker zu ziehen, ist so ernst, wie diese Warnungen werden. Nach der technischen Rechnung kommt eine zweite. Wenn Kundendaten abfließen, ist das eine meldepflichtige Datenpanne. Nach der UK GDPR und der EU DSGVO kannst du verpflichtet sein, die Behörde innerhalb von 72 Stunden zu informieren und die Betroffenen zu benachrichtigen, und die Bußgelder reichen bis zum Höheren von 20 Millionen Euro oder 4 Prozent deines weltweiten Umsatzes. Eine gehackte WordPress Seite ist nicht nur ein IT Problem, sondern ein rechtliches und finanzielles.
Wenn das deine Website ist, patch sie heute. Dann lies weiter, denn diese eine Lücke zu patchen behebt nicht den Grund, warum es immer wieder passiert.
Der Morgen, an dem der offizielle Rat lautete: "Nimm deine Website offline"
Am 21. Oktober 2026 veröffentlichte das britische National Cyber Security Centre eine Warnung zu PHP, der Programmiersprache, die still einen großen Teil des Internets betreibt. Die Kernaussage war unmissverständlich. Die Lücken könnten es Angreifern erlauben, "Befehle auf jedem Webserver auszuführen, der PHP betreibt", und unter den falschen Bedingungen bedeutet das Codeausführung aus der Ferne, ganz ohne Anmeldung. In einfachen Worten: ein Fremder könnte deinen Server tun lassen, was er will, ohne Passwort, ohne Login, ohne dass du es merkst.
Was aus einer normalen Patch Meldung eine schlechte Woche für viele IT Teams machte, war ein Satz: "Organisationen, die irgendeine Version von PHP nutzen, sind betroffen." Nicht nur die alten, vernachlässigten Seiten. Jede Version. Und die empfohlenen Maßnahmen enthielten eine Zeile, die man in offiziellen Hinweisen fast nie liest: wer nicht schnell aktualisieren oder absichern kann, solle "erwägen, das System offline zu nehmen, bis es vollständig abgesichert ist".
Lies das noch einmal. Die nationale Cyberbehörde hat Organisationen gesagt, dass es eine vernünftige Option sei, der eigenen Website den Stecker zu ziehen. So ernst war diese Sache.
Was wirklich passiert ist, in einfachen Worten
Die beiden Probleme tragen die Katalognummern CVE-2026-109618 und CVE-2026-109619. Du brauchst die Interna nicht, aber die Form lohnt sich zu verstehen, weil sie erklärt, warum der Fix dringend ist.
Beide sind Fehler im Umgang mit dem Speicher. Der eine passiert, wenn PHP im falschen Moment der Speicher ausgeht und es dann halbfertige, ungültige Daten so behandelt, als wären sie gültig. Der andere ist übrig gebliebener Zustand: Informationen aus der Anfrage eines Besuchers können in einem geteilten Arbeiter hängen bleiben und von der nächsten Anfrage aufgegriffen werden, bevor sie bereinigt sind. Wenn man ein Programm dazu bringt, Speicher zu nutzen, dem es nicht trauen sollte, kann man es manchmal dazu lenken, die eigenen Anweisungen statt seiner auszuführen. Das ist der Weg von "ein seltsamer Absturz" zu "Codeausführung aus der Ferne".
PHP hat ein Sicherheitsupdate und einige Härtungsschritte veröffentlicht. Die ehrliche Zusammenfassung für einen Unternehmer ist einfach. Wer irgendetwas auf PHP betreibt, musste sofort patchen, und wer nicht schnell patchen konnte, dem riet die offizielle Empfehlung, es abzuschalten oder zu isolieren und zu prüfen, ob schon jemand drin war.
Warum "jede Version" das beängstigende Wort ist
Die meisten Sicherheitsgeschichten handeln von einem Produkt mit einem Fehler. Das hier ist anders, und dieser Unterschied ist der ganze Punkt dieses Artikels.
PHP betreibt die Mehrheit der Websites auf dem Planeten, deren Serversprache bekannt ist. WordPress, das auf PHP gebaut ist, läuft auf rund vier von zehn aller existierenden Websites. Rechne die Shop Plugins dazu, die Buchungssysteme, die Mitglieder Tools, die unzähligen Appliances und Systemsteuerungen, die PHP still in sich tragen, und du blickst auf einen riesigen Teil des Webs, der dasselbe Fundament teilt.
Wenn alle auf demselben Fundament bauen, ist ein einziger Riss nicht dein Problem, sondern im selben Augenblick das Problem aller. Angreifer wissen das. Innerhalb von Stunden nach so einer Warnung durchsuchen automatisierte Werkzeuge das gesamte Internet nach Servern, die noch nicht gepatcht haben. Du wirst nicht ins Visier genommen, weil jemand dein Geschäft hasst. Du wirst getroffen, weil ein Skript deine Adresse gefunden hat und dein Server geantwortet hat. Monokultur ist effizient, und genau deshalb kann eine PHP Lücke Tausenden Firmen parallel die Woche ruinieren.
Der Teil, den beim WordPress Stammtisch niemand hören will
Hier ist die unbequeme Meinung, und ich stehe dazu. PHP und WordPress hatten ihren Moment, und dieser Moment ist lange her. Um etwa 2015 waren die modernen Alternativen reif, erprobt und betrieben ernsthafte Unternehmen. Danach noch neue, wichtige Systeme auf dem PHP und Plugin Modell zu bauen, war eine Entscheidung, meist getroffen, weil es schnell und vertraut aussah, nicht weil es das richtige Fundament für die lange Sicht war.
Ich will fair sein, denn Fairness überzeugt mehr als eine Schimpftirade. Millionen WordPress Seiten laufen vollkommen in Ordnung. Für eine einfache Visitenkartenseite kann es ein sinnvolles Werkzeug sein. Das Problem ist nicht, dass man PHP schlecht schreiben kann. Jede Sprache kann man schlecht schreiben. Das Problem ist das Modell, das darum gewachsen ist: ein geteilter Stack, den das ganze Internet gleichzeitig betreibt, eine Website zusammengenäht aus vierzig Plugins von vierzig Fremden, denen du nie begegnen wirst, laufend auf gemietetem Hosting, das dir nicht wirklich gehört, wo "sicher" davon abhängt, dass Dutzende andere rechtzeitig patchen. Das ist kein Fehler, den du beheben kannst. Das ist die Architektur.
Wenn also eine PHP Lücke, wie sie nur alle paar Jahre auftritt, einschlägt und der offizielle Rat lautet "erwäge, deine Seite offline zu nehmen", ist die richtige Frage nicht "wie schnell können wir patchen". Die richtige Frage ist "warum steht mein Geschäft noch auf einem Fundament, das sich das ganze Internet teilt".
Sicher durch Architektur, nicht durch Glück
Sicherheit ist kein Produkt, das man am Ende dranschraubt. Sie wird meist dadurch entschieden, wie etwas gebaut ist. Ein paar Prinzipien trennen Software, die durch ihr Design sicher ist, von Software, die nur bis zur nächsten geteilten Lücke sicher ist.
Halte die Angriffsfläche klein. Jedes Plugin, jedes Theme, jeder Anbau ist eine weitere Tür mit einem weiteren Schloss, das eine weitere Person eingebaut hat. Eine maßgeschneiderte Anwendung für genau das, was dein Geschäft tut, hat weit weniger Türen, und ich weiß, wer jede einzelne eingebaut hat.
Gib jedem Teil nur so viele Rechte, wie es braucht. Die meisten echten Einbrüche werden schlimmer, weil eine kompromittierte Komponente alles andere erreichen konnte. Gute Architektur schottet ab, damit ein Problem an einer Stelle nicht in deine Datenbank und deine Kundendaten spazieren kann.
Beobachte sie im Betrieb. Jede App, die ich betreibe, ist mit einer Live Fehlerüberwachung verbunden. In dem Moment, in dem ein einziger Nutzer auf ein Problem stößt, weiß ich welche Seite, welche Aktion und wo im Code, statt auf eine Email zu warten, die mit "es funktioniert nicht" beginnt. Stille Software ist nicht sichere Software, sie ist Software, die niemand ansieht.
Besitze den Code. Wenn die Arbeit maßgeschneidert ist und der Code dir gehört, ist ein Fix eine Entscheidung, die du heute treffen kannst. Wenn deine Seite ein Turm aus den Plugins anderer Leute ist, wartest du auf die Release Pläne anderer Leute, während die Uhr läuft.
Warum ich auf Ruby on Rails baue
Nichts davon heißt, dass ein modernes Framework Magie oder unhackbar wäre. Kein Stack ist das. Wer dir erzählt, seine Software könne nicht eingebrochen werden, verkauft dir den nächsten Vorfallsbericht. Die ehrliche Aussage dreht sich um die Schadensreichweite, den Besitz, die Wartung und darum, dass eine benannte Person dafür geradesteht.
Ich baue auf Ruby on Rails, weil es ein reifes, ernsthaftes Framework ist, bei dem gute Sicherheitsgewohnheiten in die Arbeitsweise eingebaut sind, nicht nachträglich drangeschraubt. Schutz gegen die klassischen Webangriffe ist der Standard, die Konventionen schieben dich zum sicheren Weg, und dasselbe Framework betreibt einige der anspruchsvollsten Unternehmen im Netz. Shopify, das einen sehr großen Teil der weltweiten Online Käufe abwickelt, läuft auf Rails. GitHub, wo der Großteil des Codes der Welt liegt, läuft auf Rails. Das ist kein Spielzeug für Hobbyisten.
Auf diesem Fundament baue ich drei Dinge für Kunden:
- Einen eigenen Onlineshop, der wirklich dir gehört, gebaut auf Solidus und Ruby on Rails, statt eine Themenvorlage zu mieten, die jeder Mitbewerber auch nutzt und die kaputt geht, wenn ein geteiltes Plugin es tut.
- Ein SaaS Produkt, das hält, mit Datenmodell, Abrechnung und Sicherheit durchdacht für den tausendsten Nutzer, nicht nur für die Demo.
- Eine moderne Website, die schnell und von Haus aus sicher ist, kein Haufen Plugins, zusammengehalten mit Hoffnung.
Maßgeschneidert heißt nicht langsam oder teuer. Ich nutze KI jeden Tag, um schneller und zu einem niedrigeren Preis zu bauen, und ich stehe für jede Zeile gerade, die in Produktion geht. Tempo ist nicht das Risiko. Code auszuliefern, den niemand versteht und niemand besitzt, ist das Risiko.
Und es kommt mit einer nativen App, nicht mit einem mobilen Nachgedanken
Hier ist der Teil, den die meisten Webbuden nicht anbieten können. Weil ich den Kern deines Produkts richtig baue, mit einem sauberen Weg für andere Software, mit ihm zu sprechen, kann dasselbe Produkt mit einer echten nativen iOS und Android App ausgeliefert werden. Eine Codebasis, beide App Stores, deine Marke in der Hosentasche deiner Kunden, auf demselben sicheren Backend wie deine Website. Das ist kein Plugin. Das ist ein Produkt.
Eine WordPress Seite kann dir das nicht geben. Eine maßgeschneiderte Anwendung schon, und wenn du sie ohnehin richtig baust, ist die App ein Schritt, keine Rettungsaktion.
Was du diese Woche tun solltest, egal ob du mich je beauftragst
Wenn du irgendetwas auf WordPress oder PHP betreibst, ist das die praktische Liste, direkt aus der offiziellen Empfehlung.
- Finde jedes PHP System, das du hast, zuerst alles, was zum Internet zeigt, inklusive Shop Plugins, Buchungstools und jeder Appliance, die PHP in sich trägt.
- Aktualisiere jetzt auf die gepatchte Version. Wenn du nicht kannst, wende die offiziellen vorübergehenden Absicherungen an, und wenn du auch das nicht schnell kannst, nimm das System offline, bis du es kannst.
- Nimm nichts an. Wenn ein System ungepatcht und exponiert war, prüfe es auf Spuren einer Kompromittierung und versteckte Hintertüren, bevor du ihm wieder traust. Wenn das dein Team übersteigt, nutze einen geprüften Dienstleister für die Vorfallsreaktion.
Mach das zuerst. Es ist das Verantwortliche und hat nichts damit zu tun, etwas bei mir zu kaufen.
Dann, wenn das Feuer gelöscht ist, stelle die größere Frage. Ist gemietete Software auf geteiltem Stack noch das richtige Fundament für den Teil deines Geschäfts, der tatsächlich Geld verdient. Für viele Firmen ist die ehrliche Antwort nein, und diese Woche war die Erinnerung daran.
Wo dich das zurücklässt
Alle paar Jahre bricht das geteilte Fundament, alle hetzen, die Seiten kommen zurück, und wir einigen uns darauf, uns beim nächsten Mal zu sorgen. Du musst nicht in diesem Kreislauf leben. Du kannst die wichtigen Teile deines Geschäfts auf Software bauen, die maßgeschneidert ist, von Grund auf sicher, aktiv beobachtet, dir gehörend und bereit für das Web und eine native App zugleich.
Wenn dich diese Woche nervös gemacht hat, ist das ein nützliches Gefühl. Machen wir einen Plan daraus.