Am 21. Oktober 2026 blieben in Baden-Württemberg plötzlich mehrere vertraute Webseiten dunkel. Auch am Standort Uni Heidelberg war die Abschaltung spürbar: Das Universitätsklinikum Heidelberg nahm seine Außenangebote vorsorglich vom Netz. Auslöser waren neu entdeckte, als schwerwiegend eingestufte Schwachstellen im Kern der Programmiersprache PHP.

Ein aktiver Cyberangriff lag nach Angaben der Betreiber nicht vor. Die Pause sollte Zeit für Sicherheitsupdates schaffen. Patientenversorgung und laufender Betrieb seien nicht gefährdet gewesen – ein wichtiger Unterschied, gerade bei Kliniken, deren Webseiten neben Termin- und Kontaktangeboten auch Patientenportale beherbergen.

Hohe Bewertung, zunächst wenige Details

PHP steckt weltweit in dynamischen Webseiten, Verwaltungsportalen, Content-Management-Systemen und Patientenportalen. Die aktuelle Lücke kann unter bestimmten Voraussetzungen Remotecode-Ausführung ermöglichen: Angreifer könnten also aus der Ferne Schadcode auf Webservern mit PHP-Anwendungen ausführen und betroffene Server möglicherweise übernehmen. Das Risiko betrifft vor allem die Server der Betreiber, nicht unmittelbar die Geräte von Webseitenbesuchern. Der bloße Besuch einer betroffenen Seite stellte laut dem Bericht kein direktes Risiko für private Computer oder Smartphones dar.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hatte angekündigt, dass die PHP-Entwickler Details und Patches am 21. Oktober 2026 ab 16 Uhr deutscher Zeit, also um 14:00 UTC, veröffentlichen würden. Betroffen sind CVE-2026-109618 und CVE-2026-109619. Beide Schwachstellen wurden nach CVSS 4.0 mit 9,2 von 10 bewertet. Für eine erfolgreiche Ausnutzung seien weder Authentifizierung noch Nutzerinteraktion erforderlich.

Zum Zeitpunkt der Vorankündigung waren keine bestätigten Ausnutzungen bekannt, allerdings kursierten unbestätigte Berichte über existierende Exploits. Wegen der Ähnlichkeit zum früheren Sicherheitsproblem „Log4Shell“ werden die Lücken in aktuellen Berichten auch „PHP2Shell“ genannt. Eine einheitlich bestätigte CVE-Nummer lag im ursprünglichen Bericht zum Veröffentlichungszeitpunkt noch nicht vor; später nannte das BSI die beiden CVEs.

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

Am 21. Oktober stellten die Entwickler Patches für verschiedene PHP-Versionen bereit und veröffentlichten weitere Details. Hinweise finden sich unter anderem in den GitHub-Advisories zu den CVEs sowie in Blogartikeln von Wiz.io und Calif.io. Beide Unternehmen waren gemeinsam mit OpenAI an der Entdeckung der Schwachstellen beteiligt. Die Empfehlung war klar: Patch installieren, sobald er verfügbar ist.

Was in Heidelberg, Freiburg und an den Hochschulen passierte

In Freiburg waren vorübergehend sowohl die Klinik-Webseite als auch die Internetseite der Patienten-App „Meine Uniklinik“ offline. Über die App können Patienten unter anderem Termine einsehen und mit der Klinik kommunizieren. Das Universitätsklinikum Freiburg erklärte, der Betrieb sei nicht beeinträchtigt. Öffentliche Webseiten und Patientenportale laufen getrennt von klinischen Systemen, die Behandlungsdaten, Dienstpläne und medizinische Geräte verwalten. Die Abschaltung der Außenwebseiten führte deshalb nicht zu einem Ausfall der Patientenversorgung.

Auch Heidelberg und Mannheim bezeichneten die Maßnahme ausdrücklich als präventiv und nicht als Folge eines Cyberangriffs. Interne Klinikprozesse liefen nach den Berichten weiter. Für Nutzer von Login-Portalen, E-Mail-Zugängen und Formularen gab es jedoch zeitweise Einschränkungen. Patientenversorgung und laufender Betrieb blieben nach Angaben der Kliniken gewährleistet.

Nicht erreichbar waren zeitweise außerdem die Universität Tübingen und das Karlsruher Institut für Technologie (KIT). Hochschulen betreiben zahlreiche dezentrale Webanwendungen – Bibliotheksportale, Prüfungsverwaltung, Fachbereichsseiten. Unterschiedliche Zuständigkeiten und Patch-Zyklen machen eine schnelle, einheitliche Absicherung mühsam. Irgendwo wartet immer noch ein altes System.

Mehrere Stunden offline waren auch Webseiten der baden-württembergischen Landesregierung, darunter Ministerien und Regierungspräsidien. Das Staatsministerium begründete den Schritt mit dem vorsorglichen Schutz der Infrastruktur bis zur Bereitstellung der erforderlichen Updates. Bürger konnten in diesem Zeitraum teilweise nicht auf Online-Informationen, Formulare oder Anträge zugreifen.

Warum das Abschalten so viel Arbeit macht

