PHP2Shell: Nach dem Patch Logs, Passwörter und SaaS-Ausfall sauber nachsorgen

Für wen

IT-Verantwortliche und Leitung Finanzen von KMU mit 10 bis 200 Mitarbeitenden, deren Website, Shop, Buchhaltung oder Fachanwendung auf PHP läuft oder deren SaaS-Anbieter betroffen war

Zeitbedarf

Ein halber bis ein ganzer Arbeitstag für Inventar, Logprüfung und Passwortwechsel, dazu 2 Stunden für den Notfallplan

Rechtsgrundlage

Art. 5 lit. h, Art. 9 und 24 DSG; Art. 15 DSV; Art. 73b, 74a, 74b und 74e ISG; Art. 323 OR

Stand

Oktober 2026

Beginnen Sie mit einer vollständigen Liste. Das BACS empfiehlt, alle PHP-Installationen zu erfassen, auch eingebettete Komponenten in Appliances, Containern oder Fachanwendungen (BACS). Betroffen sind laut PHP-Projekt alle Installationen, die Webanfragen bedienen, ob über PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed (php.net).

Gehen Sie in vier Gruppen vor. Erstens eigene Server und Hostings: Website, Webshop, Kundenportal. Zweitens selbst betriebene Software mit PHP, etwa ein Ticketsystem im Haus. Drittens Geräte und Container mit Weboberfläche. Viertens SaaS-Dienste, bei denen Sie PHP nicht sehen, aber Daten liegen haben: Buchhaltung, Lohn, Shop-Plattform, Newsletter.

Halten Sie pro System fest, ob es aus dem Internet erreichbar ist und ob es Personendaten verarbeitet. Das BACS rät, zuerst Systeme mit Internetzugang zu behandeln, danach Anwendungen mit schützenswerten Daten oder kritischen Geschäftsprozessen.

Beispiel (fiktives Handels-KMU mit 40 Mitarbeitenden): Website mit WordPress beim Hoster, Webshop auf eigenem virtuellem Server, Ticketsystem im Haus, Cloud-Buchhaltung, Lohnsoftware beim Treuhänder. Website, Shop und Buchhaltung haben Priorität 1, das Ticketsystem ohne Internetzugang Priorität 3.

Eine Versionsnummer allein genügt nicht immer. Bei Linux-Distributionen können Korrekturen in bestehende Paketversionen zurückübertragen sein, entscheidend ist dann die Paketversion und die Angabe des Anbieters (BACS). Halten Sie für jedes System eine von drei Belegarten fest: korrigierte PHP-Version (8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder höher), bestätigter Backport der Distribution oder schriftliche Bestätigung des Hosters oder Herstellers. Das BACS empfiehlt ausdrücklich, sich die Behebung bei Hosting-Angeboten und Herstellerprodukten bestätigen zu lassen.

Prüfen Sie zwei Punkte, die oft vergessen gehen. Nach dem Update müssen die PHP-Dienste und dauerhaft laufenden PHP-Prozesse neu starten, Container sind neu zu bauen. Danach kontrollieren Sie, ob die laufende Anwendung wirklich die korrigierte Version nutzt, etwa über die Versionsanzeige im Hosting-Panel.

Seit dem 23. Oktober empfiehlt das PHP-Projekt zusätzlich, session.upload_progress.enabled=0 zu setzen, bis das nächste reguläre Bugfix-Release erscheint (php.net). Sie schützt vor einem seltenen weiteren Angriffsweg. Die Einstellung gehört in php.ini, den FPM-Pool oder die Serverkonfiguration, nicht in ini_set() oder .user.ini. Sie schaltet Fortschrittsanzeigen bei Uploads ab; das BACS weist darauf hin, dass solche Massnahmen Uploads und Formulare beeinträchtigen können. Läuft ein System noch auf PHP 8.1 oder älter, liefert das PHP-Projekt keine Updates mehr. Dann brauchen Sie eine Korrektur Ihres Anbieters oder einen Wechsel auf eine unterstützte Version.

Beispiel: Der Webshop meldet nach dem Update PHP 8.3.36, die Shop-Software zeigt aber weiter 8.3.35. Der FPM-Dienst wurde nicht neu gestartet. Nach dem Neustart stimmt die Anzeige.

Amazon empfiehlt, mindestens ab dem 17. Oktober 2026 zu untersuchen (AWS). Der Prüfzeitraum endet erst, wenn das System nachweislich mit der korrigierten Version läuft, also nach dem Neustart aus Schritt 2.

Sichern Sie zuerst, dann prüfen Sie. Fordern Sie beim Hoster sofort die Zugriffs- und Fehlerprotokolle ab dem 17. Oktober an. Viele Hostings löschen ältere Protokolle automatisch, jeder Tag Verzögerung kann Beweise kosten. Speichern Sie die Kopien ausserhalb des betroffenen Servers.

