Zwei Update-Ebenen, zwei Zuständigkeiten

Wenn im WordPress-Dashboard „Alles aktuell“ steht, heißt das noch nicht, dass deine Website auf dem aktuellen Sicherheitsstand ist. WordPress ist eine Anwendung, die in PHP geschrieben ist. PHP selbst ist die Laufzeitumgebung auf dem Server, und die wird in den meisten Fällen nicht über WordPress aktualisiert, sondern vom Hoster, von der Serververwaltung oder von dir im Hosting-Panel.

Bei kleineren Firmen- und Informationswebsites sind diese beiden Ebenen oft auf verschiedene Personen verteilt. Eine Agentur oder ein Freelancer kümmert sich um WordPress, der Hoster um den Server. Wenn niemand ausdrücklich für beide Ebenen zuständig ist, bleibt eine davon leicht liegen.

EbeneWas dazugehörtWer aktualisiert typischerweise
WordPressCore, Plugins, ThemesBetreiber, Agentur, Wartungsdienst
PHPPHP-Version und Paketstand auf dem ServerHoster, Serveradministration, teils Betreiber im Panel

Die Meldungen aus September und Oktober 2026 zeigen gut, warum du beide Ebenen getrennt prüfen solltest.

Was im September und Oktober 2026 gemeldet wurde

Dieser Überblick hat den Stand vom 21. Oktober 2026. Bis du ihn liest, können weitere Sicherheitsupdates erschienen sein. Maßgeblich ist immer das jeweils aktuell verfügbare Sicherheitsupdate.

WordPress 7.1.2: kritische Lücke in der Template-Auflösung

Am 22. September 2026 hat das WordPress-Projekt Version 7.1.2 veröffentlicht. Sie schließt die als kritisch eingestufte Lücke CVE-2026-87902 (GHSA-7hp8-65ch-5whp). Nicht angemeldete Angreifer können dabei unter bestimmten Voraussetzungen die Template-Auflösung beeinflussen. Diese Voraussetzungen betreffen sowohl die Serverumgebung als auch das aktive Theme. Dann kann eine lesbare lokale PHP-Datei außerhalb der aktiven Theme-Verzeichnisse eingebunden werden, was unter diesen Bedingungen Codeausführung ermöglicht.

Das heißt nicht, dass jede WordPress-Website automatisch gleich angreifbar ist. Ob deine Konfiguration betroffen ist, lässt sich von außen aber kaum zuverlässig beurteilen. Das Projekt empfiehlt deshalb, sofort zu aktualisieren.

WordPress 7.1.3: Wartungs- und Sicherheitsrelease

Am 6. Oktober 2026 folgte WordPress 7.1.3 mit sieben Sicherheitskorrekturen und vier weiteren Fehlerbehebungen. Darunter sind Cross-Site-Scripting-Lücken, eine SQL-Injection im WXR-Export und ein Problem, durch das Kommentare zu privaten oder unveröffentlichten Beiträgen offengelegt werden konnten. Auch hier empfiehlt der Herausgeber, sofort zu aktualisieren.

PHP-Sicherheitsreleases vom 21. Oktober 2026

Am 21. Oktober 2026 hat das PHP-Projekt Sicherheitsreleases angekündigt. Sie schließen zwei kritische Lücken, CVE-2026-109618 und CVE-2026-109619, über die Codeausführung ohne Anmeldung möglich sein kann. Korrigiert sind sie in PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12.

Zwei Punkte sind für die Praxis wichtig:

  • Linux-Distributionen und Anbieter mit Langzeitpflege portieren Fixes oft in ältere Paketstände zurück. Die angezeigte Versionsnummer allein sagt dann wenig darüber aus, ob die Lücke geschlossen ist. Den tatsächlichen Patchstand muss dir der Hoster oder die Distribution bestätigen.
  • PHP 8.1 und ältere Versionen bekommen vom PHP-Projekt keine regulären Sicherheitsupdates mehr. Manche Anbieter pflegen eigene Backports. Ob das bei dir der Fall ist, musst du konkret erfragen.

Die vollständige Lösung ist das Update. Eine Web Application Firewall (WAF) allein ersetzt es nicht.

Warum es dafür kein WordPress-Update gibt

Das WordPress-Projekt hat am selben Tag zu den PHP-Lücken Stellung genommen. Die Lücken betreffen nicht speziell WordPress, und ein zusätzliches Core-Release dafür ist weder nötig noch geplant. Ein WordPress-Update ändert an diesem Problem also nichts. Du sollst deine PHP-Version prüfen und beim Hoster nach dem gefixten Paketstand fragen. Ist keine zeitnahe Abhilfe möglich, solltest du das Risiko gemeinsam mit dem Hoster verantwortungsvoll bewerten. Eine pauschale Entwarnung gibt es nicht.

So findest du deine PHP-Version

In WordPress findest du die PHP-Version unter Werkzeuge > Website-Zustand > Bericht (je nach Sprachversion auch „Info“) im Abschnitt Server. Alternativ zeigt das Hosting-Panel meist an, welche PHP-Version für die Domain eingestellt ist.

Beide Angaben sind ein Anfang, aber noch keine Antwort auf die Sicherheitsfrage:

  • Im Panel können mehrere PHP-Versionen installiert sein. Entscheidend ist die Version, mit der die Website tatsächlich ausgeführt wird.
  • Bei zurückportierten Fixes steht dort womöglich eine ältere Basisversion, obwohl das Paket bereits gepatcht ist. Umgekehrt beweist eine passende Nummer noch nicht, dass das Paket bereits eingespielt ist.

Versionsnummer ist nicht gleich Patchstand

