PHP2Shell und Copiki: Wie wir eine kritische PHP-Lücke abgesichert haben

Am 21. Oktober 2026 hat das PHP-Projekt Notfall-Updates für zwei kritische Lücken veröffentlicht, die seitdem unter dem Namen PHP2Shell bekannt sind. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) reagierte noch am selben Tag mit einer Warnung und hielt eine kurzfristige Ausnutzung für wahrscheinlich. Die Lücke steckt nicht in einer einzelnen Anwendung, sondern in PHP selbst, also in der Software, die unzählige Webanwendungen auf dem Server ausführt.

Weil Copiki auf MediaWiki und damit auf PHP aufbaut, musste der Betreiber handeln, nicht der Kunde. Für Verantwortliche in IT, Qualitätsmanagement (QM) und Informationssicherheit (ISMS) ist bei so einem Vorfall eine Frage entscheidend: Wurde zeitnah gepatcht, und lässt sich das belegen? Dieser Beitrag beantwortet sie an einem realen Fall, Schritt für Schritt.

Was ist PHP2Shell und warum ist die Lücke ernst

PHP2Shell bezeichnet zwei zusammenhängende Schwachstellen in der PHP-Laufzeitumgebung, also in der Software, die PHP-Anwendungen auf dem Server ausführt. Beide sind auf der üblichen Schweregrad-Skala CVSS mit 9,2 von 10 bewertet und tragen im internationalen Schwachstellenverzeichnis die Kennungen CVE-2026-109618 und CVE-2026-109619. Ein Angreifer kann sie ausnutzen, um ohne Anmeldung eigenen Code auf dem Server auszuführen. Fachlich heißt das Remote Code Execution.

Vollständig schließen lässt sich die Lücke nach Angaben des PHP-Projekts nur durch das Update. Konfigurationsmaßnahmen sind demnach ein Notbehelf, kein Ersatz. Am höchsten ist das Risiko bei der Betriebsart mod_php, bei der PHP als Modul direkt im Webserver läuft, weil der Angriff dann greift, bevor die Anwendung überhaupt eigenen Code ausführt.

Die Lage bei der Ausnutzung ist uneinheitlich. In der Fassung Version 1.2 vom 22. Oktober ist dem BSI keine erfolgreiche Ausnutzung in der Breite bekannt, bei unbestätigten Berichten über fertige Angriffswerkzeuge (Exploits). Sicherheitsforscher wie watchTowr beobachteten in ihren Honeypot-Netzen, also in absichtlich angreifbar gehaltenen Testsystemen, Ausnutzungsversuche, und Amazon meldete einen solchen Versuch bereits vor der öffentlichen Bekanntgabe. Versuche sind also belegt. Eine breite, erfolgreiche Ausnutzung ist nach aktuellem Stand nicht bekannt.

Für eine IT-Leiterin, die parallel ein ISMS aufbaut, ist der entscheidende Satz dieser: Ein Update der Anwendung reicht nicht, die PHP-Laufzeit selbst muss gepatcht werden. Für MediaWiki wurde ein Angriff ohne vorherige Anmeldung ausdrücklich bestätigt. Damit waren beide Copiki-Generationen auf der Ebene der Laufzeitumgebung betroffen. Der häufigste Denkfehler: die Lücke mit einem Anwendungsproblem zu verwechseln. Betroffen ist die Schicht unter der Anwendung, und diese Unterscheidung bestimmt, wer in der Verantwortung steht.

Unsere Reaktion im Zeitablauf

Der Ablauf im Überblick, von der Veröffentlichung bis zur vollständigen Absicherung beider Generationen:

• 21.10. abends: Prüfung des offiziellen PHP-Basis-Images, Rollout auf alle Copiki-4-Instanzen, jede einzeln kontrolliert.
• 21.10. nachts: Copiki 3 als betroffen identifiziert, für dessen PHP-Version lag kein fertiges Update vor.
• 22.10.: empfohlene Schutzeinstellungen über Repository und Pipeline auf alle Copiki-3-Instanzen ausgeliefert.
• 22.10. abends: eigene, gepatchte PHP-Laufzeitumgebung aus dem offiziellen Quellcode-Patch gebaut und getestet.
• 23.10. morgens: alle Copiki-3-Instanzen auf der gepatchten Version, jede einzeln geprüft.

Copiki 4: noch am Abend der Veröffentlichung abgesichert

Das offizielle Basis-Image, also das fertige, zentral gepflegte Grundpaket, auf dem unsere Copiki-Container aufsetzen, stand am Abend des 21. Oktober bereit. Rund zwei Stunden nach Beginn unserer Prüfung war jede Copiki-4-Instanz aktualisiert und einzeln kontrolliert. Dazwischen lagen Analyse, Entscheidung, eine gesonderte Sicherheits- und Infrastrukturprüfung der Änderung, ein Testlauf und der Weg über Test- und Staging-Umgebung.