Prüfen Sie dann vier Befunde, die das BACS nennt: ungewöhnliche Anfragen, Abstürze, veränderte Dateien und unerwartete Prozesse (BACS). Amazon nennt als konkretes Merkmal den Text PHP_SESSION_UPLOAD_PROGRESS in Formular-Uploads per POST. Achtung: Normale Zugriffsprotokolle zeigen den Inhalt einer POST-Anfrage nicht. Dieses Merkmal finden Sie meist nur in Protokollen einer Web Application Firewall oder eines Proxys. Fehlerprotokolle mit gehäuften Speicherfehlern oder Abstürzen der PHP-Prozesse in diesem Zeitraum sind ebenfalls ein Hinweis, weil eine der Lücken über Speicherfehler ausgelöst wird (php.net).

Halten Sie pro System ein Ergebnis fest: unauffällig, auffällig oder nicht prüfbar. Nicht prüfbar heisst: Protokolle fehlen ganz oder für einen Teil des Zeitraums. Diesen Fall behandeln Sie in den nächsten Schritten wie einen auffälligen Befund.

Wer Schadcode auf dem Server ausführt, kann alles lesen, worauf der PHP-Prozess Zugriff hat. Dazu gehören meist das Datenbankpasswort in der Konfigurationsdatei, API-Schlüssel für Zahlungsanbieter, Bankschnittstellen oder Versanddienste und die Zugangsdaten für den Mailversand.

Die Reihenfolge zählt. Das BACS hält für gehackte Webseiten fest, dass zuerst der eigene Computer auf Schadsoftware geprüft und bereinigt wird. Erst dann ändern Sie die FTP- und CMS-Zugangsdaten, und zwar auch Passwörter für andere Dienste, die auf demselben Computer verwendet wurden (BACS, Webseite gehackt). Danach folgen Datenbank, API-Schlüssel, Hosting-Panel und Mailkonten. Sperren Sie alte Schlüssel beim Anbieter, statt nur neue anzulegen.

Wie weit Sie gehen, richtet sich nach dem Befund aus Schritt 3. Bei auffälligem oder nicht prüfbarem Befund erneuern Sie alle Geheimnisse, die auf dem Server lagen, und ziehen eine Fachperson bei (siehe unten). Bei unauffälligem und lückenlosem Befund empfiehlt die Redaktion, mindestens die Geheimnisse in Konfigurationsdateien der Priorität-1-Systeme zu erneuern. Das ist eine Vorsichtsmassnahme, keine Vorgabe des BACS.

Beispiel: Beim Webshop liegen sechs Geheimnisse auf dem Server: Datenbank, Zahlungsanbieter, Versanddienst, SMTP, Shop-Admin und SFTP. Die Logprüfung ist nicht möglich, weil der Hoster nur sieben Tage aufbewahrt. Alle sechs werden erneuert, die alten API-Schlüssel beim Zahlungsanbieter gesperrt.

Eine Verletzung der Datensicherheit liegt vor, wenn Personendaten verlorengehen, gelöscht, vernichtet, verändert oder Unbefugten offengelegt oder zugänglich gemacht werden (Art. 5 lit. h DSG). Ein unbefugter Zugriff auf die Kundendatenbank genügt.

Führt die Verletzung voraussichtlich zu einem hohen Risiko für die Persönlichkeit oder die Grundrechte der Betroffenen, melden Sie sie dem EDÖB so rasch als möglich (Art. 24 Abs. 1 DSG). Länger dauernde Abklärungen können Sie laut EDÖB-Leitfaden nicht abwarten. Fehlende Angaben liefern Sie nach (Art. 15 Abs. 2 DSV). Gemeldet wird über das Meldeportal DataBreach auf edoeb.admin.ch, mit Art, Zeitpunkt, Dauer, Betroffenen, Folgen, Massnahmen und Ansprechperson (Art. 15 Abs. 1 DSV).

Schwerwiegend sind laut Leitfaden etwa Vorfälle, die Identitätsdiebstahl oder Kreditkartenbetrug ermöglichen. Je sensibler die Daten, desto höher das Risiko. Die betroffenen Personen informieren Sie, wenn es zu ihrem Schutz erforderlich ist oder der EDÖB es verlangt (Art. 24 Abs. 4 DSG). Laut Leitfaden etwa dann, wenn sie Zugangsdaten oder Passwörter ändern müssen.

Jede Verletzung dokumentieren Sie mit Tatsachen, Auswirkungen und Massnahmen und bewahren sie mindestens zwei Jahre ab der Meldung auf (Art. 15 Abs. 4 DSV).

Die Meldepflicht an das BACS gilt nur für kritische Infrastrukturen nach Art. 74b ISG, etwa Behörden, Energieversorger, Banken, Cloud-Anbieter und unter Umständen Hersteller von Hard- oder Software, die kritische Infrastrukturen beliefern: innert 24 Stunden nach Entdeckung (BACS). Ob Sie unterstellt sind, beantwortet das BACS auf Anfrage (Art. 74a Abs. 2 ISG). Alle anderen können dem BACS Vorfälle melden, auch anonym (Art. 73b ISG).

