PHP-Sicherheitslücke Oktober 2026: Was Website-Betreiber, Agenturen und Hoster jetzt tun müssen

Die PHP-Sicherheitslücke vom Oktober 2026 betrifft nicht ein einzelnes CMS, sondern den PHP-Laufzeitcode selbst – also die Software, die auf sehr vielen Webservern Anfragen an WordPress, Online-Shops und individuelle Anwendungen verarbeitet. Beide Schwachstellen sind mit CVSS v4.0 9.2 als kritisch eingestuft. Das heißt nicht, dass jede PHP-Website automatisch angreifbar ist. Es heißt aber: Jeder, der Websites betreibt, betreut oder hostet, sollte in den nächsten Stunden und Tagen klären, welche PHP-Laufzeit tatsächlich im Einsatz ist und ob sie die Korrektur enthält.

Dieser Beitrag ordnet die Lage sachlich ein, trennt bestätigte Fakten von offenen Punkten und gibt für drei Gruppen konkrete Schritte: Website-Betreiber ohne eigenen Server, Agenturen und Webdesigner sowie Hoster und Serveradministratoren. Exploit-Details enthält er bewusst nicht.

Was ist passiert – und warum wird gewarnt?

Das PHP-Projekt hat am 21. Oktober 2026 Sicherheits-Releases für zwei Schwachstellen angekündigt (PHP-Sicherheitsmeldungen, Release-Archiv 2026). Nach Fachberichten war die Veröffentlichung ursprünglich für den 22. Oktober geplant und wurde um einen Tag vorgezogen, nachdem die CVE-Kennungen vorab öffentlich geworden waren. Behörden und Sicherheitsstellen haben daraufhin gewarnt, darunter CERT-EU, CERT.at und das Canadian Centre for Cyber Security. In der Fachpresse kursiert für beide Lücken der Spitzname „PHP2Shell“.

• CVE-2026-109618 betrifft die Behandlung von Out-of-Memory-Zuständen: Wenn PHP an seine Speichergrenze stößt, kann Speicher beschädigt werden (Advisory-Kennung GHSA-w8hw-w9fx-j79w).
• CVE-2026-109619 ist ein sogenannter Use-after-free: Ein Zustand aus einer früheren Anfrage wird in einer späteren weiterverwendet, obwohl er nicht mehr gültig ist (GHSA-6wmf-4rv5-p3rp). Als bestätigte Auswirkung nennt PHP zusätzlich das Auslesen von Speicherinhalten (Memory Disclosure).

Beide Lücken sind mit CVSS v4.0 9.2 bewertet. Betroffen sein können alle Betriebsarten, in denen PHP Webanfragen verarbeitet: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed (Rapid7, Tenable).

Was macht diese PHP-Schwachstelle besonders kritisch?

Drei Eigenschaften kommen zusammen:

1. Keine Anmeldung nötig. Unter bestimmten Voraussetzungen genügen präparierte Anfragen von außen. Ein Angreifer braucht also kein Passwort und kein Benutzerkonto auf der Website.
2. Der Fehler sitzt unterhalb der Anwendung. Er liegt in PHP selbst, nicht in WordPress, einem Plugin oder einem Shop-System. Sauber gepflegter Anwendungscode schützt deshalb nicht automatisch. Nach der in den Fachanalysen wiedergegebenen Herstellerbewertung gilt mod_php als besonders riskant, weil eine Ausnutzung dort gelingen kann, bevor überhaupt Anwendungscode läuft.
3. Sehr große Verbreitung. PHP ist auf Webservern weit verbreitet. Zahlen zur tatsächlichen Exposition gehen in den Quellen weit auseinander – wir übernehmen sie deshalb bewusst nicht.

Wichtig für die Einordnung: Der Schweregrad wird nicht überall gleich bewertet. Red Hat stuft die Lücke als „Important“ ein und hält eine Codeausführung über PHP-FPM in der Praxis für schwierig; andere Quellen beschreiben einen konkreten Angriffspfad auch gegen PHP-FPM. Die Aussage „mit PHP-FPM bin ich sicher“ ist damit nicht haltbar.

Was bedeutet Remote Code Execution praktisch?