Wir haben dabei mehr getan als das Pflicht-Update einzuspielen. Ein nicht benötigtes PHP-Modul im Webserver wurde entfernt, die von Copiki nicht genutzte PHP-Funktion Session Upload Progress abgeschaltet (sie meldet den Fortschritt von Datei-Uploads und war einer der bestätigten Angriffswege), und die Regeln für Upload-Verzeichnisse verschärft.

Copiki 3: am Folgetag gehärtet, am übernächsten Morgen vollständig gepatcht

Noch in derselben Nacht identifizierte das Team Copiki 3 als betroffen. Für dessen PHP-Version gab es kein offizielles Update, nur einen Quellcode-Patch des PHP-Projekts, also die reine Korrektur im Programmcode ohne fertiges, installierbares Paket. Am 22. Oktober haben wir zuerst die empfohlenen Schutzeinstellungen über Repository und Pipeline ausgeliefert, also über denselben kontrollierten Weg wie jedes reguläre Update. Am Abend waren alle Copiki-3-Instanzen gehärtet: Die Lücke selbst war damit noch nicht geschlossen, der Angriffsweg aber deutlich erschwert.

Am selben Abend baute das Team eine eigene, gepatchte PHP-Laufzeitumgebung aus dem offiziellen Quellcode-Patch. Geprüft wurde sie mit knapp 5.000 automatisierten Tests, die das PHP-Projekt selbst mitliefert. Die Sicherheitsprüfung fand einen Kompatibilitätsfall bei Seitentiteln mit Leerzeichen, der vor dem Rollout behoben wurde. Am Morgen des 23. Oktober liefen alle Copiki-3-Instanzen auf der gepatchten Version, jede einzeln geprüft.

Als das PHP-Projekt am 23. Oktober empfahl, Session Upload Progress vorsorglich abgeschaltet zu lassen, war diese Funktion bei Copiki in beiden Generationen längst aus. Für einen Geschäftsführer ist der nachvollziehbare Ablauf das eigentliche Argument. Was zählt, ist der dokumentierte Weg von der Prüfung über die Härtung bis zur Kontrolle jeder einzelnen Instanz. Der Stolperstein unter Zeitdruck wäre gewesen, direkt auf den laufenden Kundensystemen einzugreifen. Auch nachts blieb die Auslieferung über Repository und Pipeline, damit jede Änderung nachvollziehbar bleibt.

Warum das so schnell ging: unsere Pipeline

Server-Konfiguration und Laufzeitumgebung werden bei uns aus dem Repository gebaut, dem zentralen, versionierten Ablageort für Code und Konfiguration, und nicht von Hand auf einzelnen Servern verändert. Eine Pipeline ist dabei der automatisierte Weg vom Code-Stand bis zur laufenden Instanz. Jede Änderung erzeugt frische Container-Images, also fertig verpackte, startbereite Softwarepakete, die eindeutig einem Code-Stand zugeordnet sind. So ist jederzeit nachvollziehbar, welcher Stand auf welcher Instanz läuft.

Jede Änderung durchläuft nacheinander Test-Umgebung, Staging-Umgebung als produktionsnahe Vorstufe und erst dann die Produktivumgebung, also die Systeme, auf denen unsere Kunden arbeiten. Die Stufen werden vorher geprüft und bewusst freigegeben. Auch unter Zeitdruck prüften wir jede Änderung vorab gesondert auf Sicherheit und auf Auswirkungen in der Infrastruktur. Nach dem Rollout kontrollierte das Team jede einzelne Instanz automatisiert: Läuft die richtige PHP-Version, sind die Schutzeinstellungen aktiv, antwortet die Instanz korrekt. Erst dann galt eine Generation als erledigt.

Für eine Qualitätsmanagementbeauftragte (QMB) ist das die Nachweislogik aus dem eigenen Managementsystem. Jeder Stand ist eindeutig zugeordnet, jede Freigabe dokumentiert und jede Instanz nach dem Rollout kontrolliert. Dieselbe Trennung zwischen Bearbeiten, Prüfen und Freigeben findet sich auch in den Freigabe-Workflows in Copiki wieder. Der schnelle Ablauf entsteht gerade durch die festen Stufen. Seit dem Vorfall lädt die Pipeline bei jedem Bauvorgang (Build) automatisch die neuesten Basis-Images, damit künftige Sicherheitsupdates automatisch mitkommen.

Copiki 3 ist abgesichert, aber am Ende seines Wegs

Für Copiki 3 liefern wir weiterhin Sicherheitsupdates, wenn sie nötig sind. PHP2Shell zeigt, dass wir dafür auch Sonderwege gehen. Der Aufwand ist jedoch ein ganz anderer. Für Copiki 4 reichte das offizielle Update, die Absicherung dauerte rund zwei Stunden. Für Copiki 3 musste das Team eine eigene PHP-Version bauen und testen, bis zur vollständigen Absicherung vergingen knapp zwei Tage.

