Heute fühlt sich an wie ein Katertag. Der Kopf ist schwer, der Kaffee stark und alle sind ein bisschen langsamer unterwegs. Nur haben wir letzte Nacht nicht gefeiert. Wir haben gepatcht – gleich dreimal. Am Morgen waren es kompromittierte Zertifikate, am Nachmittag PHP und spät in der Nacht GitLab.

Morgen: kompromittierte Zertifizierungsstellen

Jedes Mal, wenn du das Schloss-Symbol im Browser siehst, bestätigt eine Zertifizierungsstelle (Certificate Authority, CA), dass die Website wirklich die ist, die sie vorgibt zu sein. Kommt ein Angreifer an die Schlüssel einer CA, kann er sich als beliebige Website ausgeben.

Genau das ist bei eMudhra passiert. Laut Google hat ein Sicherheitsforscher gemeldet, dass die privaten Schlüssel von acht Zwischenzertifikaten (Intermediate CAs) von eMudhra mit unzureichender Zufälligkeit erzeugt wurden – womit es für jeden möglich war, vertrauenswürdige HTTPS-Zertifikate für beliebige Websites zu fälschen. Chrome hat die betroffenen CAs innerhalb weniger Stunden nach der Meldung blockiert, und Google wird das zugehörige Root-Zertifikat am 27. Oktober, also nächsten Dienstag, aus dem Chrome Root Store entfernen.

Browser konnten das schnell beheben. Alles andere nicht. Wie Cloudflare erklärt, prüft sehr viel Software Zertifikate gegen einen eigenen Trust Store – im Betriebssystem, in Laufzeitumgebungen von Programmiersprachen, in Container-Base-Images. All das muss aktualisiert, neu gebaut und neu gestartet werden. Genau diese Art von Arbeit landet bei einem Platform-Team, und am Morgen des 21. Oktober hat das ganze VSHN-Team am CA-Fix gearbeitet.

Nachmittag: PHP2Shell

Unsere Engineers waren also schon gut ausgelastet, als das nächste Problem auftrat. Am 21. Oktober haben die PHP-Entwickler Notfall-Sicherheitsupdates veröffentlicht für zwei kritische Schwachstellen im PHP-Kern-Interpreter, CVE-2026-109618 und CVE-2026-109619. Beide sind mit 9.2 bewertet und erlauben es einem nicht authentifizierten Angreifer, auf einem betroffenen Webserver aus der Ferne Code auszuführen. Erschwerend kam hinzu, dass Details bereits am 20. Oktober online geleakt wurden – vor der koordinierten Veröffentlichung und bevor Patches verfügbar waren. Die Schwachstellen laufen inzwischen unter dem Namen “PHP2Shell”, und die Empfehlung der Sicherheitsbehörden war unmissverständlich: sofort patchen oder exponierte Anwendungen vom Netz nehmen. Die PHP Foundation hat einen eigenen Beitrag zum Release veröffentlicht und dazu, wie sie die Sicherheit von PHP künftig stärken will.

Das war kein theoretisches Risiko. Ein Hosting-Anbieter berichtete, dass Angreifer ab 08:44 UTC an jenem Morgen mit einem öffentlichen Proof-of-Concept-Exploit Anfragen an die von ihm gehosteten WordPress-Sites geschickt haben.

Was PHP ist und was darauf läuft

PHP ist eine Programmiersprache fürs Web. Sie läuft auf dem Server und baut Seiten im Moment des Aufrufs zusammen – holt Inhalte aus einer Datenbank, prüft, ob du eingeloggt bist, erzeugt das HTML und schickt es an deinen Browser. Rund 70% aller Websites laufen mit PHP. Einige der bekanntesten Anwendungen darauf:

• WordPress, inklusive WooCommerce-Onlineshops
• MediaWiki, die Software hinter Wikipedia
• Drupal
• Joomla
• TYPO3
• Magento und Shopware
• Nextcloud

