Am 21. Oktober 2026 hat das PHP-Projekt Sicherheitsupdates für zwei kritische Schwachstellen veröffentlicht. Unter der Bezeichnung «PHP2Shell» werden die Lücken CVE-2026-109618 und CVE-2026-109619 diskutiert. Fehler bei der Speicherverwaltung können unter bestimmten Bedingungen ermöglichen, dass Angreifer aus der Ferne und ohne vorherige Anmeldung eigenen Programmcode auf einem betroffenen Server ausführen. Betroffen ist die Laufzeitumgebung, welche PHP-Anwendungen auf dem Server ausführt.[1][2]
PHP bildet die technische Grundlage vieler Websites und Anwendungen, darunter WordPress, Drupal und Joomla. Entsprechend können auch Onlineshops, Kundenportale und individuell entwickelte Geschäftsanwendungen betroffen sein. Die Forschenden demonstrierten zudem das Auslesen von Prozessspeicher, in dem etwa Passwörter oder technische Zugangsschlüssel liegen können. Welche Folgen ein Angriff tatsächlich hätte, hängt insbesondere von der Konfiguration, den Berechtigungen und den Verbindungen zu weiteren Systemen ab. Je nach Nutzung drohen Betriebsunterbrüche, die Offenlegung von Geschäftsgeheimnissen oder manipulierte Geschäftsprozesse. Neben den Kosten der Wiederherstellung können dadurch Umsatzausfälle und Ansprüche von Kunden entstehen.[2]
Zu prüfen ist insbesondere die PHP-Installation, auf der das Content-Management-System läuft. Das PHP-Projekt nennt sämtliche Installationen, die Webanfragen verarbeiten, als gefährdet und bewertet das Risiko bei Apache mit mod_php besonders hoch. Sicherheitskorrekturen stehen seit dem 21. Oktober in PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12 zur Verfügung. Bei Paketen eines Linux-Distributors oder eines Anbieters mit Langzeitunterstützung kann die Korrektur in eine ältere Versionslinie zurückübertragen worden sein. Entscheidend ist der belegte Korrekturstand des tatsächlich betriebenen Pakets.[1]
Die erste Aufgabe besteht darin, die eigenen Abhängigkeiten festzustellen. Die IT und die beauftragten Anbieter sollten sämtliche PHP-Systeme erfassen und öffentlich erreichbare Anwendungen vorrangig behandeln. Geschäftsleitungen sollten sich die betroffenen Systeme, die vorgesehenen Schutzmassnahmen und den Zeitpunkt der wirksamen Aktualisierung schriftlich bestätigen lassen. Bestehen technische Hindernisse, ist eine vorübergehende Einschränkung oder Abschaltung des betroffenen Dienstes gegen die Folgen eines Angriffs abzuwägen.[3]
Die vom PHP-Team beschriebenen Übergangsmassnahmen reduzieren einzelne Angriffswege. Die vollständige Behebung der veröffentlichten Schwachstellen erfordert das Sicherheitsupdate. Parallel ist zu prüfen, ob bereits Hinweise auf eine Kompromittierung vorliegen. Ein Update schliesst die bekannte Lücke; die Untersuchung bereits erfolgter Zugriffe und möglicher Hintertüren bleibt eine eigene Aufgabe. Bei einem Verdacht sollten Fachpersonen relevante Protokolle sichern und beurteilen, welche Zugangsdaten zu erneuern und welche Systeme wiederherzustellen sind.[1][3]
Aus datenschutzrechtlicher Sicht beginnt die Verantwortung bereits vor einem Schadenfall. Art. 8 DSG verpflichtet Verantwortliche und Auftragsbearbeiter zu technischen und organisatorischen Massnahmen, die eine dem Risiko angemessene Datensicherheit gewährleisten. Daraus ergibt sich für den Umgang mit bekannt gewordenen Schwachstellen eine fortlaufende Prüfungs- und Handlungspflicht. Rechtlich spricht die Kombination aus öffentlicher Erreichbarkeit, erheblichem Schadenspotenzial und verfügbaren Sicherheitskorrekturen für eine sehr hohe Priorität. Der angemessene Zeitrahmen richtet sich nach der konkreten Gefährdung und den umsetzbaren Schutzmassnahmen.[4][5]
Bei einer Aktiengesellschaft betreffen solche Risiken auch die Pflichten des Verwaltungsrats aus Art. 716a und Art. 717 OR. Er muss für eine angemessene Organisation und Aufsicht sorgen. Die operative Behebung liegt bei den zuständigen Fachpersonen; auf Leitungsebene braucht es klare Zuständigkeiten, ausreichende Ressourcen und eine verlässliche Berichterstattung. Eine persönliche Haftung nach Art. 754 OR setzt eine schuldhafte Pflichtverletzung, einen Schaden und den erforderlichen Kausalzusammenhang voraus. Massgeblich sind die damals verfügbaren Informationen und die unter den konkreten Umständen gebotenen Massnahmen.[6]
Auch bei ausgelagertem Hosting bleibt das Unternehmen für seine Datenbearbeitung verantwortlich. Nach Art. 9 Abs. 2 DSG muss es sich insbesondere vergewissern, dass der Auftragsbearbeiter die Datensicherheit gewährleisten kann. Praktisch gehören dazu der Korrekturstand, der Zeitpunkt der Umsetzung und die Abgrenzung der Aufgaben zwischen Hoster, Webagentur und Unternehmen. Verträge sollten zudem festhalten, wie rasch kritische Schwachstellen behandelt werden, wer Sicherheitsvorfälle meldet und welche Unterstützung bei der Aufklärung geschuldet ist.[7]
Werden vereinbarte Wartungs-, Sicherheits- oder Informationspflichten verletzt, können Schadenersatzansprüche nach Art. 97 OR entstehen. Massgeblich sind die geschuldeten Leistungen, der Schaden und der Kausalzusammenhang; das Verschulden wird bei dieser vertraglichen Haftung grundsätzlich vermutet. Hinzu kommen die konkreten Vertragsbestimmungen und die gesetzlichen Grenzen von Haftungsbeschränkungen.[6]
Für die Meldepflichten ist zwischen Verwundbarkeit und Datensicherheitsverletzung zu unterscheiden. Die Feststellung einer verwundbaren PHP-Version löst zunächst Abklärung und Absicherung aus. Für Art. 24 DSG ist eine Verletzung der Datensicherheit im Sinne von Art. 5 lit. h DSG massgeblich. Dazu zählen etwa das Zugänglichmachen von Personendaten an Unbefugte sowie deren widerrechtliche Veränderung oder Verlust. Bereits eine unbefugte Zugänglichkeit kann relevant sein. Die rechtliche Prüfung umfasst damit mehr als den Nachweis eines tatsächlichen Datenabflusses.[4]
Führt eine solche Verletzung voraussichtlich zu einem hohen Risiko für die Persönlichkeit oder die Grundrechte der Betroffenen, muss der Verantwortliche den EDÖB so rasch als möglich informieren. Im Zentrum stehen die möglichen Folgen für die betroffenen Menschen, etwa durch offengelegte Gesundheitsdaten oder missbrauchbare Zugangsdaten. Nach dem Leitfaden des EDÖB ist bei erkennbarem voraussichtlich hohem Risiko zeitnah zu melden, während längere Abklärungen weiterlaufen. Fehlende Angaben können nachgeliefert werden. Bei der Risikobeurteilung sind erst geplante Abhilfemassnahmen ausser Betracht zu lassen.[8]
Ein Auftragsbearbeiter muss dem Verantwortlichen jede Verletzung der Datensicherheit so rasch als möglich melden, unabhängig von einer Einstufung als hohes Risiko. Betroffene Personen sind nach Art. 24 Abs. 4 DSG zu informieren, wenn ihr Schutz dies erfordert oder der EDÖB es verlangt. Das kann beispielsweise der Fall sein, wenn sie ihre Zugangsdaten ändern müssen. Diese Informationspflicht ist eigenständig zu beurteilen. Unternehmen sollten deshalb die behördliche Meldung und die Kommunikation mit Kunden, Mitarbeitenden oder Patienten getrennt prüfen.[8]
Weitere Meldepflichten können hinzukommen. Seit dem 1. April 2025 müssen die vom Informationssicherheitsgesetz erfassten Betreiber kritischer Infrastrukturen bestimmte Cyberangriffe dem Bundesamt für Cybersicherheit, BACS, innerhalb von 24 Stunden nach ihrer Entdeckung melden. Relevant sind unter anderem Angriffe, welche die Funktionsfähigkeit gefährden, einen Informationsabfluss oder eine Manipulation bewirken oder mit Erpressung verbunden sind. Ob ein Unternehmen erfasst ist, richtet sich nach dem gesetzlichen Anwendungsbereich und den Ausnahmen.[9]
Für FINMA-beaufsichtigte Institute gelten zusätzlich die aufsichtsrechtlichen Vorgaben. Bei einer Cyberattacke, welche die Wesentlichkeitsschwelle erreicht, erwartet die FINMA grundsätzlich eine Erstmeldung innerhalb von 24 Stunden ab Entdeckung und eine vollständige Meldung innerhalb von 72 Stunden. Die Fristen werden grundsätzlich an offiziellen Bankarbeitstagen gezählt; schwerwiegende Attacken sind auch ausserhalb dieser Tage innert 24 Stunden zu melden. Bei ausgelagerten Funktionen kann bereits die Entdeckung durch den Drittanbieter den Fristenlauf auslösen. Gerade Banken müssen deshalb ihre vertraglichen Meldewege so ausgestalten, dass die erforderlichen Informationen rechtzeitig eintreffen.[10]
Unternehmen mit einem Bezug zum EU-Markt sollten ausserdem die Anwendbarkeit der DSGVO prüfen. Soweit sie anwendbar ist, sieht Art. 33 eine unverzügliche Meldung und möglichst eine Meldung binnen 72 Stunden ab Kenntnis der Datenschutzverletzung vor. Die Meldeschwelle liegt tiefer als beim Schweizer DSG und erfasst grundsätzlich bereits ein voraussichtliches Risiko für die Rechte und Freiheiten. Für eine Befreiung muss die Verletzung voraussichtlich ohne ein solches Risiko bleiben. Die jeweiligen Adressaten, Schwellen und Fristen sind daher gesondert zu beurteilen.[11]
Schliesslich können vorsätzliche Verstösse gegen die vom Bundesrat festgelegten Mindestanforderungen an die Datensicherheit nach Art. 61 lit. c DSG auf Antrag mit Busse bis zu CHF 250’000 geahndet werden. Die Strafbestimmungen richten sich primär an natürliche Personen. Eine solche Sanktion setzt die Erfüllung des konkreten Straftatbestands voraus. Ein Sicherheitsvorfall oder ein verspätetes Update allein erlaubt deshalb noch keine verlässliche Aussage über die Strafbarkeit. Die zivilrechtliche Haftung ist separat zu prüfen und kann auch bei Fahrlässigkeit relevant werden.[4][12]
Für die Geschäftsleitung empfiehlt sich jetzt ein kurzer, belastbarer Lagebericht. Er sollte ausweisen, welche Anwendungen betroffen sind, welche Korrekturen wirksam installiert wurden, welche Angriffsspuren geprüft werden und wer über Meldepflichten entscheidet. Bleibt ein Dienst vorübergehend verwundbar, gehören die Gründe, die ergänzenden Schutzmassnahmen und ein verbindlicher Behebungstermin in die Entscheidung. Diese Dokumentation schafft die Grundlage, um technische Risiken gezielt zu reduzieren und das Vorgehen gegenüber Kunden, Vertragspartnern und Aufsichtsbehörden nachvollziehbar zu machen.