Wer heute, am 21. Oktober 2026, die Webseiten der Landesregierung Baden-Württemberg aufrufen wollte, sah vielerorts nur einen Wartungshinweis. Seit der Mittagszeit waren Homepages von Ministerien und Regierungspräsidien vorsorglich vom Netz genommen worden. Auch mehrere Universitäten und Universitätsklinika schalteten ihre Internetauftritte ab – darunter Einrichtungen in Freiburg.

Das Staatsministerium erklärte, die Infrastruktur solle geschützt werden, bis Sicherheitsupdates verfügbar sind. Die Behörden wollen die Aktualisierungen installieren und ihre Webseiten danach wieder freischalten. Innenminister Manuel Hagel (CDU) sagte, ein Weiterbetrieb betroffener, mit dem Internet verbundener Systeme ohne wirksame Schutzmaßnahmen sei nicht vertretbar. Sicherheit habe Vorrang vor Verfügbarkeit. Klingt trocken, ist für einen Webserver aber ungefähr die digitale Version von: lieber kurz die Tür zusperren, als später die ganze Wohnung renovieren.

Hochkritische PHP-Lücke sorgt für den Rückzug

Hinter der Maßnahme steht eine neu entdeckte, schwerwiegende Sicherheitslücke in PHP, einer weit verbreiteten Programmiersprache. PHP steckt unter anderem in Blogs, Nachrichtenportalen, Onlineshops und Content-Management-Systemen wie WordPress. Die Schwachstellen könnten aus der Ferne ausgenutzt werden, um Schadcode auf Webservern mit PHP-Anwendungen auszuführen und IT-Systeme zu kompromittieren.

Sicherheitsbehörden und der IT-Dienstleister BITBW stuften die Lücke als hochkritisch ein. Am 21. Oktober 2026 wurde vor zwei kritischen PHP-Sicherheitslücken gewarnt: CVE-2026-109618 und CVE-2026-109619. Beide haben einen CVSS-v4.0-Wert von 9,2 – die Einstufung lautet „kritisch“. CERT-EU nennt als mögliche Folge die Ausführung fremden Codes auf betroffenen Servern.

Für 21. Oktober 2026 um 14:00 Uhr UTC, also 16:00 Uhr MESZ, waren Sicherheitsupdates angekündigt. Zum Zeitpunkt der Meldung fehlten jedoch technische Einzelheiten zu den Angriffen, die endgültige Liste betroffener PHP-Versionen und die vollständige Liste korrigierter Versionen. Nach CERT-EU-Informationen könnten PHP-Versionen ab PHP 5 betroffen sein; bestätigt war das durch vollständige PHP-Versionshinweise noch nicht.

Hier könnte Ihr Advertorial stehen
Ein Advertorial bietet Unternehmen die Möglichkeit, ihre Botschaft direkt im redaktionellen Umfeld zu platzieren

Die diskutierte Remote-Code-Execution könnte unter bestimmten Voraussetzungen Schadcode ausführen. Denkbar wären der Zugriff auf oder die Manipulation von Dateien und Datenbanken, Webseitenmanipulation, Datendiebstahl und die Installation weiterer Schadsoftware. Unklar war zunächst, unter welchen Bedingungen Angriffe möglich sind und ob dafür eine Anmeldung erforderlich ist. Einen Beleg dafür, dass jede PHP-Website bereits kompromittiert oder unter allen Bedingungen angreifbar ist, gab es nicht.

Unikliniken: keine Beeinträchtigung der Versorgung

Die Uniklinik Freiburg teilte mit, der Betrieb sei nicht beeinträchtigt. Auch die Universitätsklinika Heidelberg und Mannheim bezeichneten die Abschaltung als präventive Sicherheitsmaßnahme. Ein Cyberangriff auf ihre IT-Systeme liege nicht vor, betonten sie. Die Patientenversorgung war nicht betroffen.

Hagel warnte zugleich vor einer weiteren Verschärfung der Cybersicherheitslage. Nach seinen Angaben könnten insbesondere zunehmende Möglichkeiten künstlicher Intelligenz die Geschwindigkeit und Qualität von Cyberangriffen erhöhen. Exponierte Systeme müssten bei akuten Gefährdungen kurzfristig vom Netz genommen werden können. In den Behörden wird deshalb nicht nur gepatcht, sondern auch geprüft, welche Systeme überhaupt öffentlich erreichbar sind.

Viele Webserver könnten betroffen sein, weil neben WordPress auch Drupal und Joomla PHP verwenden. Bei WordPress übernimmt PHP unter anderem das Laden von Seiten, die Verarbeitung von Formularen sowie die Zusammenarbeit mit Plugins und Themes. Die Warnung betrifft zunächst die PHP-Laufzeitumgebung und bedeutet nicht automatisch eine neue WordPress-Sicherheitslücke. WordPress-, Plugin- und Theme-Updates allein reichen daher nicht aus; zusätzlich muss die PHP-Version des Webservers geprüft werden.

Was Betreiber jetzt kontrollieren sollten

In WordPress führt der Weg über „Werkzeuge“, „Website-Zustand“ und anschließend „Bericht“ beziehungsweise „Info“. Im Abschnitt „Server“ steht der Eintrag „PHP-Version“, den Betreiber notieren sollten. Beim Hosting-Anbieter findet sich die Einstellung häufig unter „PHP-Einstellungen“, „PHP-Version“ oder in der Domainverwaltung. Wer mehrere Domains betreibt, muss jede Website einzeln prüfen – unterschiedliche PHP-Versionen sind durchaus möglich.

