PHP-Sicherheitslücken: Fragen an Ihre Website-Agentur

Stand: 1. November 2026. Bei einer Sicherheitsmeldung zu PHP stellt sich für viele Unternehmen zuerst eine einfache Frage: Betrifft das überhaupt unsere Website oder eine Anwendung im Hintergrund? Die Antwort erfordert eine Bestandsaufnahme. Aus dem Namen eines Website-Baukastens oder aus einer sichtbaren Startseite lässt sich nicht zuverlässig ableiten, welche Technik alle angebundenen Dienste verwenden.

Was im Oktober bekannt wurde

Sicherheitsforschende von Calif entdeckten mit Unterstützung von OpenAI eine kritische PHP-Schwachstelle; Wiz Research entdeckte und meldete unabhängig davon zwei Schwachstellen. Die Entwicklerinnen und Entwickler, die das Open-Source-Projekt PHP betreuen, entwickelten die Korrekturen und veröffentlichten am 21. Oktober 2026 Sicherheitsupdates. Die Schwachstellen können unter bestimmten Bedingungen nicht authentifizierte entfernte Codeausführung ermöglichen. Als erste korrigierte Versionen nannte das PHP-Projekt 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Forschungsbericht von Wiz · Einordnung von OpenAI. Betroffene Betreiber sollen gemäss PHP aktualisieren; es gibt laut Hersteller keine vollständige Ersatzmassnahme für das Update. Welche Version heute geeignet ist, muss der Betreiber anhand der aktuellen Hersteller- und Hosting-Hinweise prüfen. PHP-Sicherheitshinweis.

Eine Schwachstelle bedeutet nicht automatisch, dass ein Unternehmen angegriffen wurde. Manche Betreiber unterbrachen Dienste vorsorglich für Updates. Ebenso lässt sich aus einer gleichzeitig auftretenden Störung kein sicherer Zusammenhang ableiten. Der separat gemeldete Railway-Sicherheitsvorfall ist kein Beleg dafür, dass PHP dort die Ursache war.

Warum die Frage mehr als die Website betrifft

Ein Unternehmen kann mehrere öffentlich erreichbare Anwendungen betreiben: einen alten Kundenbereich, ein Formular, ein Bestellsystem, eine Integration oder eine separat gehostete Kampagnenseite. Auch ein externer Dienstleister kann Komponenten verwalten, die intern kaum jemand kennt. Ob eine Komponente PHP nutzt und betroffen ist, muss jeweils geprüft werden; eine SaaS-Anwendung kann zudem in der Verantwortung ihres Anbieters liegen.

Ein typisches, ausdrücklich fiktives Beispiel: Eine Agentur hat vor Jahren ein Formular eingerichtet. Die Hauptwebsite wurde später ersetzt, das alte Formular verarbeitet weiterhin Anfragen und sendet sie ans CRM. Die neue Website sieht aktuell aus, während die alte Anwendung im Inventar fehlt. Die Lösung beginnt mit Zuständigkeit und Bestandsaufnahme, nicht mit einer Vermutung über den Anbieter.

Sieben Fragen an Agentur oder IT-Dienstleister

1. Welche Systeme betreiben oder verwalten Sie für uns? Bitte auch Subdomains, alte Formulare, Testumgebungen und verbundene Anwendungen berücksichtigen.

2. Wo wird PHP eingesetzt und wer ist für Updates zuständig? Bei verwalteten Diensten klären, welche Nachweise der Anbieter bereitstellen kann.

3. Welche Versionen laufen tatsächlich? Installierte Pakete, Container und unterschiedliche Server können voneinander abweichen. Die verantwortliche Fachperson soll den tatsächlichen Betrieb prüfen und die aktuellen Herstellerhinweise heranziehen.

4. Sind betroffene Systeme aktualisiert und anschliessend geprüft? Datum, betroffene Systeme, durchgeführte Tests und offene Ausnahmen dokumentieren. Ein Eintrag im Projektplan allein belegt kein erfolgreiches Update.

5. Welche Daten und Zugänge sind verbunden? Prüfen, ob Formulare, Datenbanken oder CRM-Schnittstellen betroffen sein könnten. Keine Schlüsselwerte per E-Mail oder Chat als Nachweis versenden.

6. Welche Hinweise auf Missbrauch liegen vor? Zuständige Fachleute sollen verfügbare Zugriffs-, Anwendungs- und Anbieterprotokolle im relevanten Zeitraum prüfen. Fehlende Auffälligkeiten sind kein Beweis, dass nichts passiert ist.

7. Wie werden Updates, Warnungen und Wiederherstellung künftig organisiert? Zuständige Person, Eskalationsweg, Backup, Wiederherstellungstest und Wartungsfenster festlegen.

Veraltete PHP-Versionen ausserhalb des Supports brauchen einen konkreten Migrationsplan mit dem Betreiber. Die aktuelle PHP-Supportübersicht zeigt, welche Versionen noch Sicherheitsupdates erhalten.

Schwachstellen proaktiv suchen

Vorsorge endet nicht beim Einspielen einzelner Updates. Die IT-Verantwortlichen sollten Inventar und Herstellerwarnungen regelmässig abgleichen, vorhandene Sicherheitsprüfungen für eigene Systeme einplanen und Funde nach Risiko, Zuständigkeit und Frist verfolgen. Vereinbarte Schwachstellenscans oder externe Sicherheitstests können ergänzen, ersetzen aber weder Patchmanagement noch die Prüfung von Zugriffsrechten. Umfang, Erlaubnis, Testzeiten und Umgang mit Ergebnissen vorab mit allen zuständigen Betreibern schriftlich abstimmen. Sensible Funde nur über geeignete Meldewege teilen. Der BACS-Leitfaden zur Schwachstellenbehandlung beschreibt den Umgang mit Meldungen.

Mitarbeitende einbeziehen – ohne Schuldzuweisung

Ein Teammitglied kann aus guten Gründen eine zusätzliche Software testen, eine Agentur mit einer kurzfristigen Landingpage beauftragen oder einen Zugang weiterreichen, ohne die technischen Folgen zu kennen. Solche Lücken entstehen oft über Zeit und durch unklare Zuständigkeiten. Darum braucht es eine einfache Möglichkeit, neue Tools, Dienstleister und verdächtige Freigaben zu melden. Sicherheitswarnungen sollten an eine überwachte Teamadresse und eine benannte Stellvertretung gehen – nicht ausschliesslich an das Postfach einer ehemaligen Kontaktperson.

Wenn ein Risiko oder Vorfall festgestellt wird

Die verantwortlichen Fachpersonen sollten betroffene Systeme priorisieren, die Hinweise des Herstellers umsetzen und bei Verdacht auf Missbrauch die Reaktion mit IT- beziehungsweise Incident-Response-Spezialisten abstimmen. Beweise und Protokolle sichern; ein Update allein beantwortet nicht rückwirkend, ob ein Zugriff stattgefunden hat. Falls Personendaten betroffen sein könnten, Datenschutzverantwortliche früh einbeziehen und Meldepflichten nach dem anwendbaren Recht prüfen. Die Schweizer EDÖB-Hinweise und die BSI-Hilfe für KMU bieten Ausgangspunkte.

Das Ziel für Geschäftsleitungen ist eine belastbare Antwort auf drei Fragen: Welche Systeme haben wir? Wer hält sie aktuell? Und woran würden wir erkennen, dass etwas nicht stimmt? Für die anschliessende Prüfung verbundener Geschäftsprozesse: Prozessautomatisierung.