Remote Code Execution (RCE) heißt: Jemand bringt den Server dazu, Befehle auszuführen, die er selbst vorgibt. Nach den vorliegenden Analysen geschieht das mit den Rechten des Web-Workers, also des Prozesses, unter dem PHP Webanfragen abarbeitet. Was ein Angreifer damit erreichen kann, hängt stark davon ab, wie das System aufgebaut ist. Mögliche – nicht automatische – Folgen sind:

• unbefugter Zugriff auf Daten, die der Web-Prozess lesen darf, etwa Datenbankinhalte oder Formulareingaben,
• Manipulation von Inhalten, zum Beispiel eingeschleuste Seiten, Weiterleitungen oder Schadcode für Besucher,
• Missbrauch des Webservers, etwa für Spam-Versand oder als Ausgangspunkt weiterer Angriffe,
• Zugriff auf erreichbare Zugangsdaten, API-Schlüssel und Konfigurationsdateien,
• je nach Berechtigungen und Architektur die Ausweitung auf weitere Systeme im selben Netz.

Wie weit ein solcher Angriff reichen kann, entscheidet die Architektur: getrennte Benutzerkonten je Website, minimale Rechte, abgeschottete Datenbanken und Container begrenzen den Schaden. Das ist ein Argument für saubere Serveradministration – aber kein Ersatz für das Update.

Angriffslage: Was belegt ist und was nicht

Bei der Frage, ob die Lücken bereits ausgenutzt werden, widersprechen sich die Quellen zum Redaktionsstand. Wir trennen deshalb sauber:

Für die Praxis ist die genaue Angriffslage zweitrangig: Eine kritische, ohne Anmeldung ausnutzbare Lücke mit verfügbarem Patch gehört zügig geschlossen – unabhängig davon, ob die ersten erfolgreichen Angriffe schon gemeldet sind.

Welche PHP-Versionen sind betroffen, welche sind korrigiert?

Die korrigierten Upstream-Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Laut Tenable, Plesk, AWS und Google Cloud sind in den unterstützten Zweigen alle Versionen unterhalb dieser Stände betroffen. Für ältere Zweige ist die Lage weniger eindeutig – dazu gleich mehr.

Die offene Frage: Was gilt für PHP 7.4 bis 8.1?

Hier sind die Quellen ausdrücklich nicht einheitlich:

• Tenable und SOCRadar sprechen von minimalen Quellcode-Backports des PHP-Security-Teams für die End-of-Life-Zweige.
• Google Cloud schreibt dagegen, das PHP-Projekt portiere die Korrekturen nicht auf 8.1 oder älter zurück.
• AWS nennt für die EOL-Laufzeiten keinen Upstream-Fix und rät zur Migration.
• Plesk hat die mitgelieferten Versionen 7.4.33, 8.0.30 und 8.1.34 neu gebaut; korrigiert sind dort Pakete mit Build-Datum 21.10.2026.

Die praktische Konsequenz: Eine ältere Version ist weder pauschal „ungepatcht“ noch pauschal „sicher“. Entscheidend ist, ob für genau Ihre Installation eine nachweisliche Korrektur des Distributors, Panel-Herstellers oder Hosters eingespielt ist. Und selbst dann bleibt ein End-of-Life-Zweig eine Dauerbaustelle – die Migration auf einen unterstützten Zweig gehört auf den Plan.

Update-Strategie: Was „aktuell“ wirklich bedeutet

• PHP 8.2 allein ist keine Sicherheitsgarantie. Entscheidend ist die konkrete Patch-Version (zum Beispiel 8.2.35) oder eine nachweislich gleichwertige Korrektur des Distributors.
• Backports verändern die Versionsnummer oft nicht. Linux-Distributionen spielen Sicherheitskorrekturen häufig in ihre bestehende Paketversion ein. Fachberichte nennen als Beispiel Ubuntu 24.04, dessen korrigiertes Paket weiterhin die Versionsnummer 8.3.6 trägt. Maßgeblich ist dann das Paket-Changelog bzw. die Sicherheitsmeldung der Distribution.
• Das Update muss in der genutzten Laufzeit aktiv sein. Ein installiertes Paket wirkt erst, wenn PHP-FPM-Pools, Apache oder LiteSpeed neu gestartet bzw. neu geladen wurden.
• Die Kommandozeile kann eine andere PHP-Version zeigen als der Webserver. Auf vielen Servern laufen mehrere PHP-Versionen parallel; php -v zeigt nur die CLI-Version.
• Nach jedem Update kurz testen: Startseite, Formulare, Login, Warenkorb, geplante Aufgaben.
• Support-Enden im Blick behalten. Nach Sekundärquellen endet der Security-Support für PHP 8.2 am 31.12.2026; für 8.4 endet zum selben Datum wohl nur der aktive Support, Sicherheitsupdates laufen länger. Diese Daten haben wir nicht gegen die offizielle Übersicht unter php.net/supported-versions geprüft – bitte dort verifizieren.

