Website-Sicherheit wird oft unterschätzt: Diese Schwachstellen sehe ich in der Praxis immer wieder

Website-Sicherheit wird häufig erst dann zum Thema, wenn bereits etwas passiert ist: Eine Website zeigt fremde Inhalte, versendet Spam, leitet Besucherinnen und Besucher auf unseriöse Seiten weiter oder ist plötzlich nicht mehr erreichbar. In vielen Fällen beginnt das Problem jedoch deutlich früher – mit veralteten Softwareversionen, nicht mehr benötigten Erweiterungen oder einer Konfiguration, die über Jahre unverändert geblieben ist.

Die beiden im Oktober 2026 veröffentlichten PHP-Schwachstellen CVE-2026-109618 und CVE-2026-109619, zusammen als PHP2Shell bezeichnet, führen diesen Zusammenhang deutlich vor Augen. Betroffen ist nicht nur eine einzelne Anwendung, sondern der PHP-Laufzeitruntime, wenn sie Webanfragen verarbeitet. Für die betroffenen PHP-Versionen wurden Sicherheitsupdates veröffentlicht. Je nach eingesetzter Version sind mindestens PHP 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 erforderlich. Auch Linux-Distributionen und Hosting-Anbieter können eigene Pakete bereitstellen.

PHP2Shell ist deshalb kein Argument dafür, eine bestimmte Website-Technologie grundsätzlich als unsicher zu bezeichnen. Es ist aber ein deutlicher Hinweis darauf, dass eine Website immer aus mehreren Schichten besteht: Webserver, PHP, Datenbank, Framework oder Content-Management-System, Erweiterungen, Theme, Serverkonfiguration und individuelle Anwendung. Jede dieser Schichten muss nachvollziehbar gewartet werden.

PHP2Shell: Warum der Unterbau einer Website wichtig ist

Bei CVE-2026-109618 und CVE-2026-109619 handelt es sich um kritische Schwachstellen in PHP, die unter bestimmten Bedingungen eine nicht authentifizierte Ausführung von Code ermöglichen können. Vereinfacht gesagt geht es um Fehler bei der Verarbeitung interner Zustände und Speicherbereiche während der Verarbeitung von Webanfragen. Ein Angreifer muss dafür nicht zwingend zunächst ein Benutzerkonto in der Website besitzen.

Das entscheidende Detail: Eine Anwendung kann im Quellcode sauber entwickelt sein und trotzdem gefährdet bleiben, wenn auf dem Server eine verwundbare PHP-Version läuft. Das gilt für individuell programmierte Websites ebenso wie für WordPress, WooCommerce, Drupal oder andere PHP-basierte Systeme.

Für den Betrieb bedeutet das:

• Prüfen Sie, welche PHP-Version tatsächlich für die Website verwendet wird. Die Version im lokalen Entwicklungsrechner ist nicht maßgeblich.
• Aktualisieren Sie PHP auf eine vom PHP-Projekt oder vom jeweiligen Distribution-Anbieter unterstützte und gepatchte Version.
• Starten Sie nach dem Update PHP-FPM, den Webserver oder den betroffenen Dienst neu, sofern dies für die Umgebung erforderlich ist.
• Prüfen Sie bei einer nicht zeitnah gepatchten Installation die Protokolle und die Integrität der Website.
• Wenn ein Update nicht sofort möglich ist, sollte die betroffene Anwendung zumindest vorübergehend isoliert oder vom Internet getrennt werden. Eine vorgeschaltete Schutzmaßnahme ersetzt das Update nicht.

PHP selbst weist darauf hin, dass die Sicherheitsupdates alle PHP-Installationen betreffen, die Webanfragen verarbeiten. Besonders wichtig ist die Unterscheidung zwischen der PHP-Version und der Version der Website-Anwendung: Ein WordPress-Update aktualisiert nicht automatisch PHP auf dem Server.

Am 23. Oktober 2026 veröffentlichte das PHP-Projekt zusätzlich einen Hinweis zu einer weiteren, ungewöhnlichen Konfigurationskombination im Zusammenhang mit dem Session-Upload-Fortschritt. Das ist ein gutes Beispiel dafür, warum Sicherheitsarbeit nicht mit einem einzelnen Patch endet. Nach einem kritischen Update sollten Konfiguration, Protokolle und laufende Dienste kontrolliert werden.

Die häufigsten Schwachstellen liegen nicht im spektakulären Bereich

In der Praxis sind es oft wiederkehrende organisatorische und technische Fehler, die eine Website angreifbar machen. Viele davon wirken zunächst unscheinbar. Zusammengenommen können sie jedoch die Angriffsfläche deutlich vergrößern.

1. Veraltete Software und fehlende Zuständigkeit

Eine Website besteht meist aus mehr Software, als auf den ersten Blick sichtbar ist. Neben dem CMS oder der individuellen Anwendung laufen PHP, Webserver, Datenbank, Betriebssystem, JavaScript-Abhängigkeiten und gegebenenfalls externe Dienste.

Ein häufiger Fehler ist, dass niemand eindeutig dafür verantwortlich ist, Sicherheitsupdates zu prüfen und einzuspielen. Dann bleibt ein System nach dem Relaunch zunächst aktuell, wird aber über Jahre nicht mehr systematisch gepflegt.

Die Lösung ist ein einfacher, dokumentierter Wartungsprozess:

• Inventarisieren Sie die eingesetzten Komponenten und Versionen.
• Legen Sie fest, wer Sicherheitsmeldungen bewertet.
• Definieren Sie für kritische Updates eine kurze Reaktionszeit.
• Testen Sie Updates zunächst in einer Staging-Umgebung, wenn die Website geschäftskritisch ist.
• Dokumentieren Sie Änderungen und halten Sie eine Rückfallmöglichkeit bereit.

Eine alte, aber bekannte Version ist nicht automatisch sicherer als eine neue Version. Entscheidend ist, ob Sicherheitslücken geschlossen werden und ob die Anwendung mit der aktualisierten Umgebung kompatibel ist.

2. WordPress mit zu vielen Plugins

WordPress ist nicht grundsätzlich unsicher. Das Projekt stellt selbst umfangreiche Sicherheitsmechanismen bereit und empfiehlt, WordPress, Themes und Plugins aktuell zu halten. Gleichzeitig erhöht jedes zusätzliche Plugin die Komplexität der Installation. Es bringt eigenen PHP-Code, eigene Berechtigungen, eigene Schnittstellen und einen eigenen Wartungsbedarf mit.

In vielen gewachsenen Installationen finden sich Plugins für Funktionen, die längst nicht mehr benötigt werden. Andere Erweiterungen überschneiden sich, werden nicht mehr gepflegt oder stammen aus unbekannten Quellen. Besonders problematisch sind Erweiterungen, die Dateien hochladen, Benutzerkonten verwalten, externe Inhalte einbinden oder administrative AJAX-Schnittstellen bereitstellen.

Praktische Maßnahmen sind:

• Deaktivieren und löschen Sie nicht benötigte Plugins vollständig.
• Verwenden Sie möglichst wenige, aktiv gepflegte Erweiterungen.
• Prüfen Sie, ob eine kleine individuelle Funktion ohne zusätzliches Plugin umgesetzt werden kann.
• Vermeiden Sie Plugins aus inoffiziellen Quellen und sogenannte nulled Plugins.
• Kontrollieren Sie nach Updates, ob Funktionen und Berechtigungen weiterhin korrekt arbeiten.

Der oft zitierte Begriff „Plugin-Wildwuchs“ ist kein technischer Messwert. Er beschreibt aber ein reales Wartungsproblem: Je mehr voneinander unabhängige Komponenten eine Website enthält, desto schwieriger werden Updates, Tests und Fehlersuche.

3. Unsichere Dateiuploads

Dateiuploads gehören zu den häufigsten Angriffsflächen. Das betrifft Kontaktformulare mit Anhängen, Bewerbungsportale, Kundenbereiche, Medienverwaltungen und Systeme zur Dokumentenablage.

Eine Endung wie .jpg allein ist kein ausreichender Schutz. Dateien können manipuliert sein, falsche MIME-Typen angeben oder so gespeichert werden, dass sie später vom Webserver als ausführbarer Code behandelt werden.

Ein sicherer Upload sollte unter anderem:

• die Dateigröße begrenzen,
• erlaubte Dateitypen serverseitig prüfen,
• den Inhalt gegebenenfalls mit einer Bibliothek validieren,
• Dateinamen nicht ungeprüft übernehmen,
• Dateien außerhalb des öffentlich ausführbaren Bereichs speichern,
• den direkten Zugriff kontrollieren und
• keine ausführbaren Dateitypen akzeptieren, wenn sie nicht zwingend erforderlich sind.

Bei individuellen Webanwendungen sollte außerdem geprüft werden, ob ein Upload überhaupt öffentlich erreichbar sein muss. Häufig reicht es, Dateien intern abzulegen und nur nach erfolgreicher Berechtigungsprüfung auszuliefern.

4. SQL-Injection und unsichere Eingabeverarbeitung

SQL-Injection entsteht, wenn Eingaben aus Formularen, URLs oder Cookies direkt in Datenbankabfragen eingebaut werden. Moderne Datenbankbibliotheken und Frameworks bieten dafür vorbereitete Abfragen und Parametrisierung. Sie müssen allerdings konsequent verwendet werden.