Auf eigenen Linux- oder Windows-Servern zeigt php -v die PHP-CLI-Version an. Das ist allerdings nicht zwingend jene Version, die der Webserver tatsächlich nutzt, etwa bei PHP-FPM, Containern oder getrennten Laufzeitumgebungen. Zusätzlich gehören Webserver-Konfigurationen, PHP-FPM-Versionen und bei IIS die FastCGI- und Handler-Zuordnungen auf die Prüfliste.

Neben Linux-Webservern können Windows Server betroffen sein, wenn dort eine verwundbare PHP-Version läuft – etwa IIS mit FastCGI, Windows mit Apache und PHP oder lokal beziehungsweise produktiv eingesetzte XAMPP-Installationen. Auch Testsysteme dürfen nicht unter den Tisch fallen, sobald sie über das Netzwerk erreichbar sind oder produktiv genutzt werden.

Das BACS rät außerdem, nicht nur öffentlich erreichbare Webseiten zu erfassen. PHP kann ebenso in Verwaltungsoberflächen, internen Fachanwendungen, Hosting-Plattformen, Containern und Appliances stecken. Mit Softwarelieferanten und Dienstleistern sollte geklärt werden, welche Produkte PHP verwenden und welche Updates erforderlich sind. Zuerst gehören internetexponierte Systeme sowie Anwendungen mit Zugriff auf besonders schützenswerte Daten oder kritische Geschäftsprozesse unter die Lupe, anschließend die internen Systeme.

Updates, Backups und ein genauer Blick hinter die Kulissen

Nach Angaben des BACS sind die Schwachstellen in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 behoben. Installiert werden sollte die korrigierte Version der jeweiligen Versionslinie oder ein entsprechendes Sicherheitsupdate des Betriebssystem- beziehungsweise Produktanbieters. Linux-Anbieter können Sicherheitskorrekturen in bestehende Paketversionen zurückportieren; eine unveränderte PHP-Hauptversion bedeutet deshalb nicht automatisch, dass der Patch fehlt. Entscheidend sind die genaue Paketversion und die Sicherheitsinformationen des jeweiligen Anbieters. Für ältere PHP-Versionen sollte geprüft werden, ob Sicherheitskorrekturen verfügbar sind oder ein Wechsel auf eine unterstützte Version nötig ist.

Vor der Aktualisierung gehört ein vollständiges Backup dazu: Website-Dateien, Datenbank, WordPress-Konfiguration, Plugins und Themes sowie hochgeladene Medien. Verwendet werden sollten ausschließlich offizielle PHP-Pakete oder Updates des Hosting-Anbieters. Der bloße Wechsel auf eine andere möglicherweise verwundbare PHP-Version genügt nicht.

Nach der Installation muss geprüft werden, ob der Webserver tatsächlich die korrigierte PHP-Version verwendet. Bei WordPress sollten Startseite, Administrationsbereich, Formulare und gegebenenfalls der Warenkorb getestet werden. Nicht erreichbare Websites können durch inkompatible Plugins oder PHP-Erweiterungen verursacht werden. Je nach Umgebung ist ein kontrollierter Neustart der PHP- oder Webserverdienste erforderlich. Das BACS empfiehlt außerdem, betroffene PHP-Dienste und dauerhaft laufende PHP-Prozesse neu zu starten, Container gegebenenfalls neu zu bauen und erneut bereitzustellen.

Auch die laufenden Anwendungen müssen kontrolliert werden: Verwenden sie wirklich die korrigierte PHP-Version oder ein vom Anbieter als behoben ausgewiesenes Paket? Vor allem Server mit mehreren Websites oder unterschiedlichen PHP-Versionen verdienen eine genaue Prüfung. Administratoren sollten installierte Versionen, Verantwortliche und kurzfristige Aktualisierungsmöglichkeiten dokumentieren und für geschäftskritische Anwendungen Funktionstests in einer vergleichbaren Umgebung vorbereiten. Einige Unternehmen hatten ihre Webserver vorsorglich heruntergefahren und wollten sie erst nach Veröffentlichung und Installation der Patches wieder starten.

Wenn der Patch noch nicht eingespielt werden kann

Bis zum Erscheinen der Patches sollten öffentlich erreichbare PHP-Anwendungen erfasst und bei hohem Risiko vorübergehend eingeschränkt werden. Besonders kritische Systeme können vom öffentlichen Internet getrennt werden. Sichere Backups und eine regelmäßige Prüfung der Webserver-Protokolle helfen dabei, Veränderungen nicht erst dann zu bemerken, wenn die Website plötzlich fremde Werbung ausliefert.

Eine Web Application Firewall kann eine zusätzliche Schutzschicht bieten, garantiert wegen der noch unvollständigen technischen Informationen aber keinen vollständigen Schutz. Das BACS nennt als mögliche Übergangsmaßnahmen das Deaktivieren der PHP-Upload-Fortschrittsanzeige und – sofern betrieblich vertretbar – das Blockieren von Multipart-Anfragen am Webserver oder vorgeschalteten Proxy. Solche Änderungen können Uploads und Formulare beeinträchtigen, müssen an die jeweilige Umgebung angepasst werden und reduzieren nur einzelne Angriffs