Am 21. Oktober 2026 meldete Bexio um 11:08 Uhr, die Buchhaltungsplattform vorsorglich vom Netz genommen zu haben, wegen einer kritischen, weltweiten Sicherheitslücke in PHP. Als behoben meldete die Statusseite den Vorfall am 22. Oktober um 07:57 Uhr (Bexio-Statusseite). Der Anbieter hat schnell reagiert. Für Sie als Kunde bleiben trotzdem Fragen offen.

Der SaaS-Anbieter ist in der Regel Ihr Auftragsbearbeiter. Sie müssen sich vergewissern, dass er die Datensicherheit gewährleisten kann (Art. 9 Abs. 2 DSG). Er muss Ihnen jede Verletzung der Datensicherheit so rasch als möglich melden (Art. 24 Abs. 3 DSG). Ob Sie dann dem EDÖB melden, entscheiden Sie als Verantwortlicher.

Schicken Sie jedem Anbieter aus Schritt 1 dieselben fünf Fragen per E-Mail:
1. Seit wann läuft Ihre Plattform mit einer korrigierten PHP-Version oder einem bestätigten Backport?
2. Haben Sie die Protokolle ab dem 17. Oktober 2026 geprüft, mit welchem Ergebnis?
3. Können Sie einen unbefugten Zugriff auf unsere Daten ausschliessen?
4. Sollen wir Passwörter, API-Token oder Schnittstellenschlüssel erneuern?
5. Bestätigen Sie, dass Sie uns eine Verletzung der Datensicherheit nach Art. 24 Abs. 3 DSG melden würden?

Legen Sie die Antworten ab. Bleibt Frage 3 unbeantwortet, behandeln Sie den Dienst in Schritt 4 wie einen nicht prüfbaren Befund.

Die Lücken haben gezeigt, dass eine Cloud-Buchhaltung ohne Vorwarnung für einen halben Arbeitstag und länger ausfallen kann. Der Plan hat vier Teile. Erstens Auslöser und Entscheid: Wer erklärt den Notbetrieb, ab welcher Ausfalldauer, und wo sehen Sie den Status des Anbieters? Abonnieren Sie die Statusseite. Zweitens Vorrat: Legen Sie regelmässig einen Export der offenen Debitoren und Kreditoren, des Kundenstamms und des Kontenplans an einem Ort ab, der ohne die Software erreichbar ist. Drittens Notbetrieb: Dringende Zahlungen erfassen Sie direkt im E-Banking Ihrer Bank. Rechnungen stellen Sie aus einer Ersatzvorlage mit einem reservierten Nummernbereich aus. Planen Sie den Lohnlauf mit Puffer, denn der Lohn ist in der Regel Ende Monat auszurichten (Art. 323 Abs. 1 OR). Viertens Wiederanlauf: Nacherfassung aller Belege, Abgleich mit dem Bankkonto, Abschluss des Ausfallprotokolls.

Beispiel: Ausfall von Mittwoch, 11 Uhr, bis Donnerstag, 8 Uhr. Die Leitung Finanzen erklärt um 12 Uhr den Notbetrieb, zwei dringende Lieferantenzahlungen gehen über das E-Banking, drei Rechnungen aus der Ersatzvorlage. Am Donnerstag werden fünf Belege nacherfasst und mit dem Kontoauszug abgeglichen.

Update eingespielt, Dienst nicht neu gestartet. Laufende PHP-Prozesse arbeiten weiter mit dem alten Code. Erst der Neustart macht den Patch wirksam.

Mündliche Zusage des Hosters. «Ist erledigt» am Telefon belegt nichts. Verlangen Sie Datum und Version schriftlich.

Protokolle zu spät angefordert. Bei kurzer Aufbewahrung fehlen danach die Tage ab dem 17. Oktober.

Neue Passwörter auf einem infizierten Rechner. Wer zuerst die Passwörter ändert und dann den Computer prüft, gibt die neuen Zugangsdaten unter Umständen gleich wieder preis.

Die Zusatzeinstellung am falschen Ort. session.upload_progress.enabled=0 über ini_set() oder .user.ini greift laut PHP-Projekt zu spät. Sie gehört in php.ini oder die Pool-Konfiguration.

Ist ein Befund auffällig, finden Sie unbekannte Dateien oder Prozesse oder fehlen die Protokolle für Priorität-1-Systeme, ziehen Sie eine spezialisierte Firma für Incident Response bei. Löschen oder neu aufsetzen sollten Sie erst nach deren Sicherung, sonst gehen Spuren verloren. Für die Frage, ob ein hohes Risiko nach Art. 24 DSG vorliegt und wie Sie Kundinnen und Kunden informieren, hilft eine Datenschutzberaterin oder eine Anwältin mit Schwerpunkt Datenschutz.