Wissen · Sicherheit

PHP-Sicherheitslücke: Was die Mail Ihres Hosters für Ihre Website bedeutet

Martin Meinhold · Stand: 23. Oktober 2026 · Lesezeit ca. 6 Minuten

Was passiert ist

Am 20. Oktober 2026 hat das PHP-Team zwei kritische Lücken angekündigt und am 21. Oktober die Korrekturen veröffentlicht. In Fachkreisen heißen sie „PHP2Shell“ (CVE-2026-109618 und CVE-2026-109619). Ein Angreifer kann damit über eine präparierte Anfrage eigenen Code auf dem Webserver ausführen, ohne Zugangsdaten und noch bevor WordPress oder ein anderes System überhaupt zu arbeiten beginnt. Korrigiert wurden nur die aktuell gepflegten Versionen PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Für ältere Versionen wie 8.0 oder 8.1 gibt es vom PHP-Team nur einen Quellcode-Flicken, den der Hoster selbst einbauen muss.

Am 23. Oktober kam ein Nachzügler dazu (CVE-2026-115560). Er setzt eine ungewöhnliche Konfiguration voraus, das PHP-Team stuft ihn als unwahrscheinlich ein und liefert die Korrektur mit dem nächsten regulären Update. Kein Notfall, nur der Vollständigkeit halber.

Erste Angriffsversuche im Netz sind dokumentiert, unter anderem von Cloudflare und Qualys. Ob eine bestimmte Website betroffen war, lässt sich von außen nicht sagen.

Betrifft mich das? WordPress, Joomla, TYPO3 und Shops: ja

PHP ist die Programmiersprache, in der die meisten Content-Management-Systeme laufen: WordPress, Joomla, TYPO3, Drupal, dazu Shopsysteme wie WooCommerce, Shopware oder Magento. Läuft Ihre Website auf einem davon, verarbeitet PHP auf dem Server Ihres Hosters jede einzelne Anfrage. Genau dort sitzt die Lücke.

Nicht betroffen sind statische Websites: fertige Dateien, die der Server nur ausliefert, ohne etwas zu berechnen. Dazu weiter unten mehr.

So finden Sie es heraus:

• Die Mail Ihres Hosters. Hoster schreiben in der Regel nur Kunden an, bei denen PHP im Einsatz ist. Wer so eine Mail bekommen hat, ist mit hoher Wahrscheinlichkeit betroffen.
• In WordPress. Unter Werkzeuge → Website-Zustand → Reiter „Info“ → „Server“ steht die PHP-Version. Liegt sie unter 8.2, gibt es für Ihre Version keinen offiziellen Patch, dann zählt allein, was der Hoster nachgerüstet hat.
• Von außen. Mit meinem kostenlosen PHP-Check auf PageCheck sehen Sie in 30 Sekunden, was über die PHP-Angriffsfläche Ihrer Seite von außen erkennbar ist, und was Sie Ihren Hoster fragen sollten.

Was Sie jetzt tun

1. Fragen Sie Ihren Hoster, schriftlich. Nur er kann die Korrektur einspielen, und nur er kann bestätigen, dass sie eingespielt ist. Ein Fragetext zum Kopieren steht gleich unten.
2. Halten Sie WordPress, Theme und Plugins aktuell. Gegen die PHP-Lücke selbst hilft das nicht. Aber wer auf Ihrem Server landet, sucht als Nächstes nach veralteten Plugins. Weniger Plugins, weniger Fläche.
3. Prüfen Sie Ihre Sicherung. Wann wurde zuletzt gesichert, liegt die Kopie außerhalb des Webspace, und haben Sie sie jemals zurückgespielt? Eine Sicherung, die nie getestet wurde, ist eine Hoffnung.

Ehrlich dazu: Ein Backport ändert die Versionsnummer nicht. Hat Ihr Hoster die Korrektur in eine ältere PHP-Version eingebaut, zeigt WordPress weiterhin zum Beispiel „8.0.30“ an. Ob der Patch drauf ist, sieht man von außen nicht, auch ich nicht. Deshalb die schriftliche Bestätigung.

Betreff: PHP-Sicherheitslücken CVE-2026-109618 / CVE-2026-109619 – Stand für meine Domain

Guten Tag,

ich habe Ihre Information zu den aktuellen PHP-Sicherheitslücken erhalten. Bitte um kurze schriftliche Auskunft:

1. Welche PHP-Version läuft derzeit für meine Domain [meine-domain.at]?
2. Ist die Korrektur vom 21.10.2026 bereits eingespielt – also PHP 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 bzw. ein Backport für eine ältere Version? Falls Backport: in welcher Paketversion?
3. Falls noch nicht: bis wann?
4. Kann ich in meinem bestehenden Tarif auf eine aktuell gepflegte PHP-Version (8.2 oder neuer) wechseln?

Vielen Dank, ich brauche die Bestätigung für meine Unterlagen.

Freundliche Grüße
[Name, Betrieb]

Aus der Praxis dieser Woche

Ich betreue eine Hotel-Website auf WordPress, die bei ihrem Hoster noch auf PHP 8.0 läuft, einer Version, für die es keinen offiziellen Patch gibt. Was ich diese Woche gemacht habe, zeigt ganz gut, wie Betreuung in so einem Fall aussieht:

• Dateien gegen die Originale geprüft. Ich habe eine vollständige Sicherung gezogen und alle 3.782 Kerndateien von WordPress mit den offiziellen Prüfsummen verglichen, dazu Upload-Ordner, Datenbank und Benutzerkonten. Ergebnis: keine fremde Datei, keine Veränderung, nur das nächtliche Übersetzungsupdate von WordPress. Am nächsten Morgen dasselbe noch einmal mit einer frischen Sicherung.
• Hoster gefragt. Welche Version läuft, wird 8.0 gepatcht, ist ein Wechsel auf 8.2 oder 8.3 im bestehenden Tarif möglich? Die Antwort kam am nächsten Tag: Der Hoster spielt den Backport für 8.0 ein.
• Testumgebung mit PHP 8.3 durchgespielt. Parallel habe ich eine Kopie der Seite auf PHP 8.3 gestellt und alles durchgeklickt: alle Seiten in zwei Sprachen, Kontaktformular, Buchungsstrecke, Backend, Bild-Upload. Ergebnis: läuft, sogar etwas schneller. Falls der Wechsel einmal ansteht, ist die Vorarbeit erledigt.

Was ich nicht kann: in die Server-Protokolle schauen. Ob jemand einen Angriff versucht hat, sieht nur der Hoster. Das gehört zur Wahrheit dazu.

Warum Seiten von meinhold.at diese Woche nichts zu patchen hatten

Die Websites, die ich für Betriebe in Baden und Umgebung baue, sind statisch: fertige HTML-Dateien, die der Server nur ausliefert, egal bei welchem Anbieter sie liegen. Es gibt keinen PHP-Interpreter, keine Datenbank und kein Login, das im Netz erreichbar wäre. Für diese Seiten war die Woche ein Nicht-Ereignis: nichts zu patchen, kein Hoster, auf dessen Tempo man warten müsste, kein Plugin-Zoo, der Pflege braucht. Nebenbei sind sie schneller, weil beim Aufruf nichts gerechnet wird.

Die Grenze, offen gesagt: Ein Shop, ein Buchungssystem oder ein Mitgliederbereich braucht dynamische Teile. Die löse ich über externe Dienste, etwa ein Buchungs-Widget, dessen Server der Anbieter selbst pflegt, statt über PHP am eigenen Webspace. Und statisch heißt nicht unangreifbar: Domain-Zugang, Mail-Konto und das Konto beim Hosting-Anbieter müssen weiterhin geschützt werden, mit starken Passwörtern und zweitem Faktor. Weg ist nur die größte Angriffsfläche, der laufende Code am Server.

Drei Wege, wenn Sie Unterstützung wollen

Je nachdem, wo Sie gerade stehen:

• Kostenloser Check. Der PHP-Check auf PageCheck zeigt Ihnen, was von außen sichtbar ist, und gibt Ihnen den passenden Fragetext für den Hoster mit.
• Persönliche Prüfung. Ich schaue mir Ihre Website an, prüfe die Dateien gegen die Originale, wie oben beschrieben, und spreche mit Ihrem Hoster, bis die Bestätigung schriftlich da ist.
• Neue Website ohne PHP. Wenn Ihre Seite ohnehin in die Jahre gekommen ist: eine statische Seite, die diese Sorte Woche gar nicht mehr kennt. Vorab gibt es eine kostenlose Vorschau.

Schreiben Sie mir an [email protected], am besten mit Ihrer Website-Adresse und der Mail Ihres Hosters. Dann sage ich Ihnen, was ich sehe, und ob überhaupt etwas zu tun ist. Wenn Sie lieber kurz telefonieren oder gemeinsam am Bildschirm schauen möchten, geht das genauso.