Manchmal liest man einen Artikel und denkt nach dem ersten Absatz: Genau so ist es. So ging es uns mit Climate Change in PHP von Michael Kraft. Der Senior Developer hat am Abend des großen PHP Security Releases vom 21. Oktober 2026 aufgeschrieben, was viele in der Szene gerade spüren. Die aktuellen Lücken sind mehr als ein weiteres Update. Sie verändern die Bedingungen, unter denen PHP Software betrieben wird.
Wir stellen seine Gedanken hier vor, ordnen sie ein und sagen ganz offen: Wir stimmen ihm in fast allem zu. Lest den Originalartikel unbedingt selbst, er lohnt sich.
Euer Legacy Projekt blockiert das Update?
Wir helfen, die Blocker zu finden, das System abzusichern und einen Weg auf eine PHP Version mit Support zu planen.
Was Michael Kraft mit Klimawandel in PHP meint
Ausgangspunkt sind die beiden kritischen Lücken, die das PHP Team mit den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 geschlossen hat. Kraft betont, dass das Problem weit über die aktuellen Versionen hinausgeht. Auch Zweige ohne Support sind betroffen. Damit geraten gleich mehrere Generationen von Software unter Druck, die sich in Jahrzehnten PHP angesammelt haben.
Sein Bild dafür ist der Klimawandel. Die Umgebung verändert sich, und zwar auch für Systeme, deren Betreiber schon vor Jahren aufgehört haben, mit Veränderung zu rechnen. Diesen Vergleich finden wir sehr treffend. Software, die nur deshalb läuft, weil niemand sie anfasst, lebt in einem Gleichgewicht, das von außen jederzeit kippen kann.
Auffällig ist, wie differenziert Kraft bleibt. Er schreibt ausdrücklich, dass nicht jede Installation gleich leicht angreifbar ist. Und er stellt klar, dass erfolgreicher fremder Code zunächst nur die Rechte des Web Workers hat, nicht automatisch Root Rechte. Diese Genauigkeit fehlt in vielen Meldungen der letzten Tage. Wie gefährlich es trotzdem ist, zeigt seine Einordnung: Der Angriff kann bei mod_php starten, bevor die Anwendung läuft, PHP-FPM muss ebenso geprüft werden, und laut watchTowr und CERT-EU sind Angriffe und öffentliche Proof of Concepts bereits im Umlauf. Warten hat damit einen konkreten Preis.
Legacy Software ist jetzt eine Entscheidung
Der stärkste Teil des Artikels ist für uns der Blick auf Legacy. Kraft beschreibt Situationen, die jeder aus der Praxis kennt. Ein verlassenes Plugin verhindert das Upgrade. Eine Bibliothek ohne Pflege hält eine wichtige Funktion zusammen. Und an den Server traut sich niemand ran, weil keiner weiß, was dann bricht. Sein Fazit bringt es auf den Punkt: „It still works“ is no longer a maintenance strategy.
Wichtig ist uns, was Kraft nicht sagt. Er erklärt alten Code nicht pauschal zu Müll. Wartbare Software kann viele Jahre wertvoll bleiben. Abhängigkeiten, die einen sicheren Betrieb verhindern, brauchen aber jetzt einen Verantwortlichen und eine Entscheidung: reparieren, ersetzen oder abschalten. Aufräumen wird damit vom netten Vorhaben zur echten Betriebsaufgabe.
Genau diese Haltung vertreten wir auch. Wir raten bei alten Projekten dazu, nicht dauerhaft im Legacy weiterzuflicken. Besser ist ein sauberer Weg heraus, abgesichert durch Characterization Tests und schrittweise umgesetzt, etwa nach dem Strangler Fig Pattern.
Erst patchen, dann die Blocker entfernen
Bei der Reihenfolge ist Kraft sehr pragmatisch. Zuerst wird das laufende System abgesichert. Ein Patch innerhalb eines unterstützten Zweigs ist dabei etwas anderes als die Migration auf eine neue PHP Version. Für ältere Installationen können Backports von Anbietern helfen. Wo gar kein Patch möglich ist, verweist er auf CERT-EU und die Empfehlung, die Systeme vom öffentlichen Netz zu trennen. Konfigurationstricks allein schließen die Lücken nicht.
Danach kommt der Teil, den wir besonders mögen. Kraft schlägt vor, das Update als Inventur zu nutzen. Es zeigt, wo undokumentierte Dienste laufen, wo alte Images stehen, wo Tests fehlen und welche Abhängigkeiten niemand mehr pflegt. Sein Rat ist bewusst klein gehalten: einen Blocker entfernen, einen Verantwortlichen festlegen, einen überflüssigen Dienst abschalten. Die Lücke räumt nicht für uns auf, aber sie holt liegen gebliebene Wartung endlich aus dem Backlog.
Wie das Patchen konkret abläuft, inklusive Docker, PECL und alten Versionen, haben wir in unserer Anleitung zur PHP Sicherheitslücke Oktober 2026 zusammengefasst. Was technisch hinter dem Angriff steckt, steht im Beitrag zum PHP2Shell Exploit.
Ein System kann korrekt konfiguriert und trotzdem verwundbar sein
Ein Gedanke aus dem Artikel bleibt besonders hängen. Kraft vergleicht mit Kubernetes, das laufende Infrastruktur ständig mit einem beschriebenen Sollzustand abgleicht. Tools wie Dependabot bringen dieses Bewusstsein für Updates bereits in den Code. Was fehlt, ist die Verbindung über die gesamte Umgebung: verwundbare Komponenten erkennen, den Sollzustand anpassen, neu testen, ausrollen und das Ergebnis prüfen.
Sein Punkt ist unbequem und richtig. Ein System kann exakt seiner Konfiguration entsprechen und trotzdem angreifbar sein, wenn diese Konfiguration veraltete Software festschreibt. Ein grüner Deploy sagt also nichts über Sicherheit aus. Für uns heißt das: Automatische Update Vorschläge, zum Beispiel mit Renovate, gehören zusammen mit PHPUnit, PHPStan und Composer Audit in jede Pipeline.
Was ein gehackter PHP Server anrichten kann
Zum Schluss beschreibt Kraft zehn mögliche Folgen eines erfolgreichen Angriffs. Er betont dabei, dass es um mögliche Szenarien geht, nicht um bestätigte Fälle dieser konkreten Lücken. Was tatsächlich passiert, hängt von Rechten, Zugangsdaten und Netzwerkzugriff des Servers ab.
Uns gefällt, dass er den Blick vom eigenen Server auf andere Menschen lenkt. Eine vertrauenswürdige Website kann zur Falle für Besucher werden, mit Weiterleitungen, gefälschten Login Seiten oder manipulierten Downloads. Der Server selbst kann für fremde Zwecke arbeiten, etwa in einem DDoS Botnetz, als Proxy für Kriminelle, zum Kryptomining oder für Spam. Und es geht um Vertrauen: Spam Seiten im eigenen Auftritt, falsche Meldungen auf einer offiziellen Website oder gestohlene Secrets, mit denen sich Angreifer als Nutzer ausgeben.
Seine Schlussbemerkung ist bewusst nüchtern. Für keines dieser Szenarien braucht es künstliche Intelligenz. Die Lücke ist nur der Eingang, alles Weitere entscheidet sich an den Rechten und Zugängen, die der Webserver hat. Ein starkes Argument dafür, Rechte knapp zu halten und Secrets nach einem Vorfall konsequent zu rotieren. Den Rahmen dafür liefern die OWASP Top 10.
Danke, Michael Kraft
In Tagen wie diesen gibt es viele hektische Meldungen und wenig Einordnung. Michael Kraft hat beides verbunden: klare Fakten mit sauberen Quellen, ehrliche Grenzen dessen, was man weiß, und einen Gedanken, der über das aktuelle Update hinausreicht. Dafür ein herzliches Danke von uns.
Wir sehen es genau wie er. Die Lücken sind ein Anlass, endlich aufzuräumen. Wer jetzt nur patcht und dann weitermacht wie bisher, steht beim nächsten Klimaereignis wieder am selben Punkt. Lest den vollständigen Artikel von Michael Kraft auf Medium und teilt ihn mit eurem Team.
Raus aus dem Legacy, rein in den sicheren Betrieb
Wir finden mit euch die Blocker in alten PHP Projekten, sichern das Verhalten mit Tests ab und bauen einen Weg auf eine Version mit Support. Mit einer Pipeline, die das nächste Update zur Routine macht.
Das Kennenlernen ist kostenlos. Danach schätzen wir den Aufwand und rechnen transparent nach Minuten ab.
