Patchen & Schwachstellen

WordPress und PHP absichern: eine Patch-Routine für Website-Betreiber

Von Wladimir Neuberger · Aktualisiert

Die kurze Antwort

Sichern Sie WordPress mit einer festen Routine: Inventar aller Installationen samt PHP-Version, Updates erst im Staging und nach einem getesteten Backup, klare Absprache mit dem Hoster, wer PHP patcht, und ein Ablauf für kritische Lücken. PHP-Zweige ohne Support dürfen Sie nicht weiterbetreiben, weil dort keine offiziellen Sicherheitsupdates mehr erscheinen.

Warum PHP und WordPress zusammengehören

Eine WordPress-Seite besteht aus mindestens drei Schichten, die jeweils eigene Updates haben: dem WordPress-Kern samt Plugins und Themes, der PHP-Laufzeit auf dem Server und dem Server selbst. Viele Betreiber pflegen nur die erste Schicht, weil sie im Dashboard sichtbar ist. Die PHP-Version steht dort nur im Website-Zustand, und gepatcht wird sie in der Regel vom Hoster oder von Ihnen, nicht von WordPress.

Wie real das ist, zeigt der Katalog bekannter ausgenutzter Schwachstellen der US-Behörde CISA (CISA Known Exploited Vulnerabilities Catalog). Wir haben einen Schnappschuss mit Stand 26. Oktober 2026 selbst ausgewertet: In den zwölf Monaten bis zu diesem Datum wurden 309 Schwachstellen aufgenommen. Davon nennen drei den Hersteller WordPress (jeweils für den Kern, aufgenommen am 21. Juli 2026 zweimal und am 25. September 2026 einmal), zwei den Hersteller PHP Group (beide am 26. Oktober 2026 aufgenommen, siehe unsere Meldung zu PHP2Shell). Das sind fünf von 309 Einträgen, rund 1,6 Prozent. Die Zahl ist klein, aber jeder dieser Einträge bedeutet, dass die Lücke nach Angaben der CISA tatsächlich ausgenutzt wurde. Ein Schnappschuss ist nicht der gesamte Katalog; Plugins und Server-Software Dritter sind darin nach Hersteller sortiert und hier nicht mitgezählt.

Schritt 1: Inventar und PHP-Version

Ohne Liste lässt sich nichts patchen. Erfassen Sie jede Installation, auch Staging-Seiten, alte Kampagnenseiten und Container. Das PHP-Projekt unterstützt jeden Zweig vier Jahre: zwei Jahre mit regulären Fehlerkorrekturen, zwei weitere Jahre nur mit kritischen Sicherheitskorrekturen. Danach ist er am Ende seines Lebenszyklus, und das Projekt rät, möglichst schnell zu wechseln, weil ungepatchte Schwachstellen bleiben können. Laut der Übersicht vom 27. Oktober 2026 enden die Sicherheitskorrekturen für PHP 8.2 am 31. Dezember 2026, für 8.3 am 31. Dezember 2027, für 8.4 am 31. Dezember 2028 und für 8.5 am 31. Dezember 2029.

  • Version feststellen: im Hosting-Panel, per SSH mit „php -v“ oder in WordPress unter Werkzeuge → Website-Zustand → Info → Server.
  • Zweig und Enddatum notieren: Liegt das Ende der Sicherheitsunterstützung innerhalb der nächsten zwölf Monate, planen Sie die Migration jetzt ein (unsere Empfehlung).
  • Fehlerkorrektur-Stand prüfen: Innerhalb eines Zweigs zählt die Unterversion. Bei einem Hoster kann der Fix auch als neuer Build unter gleicher Versionsnummer erscheinen; GoDaddy empfiehlt deshalb, das Build-Datum zu prüfen.
  • Alles ohne Support ablösen: Wer PHP 8.1 oder älter betreibt, braucht einen Wechsel auf einen unterstützten Zweig. Rückportierte Korrekturen einzelner Hoster sind eine Übergangslösung.

Schritt 2: Updates ohne Ausfall einspielen