Sind automatisch alle PHP-Websites betroffen?

Nein. Eine Website ist dann potenziell betroffen, wenn alle drei Punkte zutreffen: PHP verarbeitet Webanfragen (über eine der genannten Betriebsarten), die genutzte Laufzeit enthält die Korrektur nicht, und der Dienst ist erreichbar. Rein statische Websites ohne PHP sind nicht betroffen. Websites bei Hostern, die bereits gepatcht und die Dienste neu gestartet haben, sind es ebenfalls nicht mehr – das sollten Sie sich aber bestätigen lassen, statt es anzunehmen.

Ob auf dem Server WordPress, ein Shop oder eine Eigenentwicklung läuft, spielt für die Betroffenheit keine Rolle. Bei den Übergangsmaßnahmen, die das Advisory nennt, und bei den Folgen eines Angriffs schon – dazu unten mehr.

Wie lässt sich feststellen, ob ein System gepatcht ist?

Die richtige Methode hängt davon ab, ob Sie Zugriff auf den Server haben:

• Ohne Serverzugang: In der Hosting-Verwaltung nachsehen, welche PHP-Version für die Domain eingestellt ist, und beim Anbieter schriftlich bestätigen lassen, ob diese Version die Korrektur enthält und aktiv ist.
• Mit Serverzugang: Über die Paketverwaltung prüfen, ob das installierte PHP-Paket die CVE-Korrekturen enthält, die PHP-FPM-Konfiguration sichten (welche Pools nutzen welche PHP-Binärdatei?) und anschließend kontrollieren, dass die Dienste neu gestartet wurden.
• Bei Containern: Die PHP-Version im laufenden Container prüfen und vergleichen, aus welchem Image er gestartet wurde – nicht nur das Image in der Registry.

Für Administratoren eignen sich zum Beispiel diese unkritischen Prüfbefehle (Paketnamen je nach Distribution und Version anpassen):

# Debian/Ubuntu: Ist die Korrektur im Paket-Changelog enthalten?
apt changelog php8.3-fpm | grep -E "CVE-2026-10961(8|9)"

# RHEL-Familie: Changelog des installierten Pakets durchsuchen
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961(8|9)"

# Welche PHP-FPM-Dienste laufen überhaupt?
systemctl list-units --type=service | grep -i fpm

# PHP-Version im laufenden Container (Name anpassen)
docker exec <container> php -v

Eine öffentlich erreichbare phpinfo()-Seite ist kein geeigneter Prüfweg: Sie verrät Angreifern genau die Informationen, die sie suchen. Wer die Laufzeit des Webservers unbedingt über den Browser prüfen muss, sollte das nur kurz, geschützt und mit anschließender Löschung tun – besser ist der Weg über Paketverwaltung und Konfiguration.

Was Website-Betreiber ohne eigenen Server jetzt tun sollten

Die meisten Unternehmen betreiben ihre Website nicht selbst, sondern bei einem Hoster, oft betreut von einer Agentur. Sie müssen keine Serverbefehle kennen – aber sie sollten wissen, wen sie fragen müssen und welche Antwort ausreicht. Sieben Schritte:

1. Hoster herausfinden. Wo liegt die Website? Das steht in der Regel in der Rechnung, im Kundenkonto oder lässt sich bei der betreuenden Agentur erfragen.
2. Tatsächliche PHP-Version und Patch-Status feststellen lassen. Nicht „PHP 8“, sondern die konkrete Version oder den Paketstand, mit dem Ihre Website Anfragen verarbeitet.
3. Hoster oder Agentur kontaktieren – am besten schriftlich, damit die Antwort dokumentiert ist (Vorlage unten).
4. Bestätigung einholen, dass die Korrektur installiert und aktiv ist. „Wir haben die Updates eingespielt“ reicht nur, wenn auch die PHP-Dienste neu gestartet wurden.
5. Erfragen, ob Sie selbst etwas umstellen müssen. Bei vielen Tarifen wählen Kunden die PHP-Version pro Domain selbst. Ist dort eine alte Version eingestellt, liegt der Wechsel unter Umständen bei Ihnen.
6. Nach dem Update kurz prüfen: Lädt die Website, funktionieren Kontaktformular, Login und – bei Shops – Warenkorb und Bezahlung?
7. Bei alten PHP-Versionen einen Upgrade- oder Migrationsplan vereinbaren. Wer noch auf 7.4 oder 8.0 läuft, hat mit diesem Vorfall einen guten Anlass, den Wechsel verbindlich zu terminieren.

Vorlage: E-Mail an Ihren Hoster

Diese Nachricht können Sie kopieren, die Platzhalter ausfüllen und an den Support senden:

Betreff: PHP-Sicherheitsupdate CVE-2026-109618 / CVE-2026-109619 – Patch-Status für [Domain]

Guten Tag,

am 21.10.2026 wurden Sicherheitsupdates für die kritischen PHP-Schwachstellen CVE-2026-109618 und CVE-2026-109619 veröffentlicht. Bitte teilen Sie mir für meinen Vertrag [Kundennummer] und die Domain(s) [Domain] Folgendes mit:

1. Welche PHP-Version bzw. welcher Paketstand wird für Webanfragen dieser Domain(s) aktuell genutzt?
2. Enthält diese Version die Korrekturen für beide CVEs (z. B. PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder ein gleichwertig korrigiertes Paket)?
3. Sind die korrigierten Versionen bereits aktiv, d. h. wurden die PHP-Dienste nach dem Update neu gestartet?
4. Muss ich selbst etwas tun, etwa die PHP-Version in der Verwaltung umstellen? Falls ja, bitte mit konkreter Anleitung.
5. Falls meine Domain eine nicht mehr unterstützte PHP-Version nutzt: Gibt es dafür eine Korrektur, und welche Version empfehlen Sie für den Wechsel?

Sollte noch Handlungsbedarf bestehen, bitte ich um eine kurze Rückmeldung mit konkreten Anweisungen und einem Zeitrahmen.

Vielen Dank und freundliche Grüße
[Name, Firma, Telefon]

Was Agenturen und Webdesigner prüfen müssen

Agenturen betreuen oft Dutzende Websites auf ganz unterschiedlichen Plattformen. Hier hilft kein Bauchgefühl, sondern ein systematischer Prozess in zehn Schritten:

1. Inventar erstellen: alle Domains, Websites, Server und Hosting-Verträge, die Sie betreuen oder für die Sie Zugänge haben.
2. Tatsächlich genutzte PHP-Version je Website erfassen – nicht die im Angebot von vor drei Jahren, sondern die heute aktive.
3. Hosting-Art zuordnen: Managed Hosting, klassisches Webhosting, Managed Server, VPS, Root-Server oder Container. Davon hängt ab, wer patcht.
4. Mit betroffenen und korrigierten Versionen abgleichen (Tabelle oben), bei Distributionspaketen über das Changelog.
5. Prüfen, ob der Anbieter schon gepatcht hat – über Statusseiten, Kundeninformationen oder direkte Nachfrage.
6. Selbst verwaltete PHP-Installationen aktualisieren.
7. Dienste kontrolliert neu laden oder neu starten – PHP-FPM, Apache, LiteSpeed, Container.
8. Funktionstests durchführen und dokumentieren: Was wurde wann geprüft, mit welchem Ergebnis, was ist offen?
9. Priorisieren: Öffentlich erreichbare, ungepatchte Systeme zuerst, Shops und Systeme mit personenbezogenen Daten vor reinen Informationsseiten.
10. Altsysteme gesondert behandeln: Websites auf PHP-Zweigen ohne reguläre Updates brauchen eine Einzelentscheidung – Herstellerkorrektur nachweisen, absichern oder migrieren.