Die weite Verbreitung von PHP macht aus einer einzelnen Schwachstelle ein branchenübergreifendes Problem. Eine Lücke im Sprachkern kann zahlreiche sehr unterschiedliche Anwendungen gleichzeitig betreffen. Öffentliche IT-Landschaften sind häufig über Jahre gewachsen, dezentral gepflegt und teilweise von externen Dienstleistern entwickelt worden.

Vor einem Update müssen Betreiber zunächst erfassen, welche PHP-Versionen und Konfigurationen tatsächlich eingesetzt werden. Bei großen Einrichtungen kann diese Inventarisierung mehrere Stunden oder Tage dauern. Der koordinierte Shutdown verursachte zusätzlichen Personal-, Abstimmungs- und Budgetaufwand. IT-Dienstleister mussten kurzfristig Kapazitäten für Patches, Tests und die Wiederinbetriebnahme bereitstellen; öffentliche Einrichtungen finanzierten ungeplante Arbeiten außerhalb regulärer Wartungsfenster.

Der Vorfall steht in einer Reihe prominenter Sicherheitsprobleme: WannaCry 2017 legte über Windows-SMB unter anderem Bereiche des Gesundheitswesens lahm. Log4Shell 2021 betraf die Java-Bibliothek Log4j und damit weltweit Server. Citrix Bleed 2023 ermöglichte Session-Hijacking bei Citrix NetScaler, MOVEit 2023 führte über SQL-Injection zu Datenabflüssen. Die aktuelle PHP-Lücke 2026 brachte nun das Risiko der Remotecode-Ausführung und vorsorgliche Abschaltungen in Baden-Württemberg.

Anders als bei herstellerspezifischen Lücken betrifft sie potenziell alle Betreiber eigener PHP-Anwendungen. Baden-Württemberg war dabei laut Bericht nicht der einzige von Sicherheitswarnungen betroffene Standort in Deutschland. Als weitere Vorfälle 2026 werden unter anderem eine Sicherheitslücke beim Nachrichtenportal SR.de sowie Schwachstellen bei Windows, Cisco, Ivanti, Citrix und F5 genannt. Der Druck auf zentral verwaltete, besser wartbare Systeme dürfte damit eher steigen; auch Anbieter automatisierter Patch-Prozesse könnten stärker gefragt sein.

Patchen heißt: genauer hinschauen

Die Prüfung darf nicht bei der sichtbaren Startseite enden. Eingebettete und interne PHP-Installationen können in Verwaltungsoberflächen, internen Fachanwendungen, Hosting-Plattformen, Containern und Appliances stecken. Manchen Betreibern ist gar nicht bekannt, dass ein Produkt PHP verwendet. Mit Softwarelieferanten und Dienstleistern sollte daher geklärt werden, welche Produkte betroffen sind und welche Updates benötigt werden.

Priorität haben aus dem Internet erreichbare Systeme, Anwendungen mit Zugriff auf besonders schützenswerte Daten und Programme für kritische Geschäftsprozesse. Danach sollten auch interne Systeme geprüft werden. Für die betroffenen Versionslinien nennt die technische Warnung korrigierte PHP-Versionen:

  • PHP 8.5.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 8.2.35

Für die eingesetzte Versionslinie soll die korrigierte Version oder ein entsprechendes Sicherheitsupdate des Betriebssystem- oder Produktanbieters installiert werden. Linux-Distributionen 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. Bei älteren PHP-Versionen muss geprüft werden, ob der Anbieter noch Korrekturen bereitstellt. Falls nicht, ist ein Wechsel auf eine unterstützte Version nötig.

Auf die Liste gehören außerdem integrierte Komponenten und extern betriebene Anwendungen. Verfügbare Sicherheitsupdates sollten unverzüglich installiert werden. Bei Hosting-Angeboten und Herstellerprodukten sollten Betreiber sich die Behebung bestätigen lassen. Nach dem Update müssen betroffene PHP-Dienste und dauerhaft laufende PHP-Prozesse neu gestartet werden; Container müssen gegebenenfalls neu gebaut und bereitgestellt werden. Anschließend ist zu kontrollieren, ob die tatsächlich laufenden Anwendungen die korrigierte PHP-Version oder ein vom Anbieter als behoben ausgewiesenes Paket verwenden.

Logs und betroffene Systeme sollten auf ungewöhnliche Anfragen, Abstürze, veränderte Dateien und unerwartete Prozesse untersucht werden. Ein Update beseitigt keine bereits erfolgte Kompromittierung.

Falls ein sofortiges Update nicht möglich ist, sollte der Zugriff auf betroffene Anwendungen möglichst auf benötigte Personen und Systeme beschränkt werden. Bei kritischen Anwendungen kommt eine vorübergehende Trennung vom Internet oder eine Ausserbetriebnahme infrage. Hersteller-Advisories können zusätzliche Übergangsmassnahmen nennen, etwa das Deaktivieren der PHP-Upload-Fortschrittsanzeige oder – sofern möglich – das Blockieren von Multipart-Anfragen am Webserver beziehungsweise am vorgeschalteten Proxy.

Solche Änderungen können Upload