Incident Response in der Praxis: Abwehr von PHP2Shell (CVE-2026-109618 & CVE-2026-1ich 09619)
Sicherheitslücken schließen ist das eine, die richtigen Maßnahmen zur richtigen Zeit umzusetzen das andere. Als kritische, unauthentifizierte Remote-Code-Execution-(RCE)-Schwachstellen in PHP bekannt wurden, war schnelles Handeln gefragt. Unser Infrastruktur-Team hat umgehend mit der Risikoanalyse begonnen und kurzfristige Schutzmaßnahmen eingeleitet.
Zero-Day-Charakter und Early Mitigations
Noch vor der Bereitstellung offizieller Sicherheitspatches zirkulierten bereits erste Proof-of-Concept-Exploits. Die Angriffsvektoren nutzten Schwachstellen im PHP-Kern aus. Um den Zeitraum bis zum Release der gepatchten Binaries zu überbrücken, haben wir unverzüglich präventive Konfigurationsanpassungen auf Systemebene vorgenommen.
Auf Infrastrukturebene wurden potenziell verwundbare Standardfunktionen deaktiviert und strengere Sicherheitsvorgaben erzwungen. Eine weitreichendere Option – das vollständige Blockieren von Multipart-Uploads auf Loadbalancer-Ebene – wurde eingehend geprüft.
Bewertung des Angriffsvektors und kontrollierter Shutdown
Parallel dazu liefen die Vorbereitungen für die Sicherheitsupdates. Dabei mussten wir nicht nur schnell reagieren, sondern auch mögliche Auswirkungen auf laufende Shops und wichtige Funktionen berücksichtigen.
Da primäre Härtungsmaßnahmen das Risiko zwar verringerten, aber nicht vollständig eliminierten, verschärfte sich die Bedrohungslage im Tagesverlauf. Ein wesentlicher Faktor war dabei die Annahme, dass durch moderne KI-Technologien nach der Veröffentlichung des Patches praktisch jedermann in der Lage sein würde, binnen Minuten waffenfähige Exploits zu generieren, um ungepatchte Systeme zu kompromittieren.
Wie eine spätere Stichprobenanalyse von gestern Nacht zeigte, bewahrheitete sich dieses Szenario: Die ersten Angriffe auf Basis des Patches erfolgten bereits rund 40 Minuten nach dessen Veröffentlichung.
Nach dem konkreten Aufkommen dieser automatisierten Angriffsversuche trafen wir in enger Abstimmung mit den Stakeholdern die Entscheidung für eine temporäre Außerbetriebnahme der betroffenen Applikationsserver.
Während der Downtime lag das Hauptaugenmerk auf einer sicheren Trennung der Systeme. Anstelle dynamischer Wartungsseiten wurden vorübergehend generische Fehlermeldungen ausgegeben, was wir zugunsten der absoluten Systemintegrität bewusst in Kauf genommen haben.
Patch-Deployment und Post-Exploitation-Prävention
Sobald die offiziellen Patches bereitstanden, startete der priorisierte Rollout auf allen betroffenen Systemen. Durch die strukturierte Vorgehensweise im Team konnten die Sicherheitsupdates schrittweise und zügig eingespielt werden.
Dies machte im Anschluss an das Patching einen kontrollierten Neustart der Anwendungs-Server erforderlich. Am Ende des Tages waren sämtliche Systeme auf dem neuesten Stand, vollständig abgesichert und wieder voll einsatzbereit.
Kaskadierende CVEs: GitLab und Node.js
Die Bedrohungslage beschränkte sich nicht nur auf PHP. In den Abendstunden erforderten kritische Sicherheitsupdates für GitLab sowie Node.js ein sofortiges Handeln, um weitere RCE-Schwachstellen zu schließen. Die entsprechenden Updates wurden umgehend in unserer Deployment-Pipeline angestoßen und erfolgreich ausgerollt.
Jene Sicherheitslücken standen in keinem Zusammenhang mit PHP, wurden jedoch zufällig am selben Tag publiziert. In der Praxis kommt es gelegentlich zu solchen Phasen, in denen sich verschiedene Vorfälle zeitgleich ereignen.
Ein großes Danke an unser Team für die schnelle Reaktion, die fundierte technische Arbeit und die hervorragende, abteilungsübergreifende Zusammenarbeit in dieser hochdynamischen Ausnahmesituation.