Zwei Warnungen aus der Praxis: Erstens ist es problematisch, im Eifer alle Websites ohne Kompatibilitätsprüfung auf eine neue PHP-Hauptversion umzustellen. Ältere Themes, Plugins und Eigenentwicklungen brechen dabei schnell. Für die akute Lücke reicht innerhalb eines unterstützten Zweigs das Patch-Update; der Zweigwechsel gehört geplant und getestet. Zweitens genügt php -v nicht als Nachweis. Bei mehreren PHP-FPM-Pools, Apache-Modulen, Containern oder einer PHP-Version pro Domain muss die Laufzeit geprüft werden, die tatsächlich Webanfragen beantwortet – über Hosting-Verwaltung, Paketverwaltung, PHP-FPM-Konfiguration oder Container-Images.

Hoster und Serveradministratoren: Wer ist wofür zuständig?

Bei Servern werden zwei Dinge gern verwechselt: der Rechenzentrumsbetrieb (Strom, Netz, Hardware, Virtualisierung) und die Software-Administration (Betriebssystem, PHP, Webserver, Anwendungen). Wer nur das Erste eingekauft hat, bekommt das Zweite nicht automatisch dazu. Die Verantwortung für das PHP-Sicherheitsupdate hängt deshalb an der Hosting-Art und am Vertrag.

A. Klassisches Webhosting (Shared Hosting)

Hier stellt der Anbieter die PHP-Versionen bereit. Seine Aufgaben: bereitgestellte Versionen und ihren Patch-Stand prüfen, Korrekturen für unterstützte Zweige einspielen, Versionen aktualisieren, Dienste neu starten, Kunden informieren und nicht mehr versorgte Versionen offen kommunizieren. Bietet der Tarif eine PHP-Auswahl pro Domain, prüft der Kunde selbst, ob die gewählte Version noch sicher ist – und stellt gegebenenfalls um.

B. Managed Server

Beim Managed Server trägt der Provider die Verantwortung – im Rahmen des vereinbarten Leistungsumfangs. Typischerweise gehört dazu: betroffene Installationen identifizieren, Updates oder gleichwertige Herstellerkorrekturen einspielen, prüfen, dass die korrigierte Version aktiv ist, PHP-FPM und weitere Dienste kontrolliert neu starten, parallel installierte PHP-Versionen mitprüfen, Kunden über Maßnahmen außerhalb des Leistungsumfangs informieren sowie Ergebnis und Restrisiken dokumentieren. Wichtig: „Managed“ heißt nicht automatisch, dass auch CMS, Plugins, Themes und Anwendungen aktualisiert werden. Das ist oft eine eigene Leistung – im Zweifel im Vertrag nachsehen.

Ein Sonderfall sind Hosting-Panels: Laut Plesk ist auch die Panel-Oberfläche selbst (sw-engine) betroffen; korrigiert ist sie ab Plesk 18.0.80 Update 11 bzw. 18.0.81 Update 4. Wer Plesk betreibt, muss also PHP-Pakete und Panel aktualisieren.

C. Unmanaged VPS und Root-Server

Hier pflegt der Administrator – intern oder beauftragt – Betriebssystem und PHP-Pakete selbst. Dass der Anbieter Hardware und Rechenzentrum betreut, bedeutet nicht, dass PHP auf einem selbst administrierten Server aktualisiert wird. Checkliste:

• Paket- und Distributionsupdates einspielen, Sicherheitsmeldungen der Distribution lesen,
• Backports anhand des Changelogs prüfen (siehe Prüfbefehle oben),
• alle genutzten PHP-Versionen aktualisieren – auch Zweitinstallationen aus Fremdquellen,
• mehrere FPM-Pools und parallele Laufzeiten einzeln prüfen,
• Container und selbst gebaute Images einbeziehen,
• Dienste kontrolliert neu laden bzw. neu starten,
• Funktionsprüfung der Websites,
• soweit angemessen nach Kompromittierungsindikatoren sehen (siehe unten).

D. Docker und Container

Ein Update des Host-Systems korrigiert PHP im Container nicht. Basis-Images bzw. die PHP-Pakete im Image müssen aktualisiert, die Container neu gebaut und neu ausgerollt werden. Danach kontrollieren, dass tatsächlich die neuen Container laufen – alte Instanzen bleiben sonst unbemerkt aktiv. Feste Image-Versionen in Compose-Dateien oder Deployments sollten auf die korrigierten Stände angehoben werden.

WordPress, Shops, CMS und individuelle PHP-Anwendungen

Viele Suchanfragen zur PHP-Sicherheitslücke drehen sich um WordPress. Die klare Antwort: Ein aktuelles WordPress oder ein aktualisiertes Plugin sichert eine ungepatchte PHP-Laufzeit nicht ab. Umgekehrt gilt genauso: WordPress, Plugins und Themes haben eigene, von PHP unabhängige Risiken. Für WordPress, Shop-Systeme, andere CMS und Eigenentwicklungen empfehlen wir:

• den PHP-Patch-Status wie oben beschrieben prüfen bzw. bestätigen lassen,
• CMS, Plugins, Themes und Bibliotheken aktuell halten,
• vor größeren PHP-Versionswechseln die Kompatibilität testen, am besten auf einer Staging-Kopie,
• Backups auf Integrität und Wiederherstellbarkeit prüfen – ein Backup, das sich nicht zurückspielen lässt, ist keines,
• Zugänge und Berechtigungen durchsehen: alte Admin-Konten, geteilte Passwörter, nicht mehr benötigte FTP-Zugänge,
• bei begründetem Verdacht nach verdächtigen Veränderungen suchen (neue Dateien, unbekannte Benutzer, eingeschleuste Weiterleitungen).

Für individuelle PHP-Anwendungen gilt dasselbe – mit dem Zusatz, dass hier oft niemand automatisch zuständig ist. Wer eine Eigenentwicklung betreibt, sollte klären, wer Laufzeit und Abhängigkeiten pflegt. Warum schlanke, gut gepflegte Systeme dabei im Vorteil sind, habe ich im Beitrag Webdesign 2026: Warum Ihre Website heute völlig anders gebaut werden muss beschrieben.

Wenn ein Update (noch) nicht möglich ist

Ungepatchte, öffentlich erreichbare PHP-Installationen sollten nach Möglichkeit unverzüglich korrigiert werden. Geht das nicht sofort, kommen je nach System und Risikoprofil diese Übergangslösungen in Frage:

• die externe Erreichbarkeit der betroffenen Anwendung vorübergehend einschränken, zum Beispiel per IP-Freigabe oder Wartungsmodus auf Webserver-Ebene,
• wenn nötig und vertretbar Dienste isolieren oder vorübergehend abschalten,
• eine kurzfristige Lösung mit dem Hoster abstimmen,
• die Übergangseinstellungen aus dem PHP-Advisory prüfen.

Zu Letzterem: CERT.at nennt für CVE-2026-109618, memory_limit=-1 so zu setzen, dass Anwendungen den Wert nicht überschreiben können; für CVE-2026-109619 wird session.upload_progress.enabled=0 mit anschließendem Neustart aller Worker genannt. Laut Tenable verringern diese Maßnahmen nur bestimmte Angriffspfade – sie machen eine Installation nicht sicher. Ein unbegrenztes Speicherlimit kann zudem eigene Nebenwirkungen haben, etwa wenn einzelne Skripte den Server auslasten. Details bitte immer im Primär-Advisory prüfen und nur als Brücke bis zum Update nutzen.

Auch eine Web Application Firewall oder ein Reverse Proxy neutralisiert die Lücke nicht zuverlässig. Cloudflare selbst stuft die eigenen WAF-Regeln laut The Hacker News als Notlösung ein und rät trotzdem zum Patchen. Eine pauschale Abschaltung aller Websites ist dagegen in den meisten Fällen nicht angemessen – die Maßnahme muss zum System und seinem Risiko passen.

Verdacht auf Kompromittierung: Was zusätzlich zu tun ist

Ein Update schließt die Lücke, beweist aber nicht, dass vorher kein Angriff stattgefunden hat. Dabei hilft eine klare Unterscheidung: Schwachstellen-Exposition heißt, das System war angreifbar. Ein nachgewiesener Sicherheitsvorfall heißt, es gibt konkrete Hinweise, dass jemand die Lücke genutzt hat. Nur im zweiten Fall – oder bei begründetem Verdacht – sind folgende Schritte angezeigt:

1. Webserver-, System-, Anwendungs- und Anmeldeprotokolle sichern, bevor sie rotiert werden, und auswerten,
2. unerwartete Prozesse, neue oder veränderte Dateien, unbekannte Benutzerkonten und ungewöhnliche ausgehende Verbindungen untersuchen,
3. Zugangsdaten, API-Schlüssel und Zertifikate aus einer sauberen Umgebung heraus erneuern,
4. das System bereinigen oder – oft der sicherere Weg – nach einem belastbaren Wiederherstellungsplan neu aufsetzen,
5. bei Bedarf einen spezialisierten IT-Sicherheitsdienstleister hinzuziehen,
6. Meldepflichten und Datenschutzanforderungen prüfen: Bei einer Verletzung des Schutzes personenbezogener Daten sieht die DSGVO grundsätzlich eine Meldung an die Aufsichtsbehörde innerhalb von 72 Stunden vor.

Wer sich generell mit Melde- und Sicherheitspflichten beschäftigt, findet im Beitrag zum Cyber Resilience Act den regulatorischen Rahmen für Hersteller digitaler Produkte.

Fazit: Zuständigkeit klären, Patch-Stand belegen, dann weiterdenken

Die PHP-Sicherheitslücke vom Oktober 2026 ist ernst, aber beherrschbar: Die Korrekturen liegen vor. Die eigentliche Arbeit besteht darin, für jede Website drei Fragen belastbar zu beantworten – Welche PHP-Laufzeit beantwortet hier Webanfragen? Enthält sie die Korrektur und ist sie aktiv? Wer ist laut Vertrag dafür zuständig? Wer das heute klärt und schriftlich festhält, ist für diesen Vorfall gut aufgestellt und weiß beim nächsten deutlich schneller, was zu tun ist.

Unsere konkrete Empfehlung: Senden Sie heute die E-Mail-Vorlage an Ihren Hoster oder fordern Sie bei Ihrer Agentur eine kurze Übersicht der PHP-Stände an. Wenn Sie dabei Unterstützung möchten, hilft pxMEDIA bei der Bestandsaufnahme und PHP-Prüfung Ihrer Websites – sachlich, mit klarer Aufteilung, was beim Hoster liegt und was bei Ihnen.

Häufige Fragen zur PHP-Sicherheitslücke Oktober 2026

Quellen und weiterführende Links

Primärquellen und Behörden

• PHP-Projekt: Sicherheitsmeldungen
• PHP-Projekt: Release-Archiv 2026
• CERT-EU: Security Advisory 2026-018
• CERT.at: Kritische Sicherheitslücken in PHP – Updates verfügbar
• Canadian Centre for Cyber Security: AL26-026

Hersteller und Plattformen

• Google Cloud: Responding to core PHP vulnerabilities
• AWS Security Bulletin 2026-143
• Plesk: Betroffene und korrigierte PHP-Versionen
• Red Hat: CVE-2026-109618
• Palo Alto Networks: CVE-2026-109618

Sicherheitsforschung und Fachpresse

• Tenable: PHP2Shell FAQ
• Rapid7: Critical Unauthenticated RCE in PHP
• watchTowr: PHP RCE FAQ (Hinweis: Die Seite nannte zum Abrufzeitpunkt noch den 22.10. als Ankündigungsdatum)
• SOCRadar: PHP2Shell
• Sansec: PHP2Shell
• The Hacker News: PHP issues emergency patches

Hinweis: Dieser Beitrag gibt den Sachstand zum genannten Zeitpunkt allgemein verständlich wieder. Er ersetzt keine Sicherheitsprüfung im Einzelfall und keine Rechtsberatung zu Meldepflichten. Für verbindliche Aussagen zu Ihren Systemen ziehen Sie bitte Ihren Hoster, Ihre Agentur oder einen IT-Sicherheitsdienstleister hinzu.