WordPress rät, vor jedem Update die Datenbank und alle Dateien zu sichern und zu prüfen, dass die Sicherung vorhanden und nutzbar ist. Die WordPress-Dokumentation zum Absichern nennt dazu regelmäßige Sicherungen der vollständigen Installation an einem vertrauenswürdigen Ort, damit sich ein Stand vor einer Kompromittierung wiederherstellen lässt. Einen Testbetrieb (Staging) beschreibt die Dokumentation nicht; er ist unsere Empfehlung, weil sich dort Fehler zeigen, bevor Besucher sie sehen.

  • Backup vorab: Datenbank und Dateien sichern und eine Wiederherstellung wenigstens einmal tatsächlich testen.
  • Staging: Kopie der Seite mit der neuen PHP-Version und den neuen Plugin-Ständen laufen lassen, Kernfunktionen wie Formulare, Checkout und Anmeldung durchklicken.
  • Reihenfolge: zuerst PHP und Kern, danach Plugins einzeln. So lässt sich bei einem Fehler das verantwortliche Plugin erkennen.
  • Ungenutztes löschen: Nicht verwendete Plugins und Themes entfernen, statt sie nur zu deaktivieren. Laut WordPress-Dokumentation gehören nicht benötigte Plugins gelöscht.
  • Danach prüfen: Version kontrollieren, Fehlerprotokoll ansehen, Dienst bei Bedarf neu starten, damit die neue PHP-Version tatsächlich läuft.

Ein Backup, das nie wiederhergestellt wurde, ist nur eine Hoffnung. Testen Sie die Wiederherstellung, bevor Sie sie brauchen.

Automatische Updates abwägen

WordPress aktiviert nach eigener Dokumentation standardmäßig automatische Updates für kleinere Kernversionen und Übersetzungen. Auf neuen Installationen ab WordPress 5.6 sind auch größere Kernversionen eingeschlossen. Plugin- und Theme-Updates laufen nur in Sonderfällen automatisch; ihre Steuerung geht über die Einstellungen oder Filter. Alle automatischen Updates abzuschalten, bezeichnet die Dokumentation als dringend nicht empfohlen.

  • Kern: Kleine Versionen automatisch laufen lassen. Das ist der Standard und bringt Sicherheitskorrekturen ohne Wartezeit.
  • Plugins und Themes: Automatik lohnt sich bei bewährten Erweiterungen mit gutem Update-Verlauf. Kritische Funktionen wie Shop oder Buchung aktualisieren Sie lieber zuerst im Staging (unsere Empfehlung).
  • PHP: Das regelt WordPress nicht. Klären Sie mit dem Hoster, ob Sicherheits-Updates automatisch eingespielt werden und wie Sie bei einem Zweigwechsel informiert werden.

Wer ist beim Hoster für was zuständig?

GoDaddy beschreibt das Beispiel eines Hosters: Bei verwaltetem WordPress-Hosting und klassischem Webhosting wurde PHP vom Anbieter gepatcht, auf einem virtuellen Server (VPS) liegt die Verantwortung beim Kunden. Das ist keine allgemeine Regel, sondern zeigt, wie unterschiedlich Verträge sein können. Fragen Sie deshalb schriftlich nach.

  • Wer aktualisiert PHP, in welcher Frist nach einer Sicherheitsmeldung, und wie erfahren Sie davon?
  • Welche PHP-Zweige bietet der Tarif an, und wann wird ein auslaufender Zweig abgeschaltet?
  • Wie lässt sich der Patch-Stand prüfen, etwa über das Build-Datum statt nur die Versionsnummer?
  • Wer sichert die Daten, wie lange werden Sicherungen vorgehalten, und wer stellt wieder her?

Zugriffe und Logs im Blick behalten

