Was am 20. Oktober bekannt wurde

Am 20. Oktober 2026 wurde durch offizielle Stellen wie das BSI vor zwei kritischen Sicherheitslücken in PHP gewarnt. Die Schwachstellen werden unter den Kennungen CVE-2026-109618 und CVE-2026-109619 (steht für Common Vulnerabilities and Exposures) geführt. Beide ermöglichen unter bestimmten Voraussetzungen die Ausführung von Schadcode auf betroffenen Servern, auch ohne vorherige Anmeldung. Besonders kritisch war in diesem Fall, dass es sich um sogenannte „Zero-Day-Schwachstellen“ handelte. Darunter versteht man Sicherheitslücken, für die zum Zeitpunkt ihrer öffentlichen Bekanntmachung noch kein Sicherheitsupdate verfügbar war oder ist. Da technische Details vorzeitig bekannt wurden, konnten Angreifer die Schwachstellen natürlich potenziell relativ einfach ausnutzen, bevor die Hersteller entsprechende Patches bereitstellen konnten.

Die Tragweite der Sicherheitslücken wird neben ihrer offiziellen Erfassung unter eigenen CVE-Nummern insbesondere durch die Bewertung des BSI mit einem CVSS-Base-Score von 9,8 deutlich. Die Institutionen CERT-EU und PHP selbst bewerteten die Schwachstellen mit einem CVSS-Wert von 9,2. Während CVE (Common Vulnerabilities and Exposures) der eindeutigen Identifikation bekannter Sicherheitslücken dient, bewertet CVSS (Common Vulnerability Scoring System) deren technischen Schweregrad auf einer Skala von 0 bis 10.

Bewertung im CVSS-Score

Jede öffentlich erfasste Sicherheitslücke erhält eine eindeutige CVE-Nummer, über die sich technische Details, Risikobewertungen nach CVSS sowie verfügbare Sicherheitsupdates zuordnen lassen.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) sowie CERT-EU veröffentlichten entsprechende Sicherheitswarnungen. Auch größere Einrichtungen reagierten vorsorglich und nahmen ihre Websites zeitweise vom Netz.

Für uns war entscheidend, nicht auf eine abschließende Bewertung aller möglichen Angriffsszenarien zu warten. Solange wir nicht sicher ausschließen konnten, dass ein von uns betreutes System betroffen war, behandelten wir es als potenziell gefährdet.

Zwischenzeitlich machten auch Meldungen bereits die Runde, dass die Charité, Flughäfen, Behörden und Kliniken offline gegangen sind. Das belegte eindeutig, dass unser Handeln von vielen Betroffenen gleichermaßen gehandhabt wurde

Warum wir Websites vorsorglich abgeschaltet haben

Nach Bekanntwerden der Sicherheitslücken haben wir die von uns betreuten Server, VMs, die Hosting-Umgebungen und alle weiteren betroffenen Systeme geprüft. Das Problem, das sich dabei stellt, ist folgendes: 

Eine Sicherheitsmeldung erscheint nicht automatisch gleichzeitig mit einem installierbaren Update für jede eingesetzte Serverplattform und PHP Version.

Damit entstand ein Zeitraum, in dem eine bekannte Schwachstelle weiterhin existierte, während für einzelne Systeme noch kein geeignetes Sicherheitsupdate zur Verfügung stand. Bei diesen Systemen haben wir uns für die sichere Variante entschieden, sind den öffentlichen Empfehlungen des BSI und der EU-Behörde gefolgt und haben den öffentlichen Zugriff vorübergehend deaktiviert. Damit haben wir sozusagen den Nährboden für mögliche Angriffe entzogen.

Eine Website für einige Stunden nicht erreichbar zu machen, ist keine angenehme Entscheidung. Bei einer kritischen Sicherheitslücke halten wir dieses Risiko jedoch für besser kontrollierbar als einen möglichen erfolgreichen Angriff auf den Server. Zudem möchten wir darauf hinweisen, dass es seit Bestehen des Internets laut unseren Informationen noch nie offiziell eine Information gegeben hat, die Internetseiten vorsichtshalber lieber vom Netz zu nehmen. Jedenfalls können wir uns seit 1995 nicht an einen derartigen Vorgang erinnern. Also war das heute für die ganze Welt nicht nur eine Zero-Day-Sicherheitslücke, sondern auch der allererste derartige Fall, dass nicht ein Einzelsystem isoliert, sondern die breite Masse stark gefährdet ist.

Was wir konkret gemacht haben

Nach Veröffentlichung der Sicherheitswarnungen liefen bei uns mehrere Schritte parallel:

• Prüfung der Meldungen von PHP, BSI und CERT-EU
• Prüfung der eingesetzten PHP-Versionen und Serverkonfigurationen
• Identifikation potenziell betroffener Systeme
• vorsorgliche Abschaltung gefährdeter Websites
• Information der betroffenen Kunden
• zusätzliche Informationsmail über unseren Newsletter
• laufende Prüfung verfügbarer PHP und Debian Sicherheitsupdates
• Installation der freigegebenen Sicherheitspakete
• technische Kontrolle der Systeme nach dem Update
• schrittweise Wiederfreigabe der Websites
• Sicherstellung des Betriebs

Bei Servern mit besonderen Konfigurationen haben wir zusätzlich die Situation separat bewertet und mit den jeweiligen Kunden direkt und individuell abgestimmt.

Auch externe Server mussten berücksichtigt werden

Nicht jede von uns betreute TYPO3 oder WordPress Installation läuft auf einer von uns administrierten Serverumgebung. Andersherum administrieren wir nicht jede Installation in einer virtuellen Maschine (VM), die auf unserer oder Kunden-Infrastruktur zur Verfügung gestellt wird.

Bei Kunden mit externem Hosting konnten wir die notwendigen Betriebssystem- oder PHP-Updates nicht selbst installieren. In diesen Fällen haben wir über die Sicherheitslage informiert und auf die notwendige Abstimmung mit dem jeweiligen Hosting-Anbieter hingewiesen. Im Falle von unserer Infrastruktur haben wir in Abstimmung mit dem Kunden die Updates zur Verfügung gestellt oder komplett im Namen des Kunden und für dessen Agentur durchgeführt.

Damit war klar, welche Systeme wir direkt absichern konnten und an welchen Stellen der jeweilige Serverbetreiber oder Administrator tätig werden musste. Dennoch haben wir auch bei externen Systemen versucht, die Kunden bestmöglich weiterhin zu informieren und zu unterstützen.

Updates installieren und Websites kontrolliert freigeben

Nachdem wie angekündigt ab kurz nach 16:00 Uhr deutscher Zeit (14:00 Uhr UTC) passende PHP und etwas zeitversetzt auch Debian Sicherheitsupdates verfügbar waren, haben wir die entsprechenden Pakete geprüft und auf den von uns administrierten Systemen installiert.

Danach wurden die Server und Websites alle kontrolliert und wieder ans Netz gebracht. Erst anschließend haben wir den öffentlichen Zugriff wieder freigegeben und die betroffenen Kunden informiert. Damit war die Arbeit nicht mit der Installation eines Updates beendet, besonders entscheidend war für uns auch die Kontrolle danach, um sicherzustellen, dass die Webseiten alle wieder am Netz sind.

Website-Sicherheit endet nicht bei TYPO3 oder einem aktuellen CMS

Der Vorfall zeigt einen Punkt, der bei der Absicherung von Websites häufig unterschätzt wird.

Eine aktuelle TYPO3, WordPress oder CMS-Version allein macht eine Website noch nicht sicher! Neben der technischen Voraussetzung kommt natürlich immer auch noch eine entsprechende Konfiguration und insbesondere Überwachung hinzu.

Zum technischen Betrieb gehören unter anderem:

• TYPO3 und eingesetzte Extensions (& WordPress oder andere CMS)
• PHP
• Betriebssystem und Systempakete
• Webserver
• Datenbank
• Serverkonfiguration
• Monitoring
• Sicherheitsupdates
• Rechtemanagement
• Backups

Eine Schwachstelle in einer dieser Komponenten kann Auswirkungen auf das gesamte System haben. Backups betreffen dabei nicht unmittelbar die Sicherheit des laufenden Betriebs. Sie ermöglichen jedoch die Wiederherstellung der Arbeitsdaten, wenn dies nach einem Sicherheitsvorfall erforderlich wird.

Professionelles Website-Hosting bedeutet für uns deshalb nicht nur einfach einen Server bereitzustellen. Es bedeutet auch, relevante Sicherheitsmeldungen zu beobachten, die eigene Infrastruktur zu bewerten und bei kritischen Vorfällen Entscheidungen zu treffen. Hinzu kommen Prozesse, wie wir in derartigen Fällen intern vorgehen.

Unser Fazit

Bei einer kritischen Sicherheitslücke muss nicht jede vorsorgliche Maßnahme im Nachhinein notwendig gewesen sein. Ausschlaggebend ist die Situation zum Zeitpunkt der Entscheidung und bei Bekanntwerden des Problems.

Wenn noch nicht eindeutig feststeht, ob ein System sicher betrieben werden kann, bevorzugen wir bei kritischen Schwachstellen eine kurzfristige Einschränkung gegenüber einem vermeidbaren Sicherheitsrisiko.

Genau nach diesem Prinzip sind wir auch bei den aktuellen PHP Sicherheitslücken vorgegangen.

Weiterführende Informationen

BSI, Sicherheitshinweis WID SEC 2026 4055
https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2026-4055

CERT-EU, PHP Security Advisory
https://cert.europa.eu/publications/security-advisories/2026-018/