Der Fehler steckt in PHP selbst, nicht in einer dieser Anwendungen oder ihren Plugins. WordPress, TYPO3 oder Nextcloud aktuell zu halten, hat also nicht geschützt. Betroffen ist jede PHP-Version der letzten zehn Jahre, zurück bis Version 5.4.

Wie wir und unsere Kunden auf PHP2Shell reagiert haben

Es gibt viele Beiträge, die erklären, was in PHP kaputt war. Spannender finden wir, was in der Praxis passiert, wenn so etwas einschlägt – deshalb hier, wie der gestrige Tag bei uns aussah.

Unser Team hat am Abend des 20. Oktober mit dem Monitoring begonnen, sobald das PHP-Projekt das anstehende Release angekündigt hatte. Die Kubernetes- und OpenShift-Plattformen, die wir für unsere Kunden betreiben, laufen selbst nicht auf PHP. Aber PHP taucht an vielen Stellen auf und rund um diese Plattformen auf, deshalb haben wir das als Major Incident über alle unsere Managed Services behandelt.

Kurz vor Mittag am 21. Oktober hat uns ein Kunde angerufen und gebeten, seine Website offline zu nehmen, bis der Fix da ist.

Auch unsere eigene Website vshn.ch war offline, vom 21. Oktober um 16 Uhr bis zum 22. Oktober um 4 Uhr morgens – 12 (!) Stunden Downtime. vshn.ch wird bei cyon.ch gehostet, einem der grössten Schweizer Webhoster, und cyon hat proaktiv alle PHP-Websites abgeschaltet, um sie zu schützen, bis PHP gepatcht war. Das sieht man nicht alle Tage – ein ganzer Hosting-Anbieter, der vorsorglich bei allen PHP-Sites gleichzeitig den Stecker zieht. Aber das könnten wir in Zukunft öfter sehen, wenn der nächste tief verborgene Fehler in einem gemeinsamen Fundament auftaucht und schnelles Patchen die einzige echte Verteidigung ist.

Sobald der Fix öffentlich war, haben wir alles andere aktualisiert. Auf virtuellen Maschinen mit PHP haben wir aktualisiert, sobald Ubuntu und Red Hat gepatchte Pakete bereitgestellt haben. Die Docker-Images, die wir pflegen, werden neu ausgerollt, sobald gepatchte Base-Images verfügbar sind. Und wo Kunden eigene PHP-Apps in Containern auf unseren Clustern betreiben, mussten auch diese Images gepatcht werden – deshalb haben wir diese Kunden gebeten, sie mit einer gepatchten PHP-Version neu zu bauen und neu auszurollen. Alle Details findest du auf unserer Statusseite.

mod_php vs. PHP-FPM: nicht jedes Setup hatte dasselbe Risiko

Alle gängigen Arten, PHP für Web-Anfragen zu betreiben, waren betroffen: Apache mit mod_php, PHP-FPM, php-cgi, FrankenPHP und LiteSpeed. Wie man PHP betreibt, war aber trotzdem wichtig. Laut den PHP-Entwicklern war das Risiko bei Setups mit Apache und mod_php am höchsten – dort haben sie einen Exploit demonstriert, der greift, bevor überhaupt Anwendungscode läuft. Bei uns kommt PHP-FPM zum Einsatz. PHP-FPM war allerdings ebenfalls betroffen, und Patchen war die einzige vollständige Lösung.

Nacht: GitLab

Als wäre der Tag nicht schon spannend genug gewesen: Spät in der Nacht hat GitLab Fixes für eine kritische Schwachstelle veröffentlicht – CVE-2026-110264, bewertet mit 10.0, dem Maximum. Damit kann ein Angreifer ohne Login Code auf einem selbst betriebenen GitLab-Server ausführen. Betroffen sind alle Versionen zurück bis 7.0 aus dem Jahr 2014, weil der Fehler in der Regex-Engine steckt, die GitLab seit jeher mitliefert. Unsere VSHNeers haben auch das gefixt.

Was wir daraus mitnehmen

