Aktuelle Übersicht über die PHP-Sicherheitslücke 21.10.2026

Stand: 22.10.2026 / 22:28 Uhr / jd 

Generelle Verfügbarkeit

Unser eigene (Verwaltungs)Infrastruktur ist inzwischen auch wieder freigegeben. Damit sollte das Problem, dass bestimmte über den Marktplatz buchbare Erweiterungen nicht automatisch geladen wurden, auch beseitigt sein.

Beim DRKCMS sind im Laufe des Donnerstags einige Installationen auf einen anderen Server umgezogen und werden dort nach und nach in Betrieb gehen. Im Laufe der Nacht zu Freitag sollten nahezu alle SSL-Zertifikate neu ausgestellt und die Seiten wieder online sein.

 

Teilweise sind dafür Ihrerseits DNS-Änderungen nötig. Wenn die Domain bei uns gehostet wird, machen wir das selbst. Bei Domains vom Typ *.brk.de und *.drk.de (in Rheinland-Pfalz) haben die BRK-IT bzw. in Rheinland-Pfalz das ITC/NWE die Änderungen vorgenommen. Wenn Ihre Domain bei einem anderen Provider liegt, müssen Sie die DNS-Änderungen selbst vornehmen, unser System schickt Ihnen die geänderten IP-Adressen per E-Mail. 

Dass u.U. unter dem Domainnamen eine falsche Rotkreuz-Webseite anzeigt ist der Effekt, wenn das SSL-Zertifikat noch fehlt - das Problem sollte sich in den nächsten Stunden von selbst erledigen.

Die PHP-Updates waren zunächst erst ab Version 8.2.x verfügbar, ältere PHP-Versionen gelten weiterhin als angreifbar. Die bisher geleakten Einstiegswege (sog. multipart-POST) rauszufiltern reicht offensichtlich alleine nicht, weshalb Ansätze im Bereich WAF als nicht hinreichend sicher gelten.

Im klassischen Webspace werden wir aller Voraussicht nach alle Web-Pakete zwingend auf die Version 8.2.x anheben. Ggf. braucht Ihre Webanwendung ein Update Ihrerseits. Es gibt erste Backports (also Anpassungen auch für ältere PHP-Versionen), aber noch nicht für die von uns verwendeten Linux-Distributionen. Wir werden im Laufe des Tages prüfen, welche älteren Versionen wir guten Gewissens bereitstellen können und Details nachreichen.

Im DRKCMS ist die 8.2.x kein Problem bei aktuellen v12-Instanzen. Um ältere Versionen wir uns auch hier noch gesondert kümmern. 

Falsche DRK-Webseite online?

Durch den bei einigen Installationen nötigen Umzug müssen auch die SSL-Zertifikate neu ausgestellt werden. Das passiert automatisch, dauert aber etwas. Da wo noch kein Zertifikat ausgerollt wurde, wird beim Aufruf der Webseite eine SSL-Fehlermeldung angezeigt. Wenn man die ignoriert, wird eine andere Rotkreuz-Webseite angezeigt. 

Keine Panik, das Problem löst sich nach einiger Zeit von selber, sobald das Zertifikat ausgestellt wurde

In der Nacht zu Mittwoch hat das Entwicklerteam hinter PHP zwei gravierende Sicherheitslücke bekanntgegeben, die weltweit für Stress sorgt und für die Mittwoch, 21.10.2026 um 16 Uhr deutscher Zeit Updates bereitgestellt werden.

Die Sicherheitslücken werden insgesamt als sehr kritisch eingestuft, auch unser Maßnahmenplan ist ungewöhnlich, wir haben einen Großteil der bei uns betriebenen Webseiten Mittwoch Mittag abgeschaltet und werden (bzw. haben) diese erst nach und nach wieder in Betrieb nehmen (genommen).

   

Die beiden Sicherheitslücken tragen den Spitznamen "php2shell", was quasi bedeutet: Man kann PHP nutzen, um sich darüber eine Shell, also eine "Fernsteuerungs-Konsole" für den Server bereitstellen zu lassen. Dann hat der Angreifer Vollzugriff auf Ihren Webspace. Und wenn die Lücke alle Kunden auf diesem Server betrifft, hat er Vollzugriff auf alle Webspaces.

Betroffen sind nahezu alle im Umlauf befindlichen Versionen von PHP. Und damit rund 70-80% aller Internet-Server weltweit. Betroffen ist der PHP-Kern, d.h. es ist völlig egal, welche PHP-Anwendung Sie einsetzen - Wordpress, TYPO3, Joomla, irgendwas selbtgeschriebenes, irgend ein Framework wie Symfony - und egal, wie aktuell die ist: Der Unterbau ist das Problem.

Die Lücken, technisch korrekt mit den Namen CVE-2026-109618 und CVE-2026-109619 betitelt, sind mit einem Sicherheitsrisiko-Wert von 9,2 eingestuft auf einer Skala von 0 bis 10. Das BSI hat die zweithöchste Gefahrenstufe ORANGE gewählt.

Gar nichts. Nur zur Kenntnis nehmen, dass Ihre Webseite, Ihr ergänzendes Leitstellen- oder Callcenter-System, Ihr Onlineshop, Ihr Account in unserem Kundenmenü, Ihr Webmail-Zugang uvam. zum Zeitpunkt dieses Newsletters für mehrere Stunden offline gehen wird.

Doch, eine Sachen können Sie tun: Uns den Rücken freihalten. Auch bei uns sind dutzende interne Systeme betroffen und teils abgeschaltet oder eingeschränkt erreichbar, und unser Team arbeitet parallel an verschiedenen Baustellen. Je weniger Nachfragen wir bearbeiten müssen, je weniger Telefonanrufe uns aus der Arbeit reißen, desto früher gehen Dienste wieder online und Systemadministratoren ins Bett.

 

Zum einen haben wir uns darauf vorbereitet, ab 16:00 Uhr deutscher Zeit die bereitgestellten Updates zeitnah einzuspielen. Eigentlich aus Sicherheitsgründen werden diese bis dahin zurückgehalten, denn aus den Updates könnte man Details zu den Lücken rauslesen (und ausnutzen). Mit der kontrollierten Veröffentlichung um 16:00 Uhr soll allen Administrator*en die Möglichkeit gegeben werden, sich auf das Update vorzubereiten und es zeitnah auszurollen, bevor die Erkenntnisse ausgenutzt werden können.

Zum anderen haben wir uns die von verschiedenen Quellen bereitgestellten, teils geleakten Informationen zu der Schwachstelle angeguckt und, da wo es möglich war, für jeden Server "einen Plan B" überlegt, z.B. eine vorhergehende Filterung (WAF - Web Application Firewall). Denn es ist nicht klar, für welche insbesondere älteren PHP-Versionen es überhaupt Updates gibt bzw. wie schnell diese bereitgestellt werden. Und es nützt Ihnen wenig, wenn Ihre Webseite unter PHP8 dann um 16:05 Uhr wieder sicher läuft, aber auf dem gleichen Server ein anderer Kunde noch PHP7 einsetzt und es dafür vielleicht noch gar kein Sicherheitsupdate gibt. Wir passen daher die Konfiguration laufend so an, dass die Server irgendwann zwar mit eingeschränkter Funktionalität, aber möglichst bald wieder ans Netz gehen können.

Manche Kunden haben sich (zu recht) gewundert, warum wir sehr viel früher als 16:00 Uhr unsere Server vom Netz genommen haben. Der Grund ist einfach: Es gibt (glaubwürdige) Berichte, dass die Sicherheitslücken bereits geleakt (also ungewollt veröffentlicht) wurden und in der freien Wildbahn ausgenutzt werden. 

Und ob die vorgeschlagenen Schutzmaßnahmen (Servereinstellungen, WAF, ...) etwas nützen oder nicht, das kann man ernsthaft erst nach 16:00 Uhr beurteilen.

Unsere Abwägung war daher "better safe than sorry": Wenn wir die Systeme gegen MIttag schon abschotten, und alles viel harmloser ist als befürchtet, dann sind sie ein paar Stunden länger offline. Schade, aber kein Drama.

Wenn wir aber die Systeme unnötig lange laufen lassen mit Sicherheitslücken, die wir nicht kennen, mit Gegenmaßnahmen, von denen PHP-Profis sagen sie reichen nicht aus, dann riskieren wir, dass jemand sich eine Hintertür eingebaut hat bevor wir Updates einspielen konnten. Und das würde man u.U. erst in einigen Monaten bemerken und könnte einen erheblichen Schaden mit sich bringen.

Ab 16 Uhr wird unser Team einerseits auf den Webservern die bereitgestellten Updates installieren und immer dann, wenn ein Server vollständig abgesichert ist, ihn auf der Firewall wieder "erlauben".

Dabei wird es Produkte geben, die vergleichsweise schnell gehen:

- Aktuelle Produktversionen (beim DRKCMS z.B. die Version 12)

- Server mit generell aktuellen Versionen (im klassischen Webspace z.B. Server mit PHP8-Varianten)

- Und natürlich Systeme, die bei uns eine entsprechend hohe Priorität haben, z.B. im Leitstellenumfeld.

Es wird aber auch Server geben, die erst im Laufe des Oktobers aktualisiert werden können (und so lange offline bleiben). Es wird vielleicht auch Fälle geben (Uralt-Versionen, bei denen wir bereits sehr Jahren auf das Risiko hinweisen, dass dieser Tag kommen könnte), bei denen Sie sich von dieser PHP-Version, diesem Server und/oder z.B. dieser uralten DRKCMS-Version verabschieden müssen.

Wir werden an dieser Stelle hier weitere Infos nach und nach veröffentlichen, sobald wir sie haben. Bis dahin bitten wir Sie um Geduld.

Bitte beachten Sie, dass auch unsere internen Systeme (Kundenmenü, Rechnungssystem, Webmail, ...) von der Abschaltung betroffen sind. Und auch wenn das paradox erscheint: Sie sind nicht die, die als erstes online gehen werden. Gerade aufgrund der Wichtigkeit der Systeme prüfen wir einige Dinge etwas gründlicher, bevor wir damit wieder online gehen.

Bitte haben Sie Verständnis dafür, dass wir für den Rest der Woche jeglichen regulären Support einstellen müssen. Unser gesamtes Team (einschließlich der sich eigentlich im Urlaub befindlichen Kollegen) ist mit der aktuellen Situation beschäftigt.