PHP-Sicherheitsupdate (21. Oktober 2026): was Sie diese Woche tun sollten
Am 21. Oktober 2026 wurden zwei kritische PHP-Lücken geschlossen. Was Sie auf Ihrer Website prüfen, was Sie den Hoster fragen sollten, und zwei kostenlose Anleitungen zum Download.
Auf Englisch lesen: English version of this article.
Am 21. Oktober 2026 wurden zwei kritische PHP-Lücken geschlossen. Beide können es Angreifern erlauben, ohne Anmeldung Code auf Ihrem Server auszuführen. Läuft Ihre Website mit PHP, braucht sie das Sicherheitsupdate. Das betrifft WordPress, Joomla, Drupal und die meisten Online-Shops.
Quellen: PHP-Sicherheitsmitteilung vom 21. Oktober 2026 und CERT-EU Security Advisory 2026-018.
Sie wissen nicht, ob Ihre Seite PHP nutzt? Fragen Sie Ihren Hoster. Die meisten tun es.
Was Sie diese Woche tun sollten
- Eine Person verantwortlich machen. Meist sind das Inhaber oder die Person, die die Website betreut. Sie eröffnet ein dringendes Ticket beim Hoster und hakt nach, wenn keine Antwort kommt.
- PHP-Version prüfen. In WordPress unter Werkzeuge > Website-Zustand > Info > Server nachsehen (WordPress-Anleitung). Die vollständige Versionsnummer notieren.
- Den Patch anfordern. Korrigierte Versionen sind 8.2.35, 8.3.36, 8.4.27 und 8.5.12 oder eine spätere Version desselben Zweigs. Ein Backport des Anbieters, der beide CVEs (CVE-2026-109618 und CVE-2026-109619) abdeckt, gilt ebenfalls. Läuft noch PHP 8.1 oder älter, fragen Sie nach einer Korrektur des Anbieters oder einem Umstieg auf einen unterstützten Zweig.
- Prüfen, ob der Patch live läuft. Installiert heißt nicht aktiv. Lassen Sie sich vom Hoster schriftlich bestätigen, dass die Live-Seite die korrigierte Version nutzt.
- WordPress, Theme und Plugins ebenfalls aktualisieren. Das ersetzt den PHP-Patch nicht.
- Nach Spuren eines Einbruchs suchen. Unbekannte Admin-Konten, geänderte Dateien und geplante Aufgaben, die Sie nicht angelegt haben. Ein Patch entfernt keinen Einbruch, der schon passiert ist.
Wenn Sie heute nicht patchen können
Bitten Sie den Hoster, den öffentlichen Zugriff auf die Seite zu sperren, bis der Patch eingespielt ist. Ein Wartungs-Plugin oder eine Firewall-Regel allein bietet keinen ausreichenden Schutz.
Kostenlose Anleitungen
Ich habe zwei kurze Anleitungen geschrieben, die Sie an Ihren Hoster weitergeben oder für Ihre Unterlagen aufheben können. Beide enthalten ein Supportticket zum Kopieren und Abschicken.
KI-Prompt: Hilfe bei der Behebung
Möchten Sie eine zweite Meinung? Kopieren Sie diesen Prompt in Claude oder ChatGPT und füllen Sie die eckigen Klammern aus. Die KI kann Sie durch die Schritte führen, aber sie kann Ihren Server nicht selbst aktualisieren und Ihre Seite ohne Zugang nicht prüfen. Fügen Sie niemals Passwörter oder API-Schlüssel in den Chat ein.
Hilf mir, meine eigene WordPress-/PHP-Installation gegen CVE-2026-109618 und CVE-2026-109619 abzusichern. Erkläre die Schritte verständlich und führe mich durch eine überprüfte Behebung.
Website(s): [Domains]
Anwendung: [WordPress / andere / unbekannt]
Hosting und Betriebssystem: [Anbieter / System / unbekannt]
Zugang: [WordPress-Admin / Hosting-Panel / SSH / Container / MCP / keiner]
Backup-Stand: [Datum / unbekannt]
1. Prüfe zuerst die aktuellen Hauptquellen: https://www.php.net/ und https://cert.europa.eu/publications/security-advisories/2026-018/ sowie die Sicherheitshinweise meines Anbieters. Stand 22. Oktober 2026 sind die korrigierten Versionen PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12 oder spätere korrigierte Versionen im selben Zweig. Dokumentierte Backports des Anbieters, die beide CVEs abdecken, sind zulässig. Kannst du nicht im Web recherchieren, sag das und frag nach dem aktuellen Hinweis des Anbieters.
2. Beginne nur lesend. Frage fehlende Angaben ab und nutze nur verfügbare, autorisierte Werkzeuge. Ermittle die Laufzeitumgebung des Web-PHP, die Installationsart und jede betroffene Umgebung. Unterscheide CLI-PHP vom Web-PHP. Für WordPress: Werkzeuge > Website-Zustand > Info > Server. Ohne Zugang schreibst du ein konkretes Supportticket für den Hoster. Behaupte nie, Prüfungen durchgeführt zu haben, die du nicht ausführen konntest.
3. Lege einen kurzen Patchplan vor, mit Backups, Wiederherstellung und funktionalen Tests. Zeige genaue Befehle oder Panel-Schritte passend zu meiner Installation und erkläre deren Auswirkungen. Hole meine Freigabe ein, bevor du Änderungen am Produktivsystem oder Ausfallzeiten verursachst. Bevorzuge einen Patch im bestehenden, unterstützten Zweig; bei veralteten Zweigen plane eine kompatible Migration oder eine dokumentierte Korrektur des Anbieters.
4. Nach meiner Freigabe führst du nur die vereinbarten Änderungen durch, startest betroffene Dienste neu oder ersetzt Container und prüfst jede Instanz. Behaupte nicht, dass Plugin-Updates, WAF-Regeln oder ein Wartungs-Plugin PHP selbst beheben. Führe keine Exploit-Tests aus und wende keine pauschalen Speicherlimit-Workarounds an. Bitte mich nie, Passwörter, API-Schlüssel oder vollständige Konfigurationsdateien in den Chat einzufügen.
5. Belege, dass die Korrektur im Web-PHP aktiv ist. Teste Seiten, Formulare, E-Mail-Zustellung, Anmeldung und gegebenenfalls Kaufabschluss. Vereinbare einen Test, bevor echte Nachrichten verschickt oder Bestellungen ausgelöst werden. Prüfe Logs und Dateien auf Anzeichen eines Einbruchs. Werden verdächtige Aktivitäten gefunden, sichere die Beweise und binde Fachleute ein.
6. Ist ein sofortiges Patchen unmöglich, schlage eine kontrollierte Isolation vom öffentlichen Internet vor. Schließe mit dem Zustand vor und nach der Änderung je Umgebung ab, mit Belegen, Testergebnissen, offenen Punkten und Verantwortlichem. Verwende nur diese Status: "bestätigt gepatcht", "nachweislich nicht betroffen" oder "ungeprüft". Eine erreichbare Website oder ein grüner WordPress-Status beweist kein Patchen.