Verlass dich bei PHP nicht allein auf die angezeigte Nummer. Lass dir vom Hoster schriftlich bestätigen, dass die für deine Website aktive PHP-Version die Korrekturen vom 21. Oktober 2026 enthält. Wenn du PHP 8.1 oder älter nutzt, frag ausdrücklich, ob und wie der Anbieter diese Version noch absichert.

Diese Fragen kannst du deinem Hoster stellen

Formuliere die Anfrage kurz und konkret. Dann bekommst du eher eine verwertbare Antwort als mit einem allgemeinen „Sind wir sicher?“:

  1. Welche PHP-Version führt meine Website unter dieser Domain tatsächlich aus?
  2. Enthält dieses PHP-Paket die Korrekturen für CVE-2026-109618 und CVE-2026-109619? Wenn ja, seit wann?
  3. Falls nicht: Bis wann wird aktualisiert, und muss ich dafür selbst etwas umstellen, etwa die Version im Panel wechseln?
  4. Falls meine PHP-Version keine regulären Updates mehr bekommt: Gibt es Backports, oder sollte ich auf eine unterstützte Version wechseln?

Hast du selbst keinen Zugriff auf Hosting oder WordPress, gib diese Fragen an deinen Betreuer oder deine Agentur weiter. Wichtig ist, dass am Ende jemand die Antwort dokumentiert.

Empfohlener Prüfablauf für deine Website

Der folgende Ablauf ist eine Empfehlung für kleinere Websites ohne eigene IT-Abteilung. Du kannst ihn an deine Situation anpassen.

  1. Verantwortlichen benennen: Lege fest, wer für WordPress und wer für PHP zuständig ist. Das kann ein und dieselbe Person sein, aber es muss ausdrücklich geklärt sein.

  2. PHP-Version und Patchstand erfragen: Kläre mit den Fragen oben, welche PHP-Version aktiv ist und ob sie die Oktober-Korrekturen enthält.

  3. Inventar erstellen: Notiere die WordPress-Version sowie alle installierten Plugins und Themes, auch deaktivierte. Was du nicht brauchst, kannst du nach Rücksprache entfernen.

  4. Backup und Rückweg sicherstellen: Prüf vor Änderungen, dass ein aktuelles Backup von Dateien und Datenbank existiert und dass klar ist, wie es zurückgespielt wird.

  5. Nicht endlos testen: Eine kurze Prüfung ist sinnvoll. Sicherheitsupdates auf unbestimmte Zeit wegen Tests zu verschieben, erhöht aber das Risiko.

  6. Updates koordiniert einspielen: WordPress-Core, Plugins, Themes und PHP in Absprache aktualisieren, damit nicht zwei Beteiligte gleichzeitig am System arbeiten.

  7. Funktionen kontrollieren: Danach Startseite, mindestens eine Unterseite, den Login, ein Kontaktformular und gegebenenfalls Shop-Funktionen wie Warenkorb und Bestellabschluss prüfen.

  8. Ergebnis dokumentieren: Datum, eingespielte Versionen, Bestätigung des Hosters und die verantwortliche Person notieren.

Wie solche Aufgaben in eine laufende Betreuung passen und welche Bausteine dazugehören, erklärt der Artikel zu WordPress-Wartung und Kosten.

Was Backups und Firewall leisten – und was nicht

Backups helfen dir, nach einem Problem einen früheren Zustand wiederherzustellen. Eine WAF kann bestimmte Angriffsmuster abfangen. Beides ist sinnvoll, ersetzt aber das Schließen der Lücke selbst nicht.

Eine noch nicht gepatchte Website ist auch nicht automatisch kompromittiert. Hast du allerdings konkrete Hinweise, etwa unbekannte Administratorkonten, veränderte Dateien oder unerwartete Weiterleitungen, ist das eine eigene Aufgabe. Ein Update entfernt keine bereits eingeschleuste Schadsoftware. In diesem Fall solltest du die Website gezielt untersuchen lassen.

Langfristig: weniger Laufzeit am öffentlichen Frontend

Erst wenn die akuten Updates erledigt sind, lohnt sich eine grundsätzliche Frage: Braucht deine Website am öffentlichen Frontend überhaupt eine laufende WordPress- und PHP-Umgebung? Viele Informationsseiten zeigen jedem Besucher dieselben Inhalte.

Bei einer rein statischen Auslieferung gibt es am öffentlichen Frontend keine WordPress- oder PHP-Laufzeit, die über die hier beschriebenen dynamischen Codepfade angegriffen werden könnte. Das gilt aber nur, wenn WordPress nicht weiterhin öffentlich erreichbar ist. Wie das funktioniert und wo die Grenzen liegen, beschreibt der Artikel WordPress als Static Site. Die technischen Wege dorthin findest du unter WordPress als HTML exportieren.

Wichtige Einschränkungen:

  • Kein Ersatz für eine Bereinigung: Ein möglicherweise kompromittiertes Quellsystem muss vor dem Export bereinigt werden. Ein Export repariert keinen Hack.
  • Nicht wartungsfrei: Server, Zugänge, externe Dienste, clientseitiges JavaScript und eine eventuell weiterbetriebene WordPress-Redaktion musst du weiterhin absichern.
  • Nicht für alles geeignet: Shops, Mitgliederbereiche, serverseitige Formulare und andere dynamische Funktionen lassen sich nicht unverändert übernehmen. Dafür musst du externe Alternativen separat planen.

Ob deine Website dafür infrage kommt, kannst du im Eignungscheck einschätzen. Passt das Ergebnis, kannst du mit dem WP2HTML-Converter eine statische Version erzeugen. Mach das am besten, nachdem WordPress und PHP aktualisiert sind und das Quellsystem sauber ist.

Primärquellen