Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Sicherheitslücken geschlossen — einen Tag früher als geplant. Wir haben unsere Hosting-Kunden informiert, bevor die Schlagzeilen kamen, und am selben Abend alle Server gepatcht. Hier erzählen wir, wie das ablief und warum es für die meisten unserer Kunden ein ganz normaler Mittwoch war.
Was passiert ist
PHP ist die Programmiersprache, auf der TYPO3 läuft — und auf der grob 60% aller Webanwendungen weltweit aufbaut. Sie arbeitet auf dem Server und baut bei jedem Aufruf die Seite zusammen, die im Browser landet. Eine Lücke in PHP betrifft deshalb nicht eine einzelne Website, sondern potenziell jede, die darauf aufsetzt.
Am 21. Oktober 2026 um 16:00 Uhr deutscher Zeit hat das PHP-Projekt die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Sie schließen zwei kritische Lücken in der Speicherverwaltung und Fehlerbehandlung von PHP (CVE-2026–109618 und CVE-2026–109619). Im schlimmsten Fall erlauben sie Remote Code Execution — also das Ausführen von fremdem Code auf dem Server.
Eigentlich war der Release für den 22. Oktober geplant. Weil die CVE-Nummern am Nachmittag des 20. Oktober vorzeitig im Netz kursierten, zog das PHP-Team ihn um einen Tag vor. Mit den Nummern machte auch ein falscher CVSS-Score von 10.0 die Runde. CVSS ist die gängige Skala, mit der Sicherheitslücken nach ihrer Schwere bewertet werden — von 0 bis 10, wobei 10 das Maximum ist. Der tatsächliche Wert liegt bei 9.2: kritisch, aber nicht ganz so dramatisch, wie es die ersten Posts nahelegten. Technische Details sind laut PHP Foundation nicht durchgesickert.
Kritisch war das trotzdem. Aber genau in solchen Momenten zeigt sich, ob ein Team vorbereitet ist.
24h früher: Einschätzung auf der Open Source CMS Conference
Als die ersten Meldungen auftauchten, waren wir gerade auf der Open Source CMS Conference 2026 in Utrecht. Das Thema war sofort Gespräch in den Pausen und auf den Fluren. Und weil dort viele Leute zusammenkommen, die sich täglich mit Sicherheit in Open-Source-Projekten beschäftigen, konnten wir die Lage direkt mit ihnen einordnen.
Einer meiner Gesprächspartner war John Blackbourn, der seit vielen Jahren im Security-Team von WordPress mitarbeitet und dort selbst zahlreiche Sicherheitsreleases begleitet hat. Gerade dieser Blick von außen — aus einem anderen großen PHP-basierten CMS — hat uns geholfen, die Lage nüchtern einzuschätzen.
Die Einschätzung vor Ort war ziemlich einhellig: ernst nehmen, aber nicht in Panik verfallen. Ein Patch war angekündigt, ein funktionierender Exploit war nicht bekannt, und der dramatische CVSS-Score aus den ersten Posts war mit Vorsicht zu genießen. Entscheidend würde sein, wie schnell nach dem Release gepatcht wird — nicht, wie laut im Vorfeld darüber geschrieben wird.
Für uns war damit klar: Wir warten nicht ab, bis unsere Kunden die Schlagzeilen lesen.
Erst informieren, dann patchen
Noch am selben Tag haben wir entschieden, alle Hosting-Kunden proaktiv anzuschreiben. Der Gedanke dahinter: Wer von einer kritischen Lücke zuerst über einen Newsticker erfährt, fängt an zu spekulieren. Ist meine Website betroffen? Muss ich jetzt etwas tun? Wer kümmert sich?
Diese Fragen wollten wir beantworten, bevor sie jemand stellen muss. In unserer ersten Nachricht stand deshalb kurz und klar:
- was passiert ist und wie wir es einschätzen,
- dass ein offizieller Fix angekündigt ist,
- dass wir die Server unserer Kunden direkt nach Veröffentlichung patchen,
- und dass niemand selbst aktiv werden muss.
Keine Alarmstimmung, kein Fachchinesisch — sondern die Sicherheit, dass das Thema bei uns in guten Händen ist.
Ein klarer Plan: wer, wann, welcher Server
Parallel zur Kundeninfo haben wir intern einen Actionplan aufgestellt. Für jeden Server, den wir betreuen, stand fest, wer ihn patcht und in welchem Zeitfenster. So mussten wir nach dem Release nichts mehr absprechen, sondern konnten sofort loslegen.
Der Plan beantwortete im Kern vier Fragen:
- Wer? Feste Zuständigkeiten pro Server und Kunde — kein „Das macht bestimmt jemand anders“.
- Wann? Eine Reihenfolge nach Kritikalität: öffentlich erreichbare Systeme mit viel Traffic zuerst.
- Wie? Ein abgestimmtes Vorgehen fürs Einspielen der neuen PHP-Version und den anschließenden Funktionstest.
- Was, wenn? Ansprechpartner für Sonderfälle, falls ein System nicht wie erwartet reagiert.
So ein Plan entsteht nicht aus dem Nichts. Viele Unternehmen wissen gar nicht, wo welche Server mit welcher PHP-Version laufen. An einem Tag wie diesem müssen sie erst einmal Bestandsaufnahme machen — während die Uhr tickt. Bei b13 stellt sich diese Frage nicht: Wir kennen jedes System, das wir betreuen, und unsere Kunden sind jederzeit in guten Händen. Und der Plan funktioniert, weil wir als Team seit Jahren eng zusammenarbeiten, unsere Infrastruktur kennen und wissen, wer sich wo am besten auskennt.
Release um 16 Uhr, Entwarnung am frühen Abend
Am 21. Oktober um 16:00 Uhr war der Fix da. Ab diesem Moment lief unser Plan: Server für Server wurde aktualisiert, getestet und abgehakt. Jeder wusste, was zu tun war — Rückfragen gab es kaum.
Im Laufe des frühen Abends haben wir dann alle Kunden ein zweites Mal informiert: Die neue PHP-Version ist eingespielt, die Websites laufen, es besteht kein Handlungsbedarf. Zwei kurze Nachrichten, ein ruhiger Nachmittag — und ein Thema weniger auf dem Tisch unserer Kunden.
Warum das für fast alle unsere Kunden kein Problem war
Ein PHP-Update klingt einfach. Ob es das auch ist, hängt davon ab, wie aktuell der Rest des Projekts ist. Eine TYPO3-Installation, die seit Jahren nicht angefasst wurde, hängt oft an einer alten PHP-Version. Dann wird aus einem Sicherheitspatch schnell ein Upgrade-Projekt — und zwar genau dann, wenn die Zeit am knappsten ist.
Bei fast allen unseren Hosting-Kunden war das nicht der Fall. Viele von ihnen nutzen unseren Evergreen Service: Wir halten ihre TYPO3-Instanzen kontinuierlich auf dem aktuellen Stand. Und damit automatisch auch die Server- und PHP-Infrastruktur darunter. Als der Patch kam, lief bereits eine unterstützte PHP-Version, und das Update war ein Routineschritt.
Das ist der eigentliche Punkt dieses Tages: Sicherheit entsteht nicht in der Nacht nach einer Schlagzeile. Sie entsteht durch die vielen unspektakulären Updates davor.
Und bei dir?
Lief der Patch-Tag bei deinem Projekt weniger entspannt? Wir kümmern uns um dein Hosting — inklusive Sicherheitsupdates, bevor du danach fragen musst. Und mit unserem Evergreen Service bleibt dein TYPO3 immer auf dem aktuellen Stand, die Technik darunter gleich mit.
Geschrieben von:
