Stand: 30. Oktober 2026. Dieser Beitrag behandelt die kritischen PHP-Lücken vom 21. Oktober sowie die ergänzenden Hinweise vom 23. und 26. Oktober. Sicherheitsmeldungen entwickeln sich weiter; prüfe vor einer Änderung auch die verlinkten Originalquellen.
Eine aktuelle WordPress-Version ist wichtig. Doch deine Website braucht auch eine gepflegte technische Grundlage: PHP. In dieser Laufzeitumgebung wurden im Oktober zwei kritische Sicherheitslücken geschlossen. Unter bestimmten Bedingungen können Angreifer darüber ohne Anmeldung eigenen Code auf einem verwundbaren Server ausführen. Ein normales Plugin-Update allein behebt diese PHP-Fehler nicht. [1] [4]
Was ist passiert – und warum ist das so ernst?
Die Meldungen heißen CVE-2026-109618 und CVE-2026-109619. Beide erhalten einen CVSS-v4-Wert von 9,2 und damit die Einstufung „kritisch“. Diese Zahl beschreibt die technische Schwere; sie ist keine Aussage darüber, mit welcher Wahrscheinlichkeit gerade deine Website angegriffen wird. [1] [2]
PHP verarbeitet auf dem Server unter anderem Seitenaufrufe, Formulare und Datenbankzugriffe. Gelingt eine sogenannte Remote Code Execution, können Angreifer im Rahmen der Rechte des betroffenen Prozesses handeln. Mögliche Folgen sind manipulierte Seiten, ausgelesene Zugangsdaten oder Datenbestände und eingeschleuste Hintertüren. Welche Schäden tatsächlich möglich sind, hängt unter anderem von Berechtigungen und der Trennung der Systeme ab. Daraus folgt nicht automatisch ein Zugriff auf den gesamten Hosting-Server. [4] [6]
Die Ursachen einfach erklärt
Die erste Lücke betrifft den Umgang mit Speichermangel. PHP kann eine Anfrage abbrechen, während interne Daten noch nicht vollständig vorbereitet sind. Beim anschließenden Aufräumen greift die Software unter Umständen auf ungültige Speicherinhalte zu. Geschickt präparierte Anfragen können daraus mehr als einen Absturz machen. [1]
Die zweite Lücke betrifft liegen gebliebene Verweise. Ein PHP-Arbeitsprozess bearbeitet häufig mehrere Anfragen nacheinander. Bestimmte interne Verweise können bestehen bleiben, obwohl der dazugehörige Speicher bereits freigegeben wurde. Eine spätere Anfrage kann diesen veralteten Zustand erreichen. Fachleute sprechen von „Use after free“. Beide Probleme liegen in PHP selbst; sie beweisen weder einen Fehler deines Webdesigners noch ein unsicheres Passwort. [2]
Wie groß ist das Ausmaß?
Grundsätzlich stehen PHP-Installationen im Fokus, die Webanfragen verarbeiten: darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das PHP-Team stuft mod_php als besonders riskant ein; dort wurde ein Angriff vor dem Start des eigentlichen Anwendungscodes demonstriert. Andere Betriebsarten sind deshalb nicht pauschal sicher. Auch Anwendungen mit eingebautem PHP müssen geprüft werden. [4]
NHS England meldete am 29. Oktober, dass beide CVEs im CISA-Katalog bekanntermaßen ausgenutzter Schwachstellen stehen. Gleichzeitig berichtete die Behörde, selbst keine Hinweise auf eine massenhafte Ausnutzung beobachtet zu haben. Das ist ein Anlass zum zügigen Handeln, aber keine belastbare Zahl weltweit gehackter Websites. Auch eine verwundbare Installation ist nicht automatisch bereits kompromittiert. [6]
Welche PHP-Versionen schließen die beiden kritischen Lücken?
Für die beiden Meldungen vom 21. Oktober nennt das PHP-Projekt folgende korrigierte Versionen. Innerhalb deines unterstützten Zweigs sollte mindestens diese Korrektur oder ein nachweislich gleichwertiger Hersteller-Patch installiert sein. [1] [2]
| PHP-Zweig | Korrigiert ab |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
Die sichtbare Versionsnummer reicht nicht immer als Nachweis. Hostinganbieter und Linux-Distributionen können Sicherheitskorrekturen in ältere Paketstände zurückübertragen. Bei diesem „Backporting“ bleibt die angezeigte PHP-Nummer unter Umständen gleich. Lass dir deshalb Paketstand und Schutz gegen die konkreten CVEs bestätigen. Die Dokumentation eines anderen Hosters ist kein Nachweis für deinen eigenen Server. [7]
PHP 8.1 und ältere Zweige erhalten vom PHP-Projekt keine regulären Sicherheitsupdates mehr. Ein Sonder-Patch ersetzt keine dauerhaft unterstützte Umgebung. Auch PHP 8.2 braucht bereits einen Umstiegsplan: Der offizielle Sicherheitssupport endet am 31. Dezember 2026. [4] [5]
Was du jetzt konkret tun solltest
- Zuständigkeit klären. Liste Website, Shop, Kundenportal und weitere PHP-Anwendungen auf. Bei verwaltetem Hosting übernimmt häufig der Anbieter die Server-Updates; bei einem eigenen Server dein Administrator. Öffentlich erreichbare Systeme haben Vorrang.
- Patchstatus bestätigen lassen. Frage gezielt nach CVE-2026-109618 und CVE-2026-109619. „PHP 8 läuft“ ist dafür keine ausreichende Antwort. Prüfen lassen solltest du die tatsächlich von der Website verwendete Laufzeit, nicht nur eine Kommandozeilen-Version.
- Update kontrolliert einspielen. Sichere Dateien und Datenbank und halte einen Wiederherstellungsweg bereit. Ein Wechsel des PHP-Hauptzweigs verlangt einen Kompatibilitätstest. Die Sicherheitskorrektur sollte dabei ohne vermeidbare Verzögerung erfolgen.
- Wirksamkeit prüfen. Verantwortliche müssen sicherstellen, dass die laufenden PHP-Prozesse die gepatchte Version nutzen. Teste anschließend Seiten, Anmeldung, Kontaktformular und gegebenenfalls Shop und Zahlungen.
- Bei Verdacht genauer hinsehen. Sichere Protokolle und lass neue oder veränderte Dateien, unbekannte Konten und Auffälligkeiten untersuchen. Ein Patch schließt die Eintrittsstelle; er entfernt keine bereits installierte Hintertür.
Diese Reihenfolge ist eine praktische Umsetzung der Empfehlungen von NCSC und CERT-EU [8]. Wenn sich eine gefährdete Anwendung nicht rechtzeitig aktualisieren lässt, sollten die Verantwortlichen den öffentlichen Zugriff bis zur Behebung begrenzen oder das System vorübergehend vom Netz nehmen. [3] [4]
Zwei zusätzliche Meldungen, die dein Administrator kennen sollte
23. Oktober: CVE-2026-115560. Dieser separate Angriffsweg setzt eine ungewöhnliche Kombination aus Session-Konfiguration und Anwendungscode voraus. PHP empfiehlt vorübergehend session.upload_progress.enabled=0. Der Administrator sollte die Einstellung an der richtigen Stelle setzen und die betroffenen Worker neu starten. Sie ersetzt die Updates gegen die beiden kritischen Lücken nicht. [3] [4]
26. Oktober: aktualisierte Windows-Pakete. PHP veröffentlichte die Builds 8.2.35-1, 8.3.36-1, 8.4.27-1 und 8.5.12-1 mit Brotli 1.2.1 gegen CVE-2026-111497. Betroffen ist ein zusätzlicher Dekomprimierungsweg über cURL. Wer offizielle Windows-Pakete nutzt, sollte auch diesen Paket-Neubau prüfen lassen. Das ist eine andere Meldung als die beiden PHP-Speicherfehler. [3]
Wie du deine Website dauerhaft besser schützt
Organisiere Updates als festen Betriebsablauf: Wer verfolgt Meldungen? Wer spielt Korrekturen ein? Wer prüft danach die Website? Ergänze getrennte, getestete Backups, sparsame Benutzerrechte und eine Überwachung wichtiger Dateien und Anmeldungen. Nutze für Administratorkonten starke, individuelle Zugangsdaten und Mehrfaktor-Anmeldung, wo verfügbar. Diese Maßnahmen begrenzen Risiken; sie machen eine ungepatchte PHP-Laufzeit nicht sicher.
Ein Security-Plugin, eine Web-Firewall oder ein versteckter WordPress-Login kann zusätzliche Angriffsmöglichkeiten begrenzen. Bei den hier beschriebenen PHP-Fehlern ersetzt das keine Korrektur der Laufzeit. Auch scheinbar hilfreiche Änderungen am Speicherlimit solltest du nicht ungeprüft übernehmen: Die offiziellen Zwischenmaßnahmen decken nur bestimmte Angriffswege ab. [4]
Diese Anfrage kannst du deinem Hoster schicken
Bitte bestätigt mir für meine Domain, ob die tatsächlich eingesetzte PHP-Laufzeit gegen CVE-2026-109618 und CVE-2026-109619 gepatcht ist. Welcher Paketstand beziehungsweise Backport ist aktiv, und wurden die betroffenen Prozesse neu gestartet? Bitte prüft außerdem den ergänzenden Hinweis zu CVE-2026-115560 und, falls Windows-Pakete eingesetzt werden, den Brotli-Paket-Neubau vom 26. Oktober.
Du möchtest die Rückmeldung einordnen oder die Pflege deiner Website sauber organisieren? Sprich mit der KOKOSKA Kreativ-Manufaktur. Wir klären mit dir die nächsten Schritte und die Zuständigkeiten beim Hosting.
Quellen und weiterführende Informationen
- PHP Security Team: CVE-2026-109618: RCE via OOM corruption (21.10.2026).
- PHP Security Team: CVE-2026-109619: RCE via stale global state (21.10.2026).
- PHP Group: Offizielle Meldungen vom 21., 23. und 26. Oktober 2026 (Oktober 2026).
- CERT-EU: Security Advisory 2026-018: Critical Vulnerabilities in PHP (aktualisiert 23.10.2026).
- PHP Group: Supported Versions: Laufzeiten und Supportende (abgerufen 30.10.2026).
- NHS England: Critical Vulnerabilities in PHP (PHP2Shell), CC-4875 (aktualisiert 29.10.2026).
- dogado: PHP-Sicherheitsupdates und Erklärung zum Backporting (Stand 22.10.2026).
- NCSC: Critical security issue affecting PHP (21.10.2026).
Alle Quellen zuletzt am 30.10.2026 geprüft. Eigenständige redaktionelle Einordnung; keine Übernahme fremder Artikel. Das Titelbild ist ein KI-generiertes Symbolbild und zeigt keinen realen Sicherheitsvorfall.
Ludwig Kokoska
Inhaber der KOKOSKA Kreativ-Manufaktur in Rüthen. Verbindet Marketing, B2B-Vertrieb, digitale Entwicklung und Events. Mehr über Ludwig und KOKOSKA ↗
