PHP2Shell: Wie wir unsere ILIAS-Plattformen innert Stunden abgesichert haben
Am 20. Oktober 2026 kündigte das PHP-Projekt kurzfristig eine ausserordentliche Sicherheitsaktualisierung an. Sie betraf zwei kritische Schwachstellen, die unter dem Namen "PHP2Shell" bekannt wurden. Über die Lücken können Angreifer ohne Anmeldung die Kontrolle über einen Webserver übernehmen. PHP ist die technische Grundlage von ILIAS. Damit waren grundsätzlich alle ILIAS-Installationen weltweit betroffen, auch die rund 60 Plattformen, die wir für Hochschulen, Schulen und Unternehmen betreiben.
Vorbereitung, bevor die Korrektur da war
Wir verfolgen Sicherheitsmeldungen zu den Komponenten, die wir einsetzen, laufend. Noch am Abend der Ankündigung haben wir begonnen, die Lage einzuschätzen. Am Morgen des 21. Oktober haben wir alle betroffenen Server erfasst, für jeden geprüft, welche Version im Einsatz ist, und das Update vorbereitet und getestet. So stand fest, dass die Korrektur sofort nach ihrem Erscheinen eingespielt werden kann.
Die Entscheidung: lieber offline als verwundbar
Schon vor der offiziellen Veröffentlichung waren Details zu den Lücken im Umlauf. Am Vormittag tauchten erste Berichte über mögliche Angriffe auf. Eine Korrektur gab es noch nicht, und zuverlässig vorbeugen liess sich nicht. Wir haben deshalb entschieden, alle von uns betriebenen ILIAS-Installationen vorsorglich vom Netz zu nehmen. Ein Unterbruch von einigen Stunden ist für die Nutzerinnen und Nutzer ärgerlich. Ein erfolgreicher Angriff auf eine Lernplattform mit Personendaten wäre um ein Vielfaches gravierender.
Gegen Mittag waren alle Plattformen offline. Kurz darauf erschien anstelle von ILIAS eine Wartungsseite mit einem Hinweis zum Unterbruch. Die Plattformen waren so geschützt, und wir konnten sie trotzdem weiter testen.
Eine Stunde nach der Veröffentlichung wieder online
Die Korrektur erschien am 21. Oktober um ca. 15:30 Uhr, etwas früher als angekündigt. Wir sind in festen Schritten vorgegangen: zuerst die Test- und Staging-Systeme, dann nach erfolgreicher Prüfung die produktiven Plattformen. Jede Plattform haben wir erst wieder freigeschaltet, nachdem wir kontrolliert hatten, dass die korrigierte Version tatsächlich aktiv ist.
Um ca. 16:30 Uhr, rund eine Stunde nach der Veröffentlichung, war der grösste Teil der Plattformen gepatcht und wieder erreichbar.
Auch ältere Systeme abgesichert
Einige wenige Plattformen laufen auf älteren Systemen, für die es keine fertige Korrektur gab. Wir haben sie nicht einfach offline gelassen, sondern die Korrektur für diese Systeme selbst aufbereitet, getestet und eingespielt. Am Abend um ca. 19:15 Uhr war die letzte Plattform wieder online. Seither laufen alle von uns betriebenen ILIAS-Installationen mit der korrigierten Version.
Kontrolle danach
Kurz nach der Veröffentlichung wurden weltweit erste Angriffe gemeldet. Wir haben deshalb im Lauf des Tages mehrmals alle Server systematisch auf Spuren eines Angriffs untersucht und dabei keine Hinweise auf eine Kompromittierung gefunden. Diese Kontrolle wiederholen wir in den kommenden Tagen.
Nächster Schritt: Docker-Images und ReviewApps
Neben den produktiven Plattformen pflegen wir eigene Docker-Images für ILIAS. Das sind vorkonfigurierte Pakete, aus denen sich eine lauffähige ILIAS-Umgebung mit wenigen Handgriffen starten lässt. Wir veröffentlichen sie auch öffentlich für die ILIAS-Community. Diese Images bauen wir in Kürze mit der korrigierten PHP-Version neu. Die offiziellen PHP-Grundimages, auf denen sie aufbauen, sind inzwischen verfügbar.
Mit den aktualisierten Images nehmen wir anschliessend auch unsere ReviewApps wieder in Betrieb. ReviewApps sind kurzlebige Testinstanzen, die automatisch für jede Weiterentwicklung entstehen, zum Beispiel für eine neue Funktion oder eine Fehlerkorrektur. So kann man Änderungen in einer echten ILIAS-Umgebung ausprobieren und abnehmen, bevor sie auf eine produktive Plattform kommen. Auch die ReviewApps haben wir am 21. Oktober vorsorglich abgeschaltet. Sie gehen erst wieder online, wenn sie auf den abgesicherten Images laufen.
Unser Fazit
Sicherheitslücken lassen sich nicht verhindern. Entscheidend ist, wie schnell und wie überlegt man reagiert. Dass wir die Lücke so schnell schliessen konnten, liegt an drei Dingen: Wir wissen jederzeit, welche Systeme wir betreiben und in welchem Zustand sie sind. Wir haben eingespielte Abläufe für den Ernstfall. Und wir entscheiden im Zweifel für die Sicherheit, auch bei Test- und Entwicklungsumgebungen.