Der Grund liegt in der Altversion. Die von Copiki 3 genutzte PHP-Version erhält seit Ende 2022 keine regulären Updates mehr. Für nicht mehr unterstützte Versionen stellt das PHP-Projekt nur noch minimale Backports bereit, also Korrekturen, die aus der aktuellen Version in den alten Quellcode zurückübertragen werden, ohne fertiges Paket, und bei sehr alten Zweigen gibt es teils gar keinen Fix. Übersetzt heißt das: Bei einer künftigen Lücke könnte für eine solche Altversion womöglich gar kein offizieller Patch mehr existieren.

Copiki 3 ist damit nach aktuellem Stand geschützt. Die Absicherung ist aber eine belastbare Momentaufnahme, kein Ersatz für einen laufend gepflegten Update-Weg. Für einen Geschäftsführer im Generationswechsel ist die Rechnung übersichtlich: rund zwei Stunden regulärer Update-Weg gegenüber knapp zwei Tagen Sonderbau, mit der Aussicht, dass dieser Sonderbau beim nächsten Mal nicht mehr möglich sein könnte.

Was Copiki 4 für den Betrieb bedeutet

Copiki 4 wird aktiv weiterentwickelt, mit regelmäßigen Sicherheitsupdates, neuen Funktionen und einer moderneren Infrastruktur. Seine Stärke im Betrieb ist der reguläre Update-Weg. Liegt ein offizielles Update vor, kann es ohne Sonderbau über die Pipeline ausgeliefert werden. Genau das hat PHP2Shell gezeigt.

Der Betrieb bleibt dabei Sache des Betreibers. Bei einem Vorfall wie PHP2Shell müssen Kunden nicht selbst eingreifen, die Laufzeitumgebung wird zentral für alle Instanzen aktualisiert. Für eine IT-Leiterin, die Patchnachweise gegenüber Prüfern führen muss, bedeutet das weniger Unsicherheit darüber, ob und wie schnell beim nächsten Vorfall ein Fix verfügbar ist. Wer darüber nachdenkt, wie ein Managementsystem Verantwortung bündelt und die Geschäftsführung entlastet, findet hier einen handfesten Beleg. Für den Umstieg von Copiki 3 beraten wir und begleiten die Migration. Den Umstieg nur als IT-Projekt zu sehen, greift zu kurz. Es ist eine Betriebsentscheidung über die Reaktionsfähigkeit bei künftigen Lücken.

Fazit

Eine kritische Lücke in der technischen Basis kann jeden treffen, der PHP einsetzt. Entscheidend ist, wie schnell und kontrolliert der Betreiber reagiert. Bei PHP2Shell mussten unsere Kunden nichts tun, weil wir die Laufzeitumgebung zentral für alle Instanzen abgesichert haben. Copiki 4 war noch am Abend der Veröffentlichung abgesichert, Copiki 3 am Folgetag gehärtet und am übernächsten Morgen vollständig gepatcht. Das Vertrauenssignal liegt im nachvollziehbaren Ablauf dahinter: Prüfung, Härtung, gestufte Freigaben und die Kontrolle jeder einzelnen Instanz.

Der Aufwandsunterschied zwischen beiden Generationen ist eine sachliche Einordnung. Rund zwei Stunden regulärer Update-Weg stehen knapp zwei Tagen Sonderbau gegenüber. Sicherheitslücken wird es weiter geben. Wie ruhig der nächste Vorfall verläuft, hängt davon ab, dass der Update-Weg eingespielt und kontrolliert bleibt. Für Copiki-3-Kunden ist der Umstieg auf Copiki 4 der Schritt, der genau das für die Zukunft einfacher macht.

Zurück zum Ausgangspunkt: Während das BSI am 21. Oktober zum sofortigen Handeln aufrief, war die Frage für Copiki-Kunden bereits in Arbeit, ohne dass sie selbst eingreifen mussten.

Häufige Fragen

Quellen

• BSI: Pressemitteilung zur PHP-kritischen Schwachstelle (21.10.2026)
• BSI: Cybersicherheitswarnung 2026-297981-1032 (Version 1.2)
• PHP Security Advisory zu CVE-2026-109618
• PHP Security Advisory zu CVE-2026-109619
• php.net: Release- und Advisory-Archiv 2026
• watchTowr: PHP CVE-2026-109618 FAQ
• Calif: PHP2Shell und der bestätigte Pre-Auth-Angriff gegen MediaWiki
• Sansec: PHP2Shell und der Umgang mit alten PHP-Versionen

KI unterstützt, Menschen entscheiden – so sichern wir Qualität, Relevanz und Verantwortung.