Eine Eingabe zu maskieren oder einzelne Zeichen zu ersetzen, ist kein verlässlicher Ersatz für parametrisierte Abfragen. Zusätzlich sollten Eingaben typisiert und inhaltlich validiert werden. Eine ID, die als Ganzzahl erwartet wird, sollte auch als Ganzzahl verarbeitet werden. Ein Suchfeld benötigt andere Regeln als ein Datum oder eine E-Mail-Adresse.

Bei WordPress sollten die vorgesehenen Datenbankfunktionen verwendet werden. Bei einer klassischen PHP-Anwendung sollte der Datenbankzugriff zentral über eine gut getestete Abstraktionsschicht erfolgen. Dadurch sinkt das Risiko, dass einzelne Stellen im Code Sicherheitsregeln umgehen.

5. Cross-Site-Scripting und fehlendes Escaping

Cross-Site-Scripting, kurz XSS, entsteht, wenn fremde Eingaben später als HTML oder JavaScript im Browser anderer Personen ausgegeben werden. Typische Quellen sind Suchbegriffe, Kommentare, Profilfelder, Fehlermeldungen oder importierte Inhalte.

Die zentrale Regel lautet: Eingaben validieren, Ausgaben kontextbezogen maskieren. HTML-Ausgabe, Attribute, JavaScript-Kontext und URLs benötigen unterschiedliche Verfahren. Eine pauschale Funktion für alle Situationen ist daher selten ausreichend.

Auch ein Content-Management-System schützt nicht automatisch vor jedem XSS-Problem. Rollen, Rechte und die Möglichkeit, HTML einzufügen, müssen zur tatsächlichen Aufgabe der jeweiligen Benutzerinnen und Benutzer passen.

6. Zu weitreichende Benutzerrechte

Viele Websites verwenden einen einzigen Administratorzugang für mehrere Personen. Das ist bequem, erschwert aber die Nachvollziehbarkeit und vergrößert den Schaden, wenn Zugangsdaten kompromittiert werden.

Besser sind persönliche Benutzerkonten, klar getrennte Rollen und möglichst wenige Administrationsrechte. Redakteurinnen und Redakteure müssen nicht zwingend Plugins installieren oder Servereinstellungen ändern können. Für Administrationsbereiche sollten starke Passwörter, Mehrfaktor-Authentisierung und – wo möglich – zusätzliche Zugriffsbeschränkungen eingesetzt werden.

7. Fehlende Trennung von Anwendung und Server

Eine Website sollte nicht mehr Zugriff auf das Betriebssystem, die Datenbank oder andere Anwendungen erhalten, als sie für ihren Zweck benötigt. Dazu gehören getrennte Datenbankbenutzer, restriktive Dateirechte und eine Konfiguration, in der sensible Dateien nicht öffentlich erreichbar sind.

Konfigurationsdateien, Backups, Protokolle, Versionskontrollverzeichnisse und temporäre Dateien gehören nicht in das öffentlich ausgelieferte Webverzeichnis. Fehlermeldungen mit vollständigen Dateipfaden oder Zugangsdaten dürfen in der Produktionsumgebung nicht sichtbar sein.

WordPress oder klassisch programmierte Website?

Für viele kleinere Projekte wird WordPress eingesetzt, weil Inhalte schnell gepflegt werden können und zahlreiche Erweiterungen verfügbar sind. Das kann sinnvoll sein, wenn die Website mit wenigen, gut ausgewählten Komponenten auskommt und regelmäßig gewartet wird.

Bei individuelleren Anforderungen bevorzuge ich häufig eine klassisch programmierte Website oder eine schlanke individuelle Anwendung. Der entscheidende Vorteil ist nicht, dass individueller Code automatisch sicherer wäre. Der Vorteil liegt in der besseren Begrenzbarkeit:

• Es gibt weniger nicht benötigte Funktionen.
• Die Zahl der externen Komponenten bleibt überschaubar.
• Benutzerrollen und Geschäftslogik können gezielt umgesetzt werden.
• Updates lassen sich auf die tatsächlich eingesetzten Abhängigkeiten konzentrieren.
• Die Datenflüsse und Schnittstellen sind leichter zu dokumentieren.

Eine individuelle Website bringt allerdings eine andere Verantwortung mit sich. Sicherheitsupdates für PHP, Bibliotheken, Webserver und Betriebssystem müssen weiterhin geplant werden. Selbst geschriebener Code muss geprüft, getestet und langfristig gewartet werden. Eine klassische Umsetzung ist also kein Freibrief, sondern eine Entscheidung für eine kontrolliertere technische Basis.