Drei sehr unterschiedliche Probleme, ein gemeinsamer Nenner: Keines davon steckte in den Anwendungen, die man jeden Tag nutzt. Sie lagen in den Schichten darunter – in den Zertifikaten, die HTTPS vertrauenswürdig machen, in der Sprache, auf der der Grossteil des Webs läuft, in der Regex-Engine einer Entwicklerplattform. Jede Software, die wir betreiben, sitzt auf Schichten von Code, den jemand vor Jahren geschrieben hat und den die meisten von uns nie anschauen. Es ist leicht, jetzt mit dem Finger auf eMudhra, PHP oder GitLab zu zeigen. Bitte nicht. Heartbleed hat 2014 OpenSSL getroffen, Log4Shell 2021 die Java-Welt. Das kann jedem Fundament passieren, auf dem wir alle aufbauen.

Der KI-Aspekt

Was PHP2Shell besonders macht, ist, wie die Schwachstelle gefunden wurde. Der verwundbare Code war seit über zehn Jahren vorhanden, aber ihn auszunutzen erforderte eine aussergewöhnlich komplexe Kette von Schritten – am Rand dessen, was menschliche Forschende praktisch leisten können. Moderne KI-Modelle haben diese Hürde deutlich gesenkt. Laut den Forschenden von Wiz hat ein einzelner Forscher in einer Woche geschafft, wofür früher ein Weltklasse-Team Monate gebraucht hätte.

Das ist zugleich beängstigend und eine gute Nachricht. Beängstigend, weil “zu kompliziert zum Ausnutzen” kein Sicherheitsnetz mehr ist – Angreifer haben dieselben Werkzeuge. Gut, weil auch die Verteidiger solche tief vergrabenen Fehler jetzt schneller finden und beheben können, bevor jemand anderes sie ausnutzt. Wir sind ziemlich sicher, dass Tage wie gestern nicht selten bleiben. Rechne mit mehr davon, in mehr Sprachen, öfter. Damit zählt eines mehr denn je: wie schnell du patchen kannst.

Und an dieser Stelle möchten wir Danke sagen. Unsere VSHNeers waren schnell beim Patchen, und einige von ihnen könnten heute wirklich etwas Schlaf gebrauchen. Wenn dir also im nächsten Call jemand etwas müde vorkommt, weisst du jetzt, warum.

Was du tun solltest

Zu den Zertifikaten: Wenn deine Website ein Zertifikat nutzt, das auf emSign ECC Root CA – G3 zurückgeht, solltest du es laut Google sofort durch eines einer anderen CA ersetzen, bevor die Root am 27. Oktober aus Chrome entfernt wird. Über Browser hinaus: Aktualisiere die Trust Stores in Betriebssystemen, Laufzeitumgebungen und Container-Base-Images, baue die Images neu und starte die betroffenen Systeme neu. Und falls nach dem Patchen Zertifikatsfehler auftauchen: Behebe sie nicht, indem du die Zertifikatsprüfung abschaltest.

Zu PHP: Aktualisiere auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Wenn du eine ältere Version nutzt: PHP 8.1 und älter erhalten möglicherweise keinen Fix – kläre das mit deinem Anbieter und plane das Upgrade jetzt. Wenn dein Server über ein Hosting-Panel wie cPanel verwaltet wird, kommen die gepatchten PHP-Versionen über die Updates des Panels – aktualisiere also das Panel, nicht nur deine Anwendung. Wenn du PHP in Containern betreibst, baue deine Images auf einer gepatchten Basis neu und rolle sie neu aus. Und denk daran: Ein Patch entfernt keine bereits erfolgte Kompromittierung – wirf also auch einen Blick in deine Logs.

Zu GitLab: Wenn du eine selbst betriebene Instanz hast, aktualisiere auf die gefixte Version für deinen Release-Branch.

Wenn du nicht sicher bist, ob etwas in deinem Stack betroffen ist, melde dich bei uns. Wir sind heute etwas müde, aber wir sind da.

Und jetzt: mehr Kaffee.