Die WordPress-Dokumentation nennt Server-Logs wertvoll für die Spurensuche: Sie enthalten IP-Adressen, Zeitpunkte und Aktionen und können unter anderem Dateieinschleusung, Verzeichniswechsel und Brute-Force-Versuche zeigen, nicht aber, welcher Benutzer sich angemeldet hat. Ergänzend empfiehlt sie, die Administration mit zweistufiger Anmeldung zu schützen, SFTP statt FTP zu nutzen und mit „DISALLOW_FILE_EDIT“ die Bearbeitung von PHP-Dateien im Dashboard zu sperren.

  • Zugriffslogs aufbewahren und nach einer Sicherheitsmeldung ab dem Veröffentlichungstag nach auffälligen Anfragen an PHP-Dateien durchsuchen.
  • Neue oder geänderte PHP-Dateien in Upload- und Cache-Ordnern sowie unbekannte Administratorkonten prüfen.
  • Zweistufige Anmeldung für alle Administratoren aktivieren und nicht mehr benötigte Konten löschen.

Wenn eine kritische Lücke gemeldet wird

Das jüngste Beispiel sind die PHP-Lücken CVE-2026-109618 und CVE-2026-109619, für die das PHP-Projekt am 21. Oktober 2026 Korrekturen veröffentlichte und die die CISA am 26. Oktober 2026 in ihren Katalog aufnahm. Patchstack weist darauf hin, dass die Fehler im PHP-Interpreter liegen und deshalb jede Seite auf einer verwundbaren Version betreffen; nur ein PHP-Update behebt sie vollständig. Ein WordPress-Update allein genügt also nicht. Ablauf in solchen Fällen, als unsere Empfehlung:

  • Betroffenheit klären: Produkt, Zweig und Unterversion mit den Angaben des Herstellers vergleichen.
  • Backup anlegen, dann auf die gepatchte Version oder das vom Hoster gelieferte Paket aktualisieren; anschließend PHP und Webserver neu starten und die Version bestätigen.
  • Bis zum Update Zwischenlösungen wie Hoster-Firewall-Regeln nutzen, aber nur als Überbrückung. PHP selbst nennt Abhilfen unvollständig.
  • Logs und Dateien auf Auffälligkeiten prüfen; bei Verdacht Zugangsdaten erneuern und von einem sauberen Backup wiederherstellen.
  • Lernen: Notieren Sie, wie lange das Patchen gedauert hat, und legen Sie die nächste Frist fest.

Aktuelle Meldungen zum Thema

Häufige Fragen

Reicht es, WordPress aktuell zu halten?

Nein. PHP wird getrennt gepflegt, und Lücken im PHP-Kern lassen sich durch WordPress-Updates nicht beheben. Prüfen Sie Version und Support-Ende Ihres PHP-Zweigs regelmäßig.

Wie finde ich heraus, welche PHP-Version meine Seite nutzt?

Im Hosting-Panel unter „PHP-Version“, per SSH mit „php -v“ oder in WordPress unter Werkzeuge → Website-Zustand → Info → Server. Bei Hostern kann der Fix unter gleicher Versionsnummer als neuer Build erscheinen.

Soll ich automatische Updates aktivieren?

Für kleine Kernversionen ist das der WordPress-Standard und sinnvoll. Für Plugins entscheiden Sie je Erweiterung; kritische Funktionen testen Sie zuerst im Staging. PHP-Updates klären Sie mit dem Hoster.

Wer ist für das PHP-Update zuständig, ich oder der Hoster?

Das hängt vom Tarif. Bei verwalteten Angeboten patcht oft der Anbieter, auf einem eigenen virtuellen Server meist der Kunde. Lassen Sie sich die Zuständigkeit schriftlich bestätigen.

Quellen

Die Einordnung beruht auf den genannten Veröffentlichungen. Prüfen Sie bei Entscheidungen die Originalquelle.

Weiterlesen

Sie möchten wissen, wo Sie stehen?

Ein Basic Scan zeigt, wo Ihre Systeme von außen angreifbar sind — mit Festpreis und Bericht. Oder Sie lassen sich kostenlos vor neuen Lücken warnen.

Sicherheitspakete ansehen Warnungen abonnieren Kontakt aufnehmen