WordPress kann die bessere Wahl sein, wenn viele Personen Inhalte pflegen, redaktionelle Prozesse wichtig sind oder bewährte Funktionen benötigt werden. Dann sollte die Installation bewusst klein gehalten werden. Ein schlankes Theme, wenige gut gepflegte Plugins, getrennte Benutzerkonten und ein belastbarer Updateprozess sind wichtiger als eine möglichst große Funktionsauswahl.

Backups helfen nur, wenn eine Wiederherstellung möglich ist

Ein Backup ist keine Sicherheitsmaßnahme, wenn es nur auf dem gleichen Server liegt wie die Website oder nie getestet wurde. Bei einem kompromittierten System können auch Sicherungen verändert oder gelöscht worden sein.

Mindestens eine Sicherung sollte getrennt vom Produktivsystem aufbewahrt werden. Für Datenbanken, Uploads, Konfiguration und gegebenenfalls Benutzerdaten gelten unterschiedliche Anforderungen. Zusätzlich sollte regelmäßig eine Wiederherstellung in einer isolierten Umgebung getestet werden.

Ein brauchbarer Backupplan beantwortet konkrete Fragen:

• Wie häufig wird gesichert?
• Wie lange werden Sicherungen aufbewahrt?
• Wer kann darauf zugreifen?
• Wie wird verhindert, dass ein kompromittierter Server alle Sicherungen löscht?
• Wie lange dauert eine Wiederherstellung?
• Welche Daten müssen nach einem Vorfall zusätzlich zurückgesetzt oder geprüft werden?

Was nach einem Sicherheitsvorfall zu tun ist

Wenn eine Website manipuliert wurde oder ein kritischer Verdacht besteht, sollte nicht einfach nur ein einzelnes Plugin aktualisiert werden. Zuerst muss der Vorfall eingegrenzt werden. Dazu gehören die Sicherung relevanter Protokolle, die Prüfung von Benutzerkonten, die Kontrolle neu angelegter Dateien und die Suche nach unerwarteten Änderungen.

Passwörter und Zugangsschlüssel sollten aus einer vertrauenswürdigen Umgebung heraus geändert werden. Das betrifft nicht nur das CMS, sondern auch Hosting, Datenbank, SFTP, SSH, E-Mail und externe Schnittstellen. Je nach Art des Vorfalls kann es sinnvoll sein, die Website aus einem geprüften Backup neu aufzusetzen, statt einzelne Dateien manuell zu bereinigen.

Bei PHP2Shell ist besonders wichtig: Ein erfolgreich ausgenutzter Fehler kann theoretisch Code außerhalb der eigentlichen Website-Anwendung ausführen. Deshalb reicht die Aussage „WordPress sieht normal aus“ nicht aus, um einen kompromittierten Server auszuschließen.

Eine praktische Sicherheitsroutine für kleinere Organisationen

Für viele Unternehmen und Einrichtungen ist keine umfangreiche Sicherheitsabteilung vorhanden. Trotzdem lässt sich eine wirksame Grundroutine etablieren:

1. Bestand aufnehmen: Erfassen Sie Domain, Hosting, PHP, Webserver, Datenbank, CMS, Plugins, Themes, externe Dienste und Zugänge.
2. Verantwortung festlegen: Benennen Sie eine Person oder einen Dienstleister, der Sicherheitsmeldungen bewertet und Updates koordiniert.
3. Angriffsfläche reduzieren: Entfernen Sie ungenutzte Plugins, Testseiten, alte Benutzerkonten und nicht benötigte Dienste.
4. Updates priorisieren: Kritische Sicherheitsupdates für öffentlich erreichbare Systeme dürfen nicht monatelang aufgeschoben werden.
5. Zugänge absichern: Verwenden Sie persönliche Konten, starke Passwörter und Mehrfaktor-Authentisierung für administrative Bereiche.
6. Backups testen: Führen Sie Wiederherstellungen regelmäßig durch und bewahren Sie Sicherungen getrennt auf.
7. Protokolle beobachten: Prüfen Sie ungewöhnliche Logins, neue Dateien, Fehlermeldungen und unerwartete Weiterleitungen.

Website-Sicherheit ist damit weniger ein einzelnes Produkt als ein fortlaufender Prozess. Die technische Architektur beeinflusst, wie gut dieser Prozess beherrschbar ist. Eine schlanke, klassisch programmierte Website kann dabei Vorteile haben, wenn sie tatsächlich überschaubar bleibt und professionell gepflegt wird. WordPress kann ebenfalls sicher betrieben werden, wenn die Installation nicht mit unnötigen Erweiterungen überladen wird.

Entscheidend ist nicht das Etikett der Technologie, sondern ob Verantwortlichkeiten, Updates, Berechtigungen, Backups und die technische Struktur nachvollziehbar sind.