Beschreibung: Einfach erklärt: PHP und Browsercode, Anmeldung und Serverangriff, Risikotabelle, Versionsprüfung und sichere Updates.
Fällt das Internet zu einer festen Uhrzeit aus?
Der 21. Oktober 2026 um 14:00 UTC (16:00 Uhr in Deutschland) war kein Termin für den Weltuntergang des Internets, sondern der angekündigte Liefertermin für PHP-Sicherheitsupdates. Die Updates sind inzwischen erschienen. Jetzt müssen Betreiber sie installieren und am tatsächlich laufenden Server prüfen.
Ein WordPress-Update oder ein stärkeres Administratorpasswort beseitigt keine Schwachstelle im PHP-Interpreter. Besucher sollten vor allem gefälschte Nachrichten zur „dringenden Sicherheitsbestätigung“ meiden.
Was macht PHP? Ein Blick hinter die Ladentheke
PHP ist eine Programmiersprache, die auf einem Webserver läuft. Klickt jemand auf Kaufen, kann das Programm die Anmeldung prüfen, Lagerbestand und Preis abfragen, die Bestellung speichern und eine Antwort zurückgeben. WordPress, Onlineshops und Firmenportale nutzen PHP. Die Bezahlung übernimmt unter Umständen ein anderer Dienst. PHP arbeitet hinter den Kulissen.
Kann man PHP mit F12 sehen?
Die Browser-Werkzeuge zeigen HTML (Aufbau), CSS (Aussehen) und JavaScript (Interaktion). PHP wird auf dem Server ausgeführt; im Browser landet normalerweise nur das Ergebnis. Das Essen ist sichtbar, das Küchenrezept nicht.
In Chrome: F12 → Network → Seite neu laden → Dokument-Anfrage auswählen → Headers. X-Powered-By: PHP/... oder eine Adresse mit .php können Hinweise geben, lassen sich aber verbergen. Mit F12 lässt sich eine Sicherheitslücke weder bestätigen noch ausschließen.
| Technik | Aufgabe |
|---|---|
| HTML / CSS | Aufbau / Gestaltung |
| JavaScript | Interaktionen im Browser und auch Serverprogramme |
| PHP | Serverseitige Logik, Anmeldung und Datenzugriff |
| Python / Java / Go | Weitere Sprachen für Backend-Anwendungen |
| SQL | Datenbanken abfragen und verändern |
| P2P | Direkte Verbindung zwischen Geräten, keine Sprache |
Ein PHP-Programm kann SQL einsetzen. SQL ist deshalb kein Ersatz für PHP.
Was hat PHP tatsächlich bestätigt?
Offizieller Stand vom 22. Oktober 2026: PHP hat vier korrigierte Versionen für zwei Sicherheitslücken veröffentlicht; beide sind mit 9,2/10 nach CVSS v4.0 bewertet. Das ist ein Schweregrad, keine Einbruchswahrscheinlichkeit von 92 %.
| PHP-Zweig | Korrigierte Version |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
CVE-2026-109618 betrifft einen Fehler bei der Verarbeitung von Speichermangel. CVE-2026-109619 betrifft internen Zustand, der zwischen Anfragen fälschlich erhalten bleibt. Unter bestimmten Bedingungen ermöglichen beide Codeausführung aus der Ferne ohne Anmeldung. Für Apache mod_php wurde ein Angriff nachgewiesen, bevor der Anwendungscode überhaupt startet. Auch PHP-FPM und andere PHP-Laufzeitumgebungen müssen untersucht und aktualisiert werden.
PHP 8.1 und ältere Versionen erhalten vom PHP-Projekt keine regulären Sicherheitsupdates mehr. Manche Betriebssystem- oder Langzeit-Support-Anbieter übernehmen Korrekturen in ältere Pakete; außerdem hat das Projekt ausnahmsweise Quellcode-Patches für 7.4, 8.0 und 8.1 bereitgestellt. Deshalb zählen die Sicherheitshinweise des Anbieters und nicht nur die angezeigte Versionsnummer. PHP 8.2 erreicht sein Supportende am 31. Dezember 2026.
Bemerkenswert: erste Hinweise auf die erste Schwachstelle gab es bereits 2024. Die PHP Foundation räumt Verzögerungen wegen schwieriger technischer Entscheidungen und knapper Ressourcen ein. Ein demonstrierter Angriff bedeutet nicht, dass jede Website bereits kompromittiert wurde. Zum Zeitpunkt der Offenlegung hatte die Foundation unter kursierenden Demonstrationen keinen funktionsfähigen Exploit identifiziert. Das ist keine Entwarnung für die Zeit danach.
Anmeldung umgehen oder Befehle auf dem Server ausführen?
Eine Anmeldung zu umgehen bedeutet, die Passwort- oder Berechtigungsprüfung auszutricksen. Codeausführung aus der Ferne (RCE) bedeutet, den Server zu unerlaubten Befehlen zu bewegen. Das PHP-Projekt hat jetzt bestätigt, dass beide Lücken unter bestimmten Voraussetzungen RCE ohne Anmeldung ermöglichen.
Bei Apache mod_php wurde die erste Lücke vor dem Start des Anwendungscodes praktisch ausgenutzt. Auch PHP-FPM kann über anwendungsabhängige Wege betroffen sein. Wie weit ein Angreifer käme, hängt von PHP-Rechten, Datenbanken und Netzzugriffen ab. Daraus folgt nicht, dass jede Website Daten verloren hat.
Welche Systeme haben Vorrang?
| Lage | Priorität | Warum und was tun? |
|---|---|---|
| Öffentlich, ungepatcht, viele personenbezogene Daten | Sofort | Von außen erreichbar, hoher Schaden: patchen, Zugang beschränken, Protokolle sichern |
| Öffentlich, ungepatcht, interne Datenbank angebunden | Sofort | Öffentlicher Einstieg zum internen Netz möglich: DB-Rechte begrenzen und patchen |
| Öffentlich, ungepatcht, wenige sensible Daten | Hoch | Manipulation oder Angriffssprungbrett möglich: zügig aktualisieren |
| Nur Firmennetz, ungepatcht, wichtige Daten | Hoch | Befallene Rechner oder VPN können Zugang schaffen: patchen und Zugriffe prüfen |
| Intern, ungepatcht, wenige Daten | Mittel bis hoch | Ausbreitung auf weitere Systeme: isolieren und aktualisieren |
| Gepatcht, wichtige Daten | Weiter untersuchen | Ein Einbruch kann vor dem Update erfolgt sein |
| Kein PHP im betroffenen Dienst | Nicht unmittelbar betroffen | Andere Verwaltungsdienste prüfen |
Öffentliche Erreichbarkeit, hohe PHP-Rechte, wertvolle Daten, interne Verbindungen und fehlende Updates erhöhen das Risiko gemeinsam. Ein Firmennetz ist kein magischer Schutzschild.
Wie prüft man die eigene Website?
Gehen Sie der Reihe nach vor: Wo läuft PHP? → Welche Version bedient die Website tatsächlich? → Welche Versionen sind laut offizieller Meldung betroffen? → Ist der Patch aktiv?
In WordPress: Werkzeuge → Website-Zustand → Bericht/Info → Server (Bezeichnungen können abweichen). Ein Update von WordPress oder Plugins aktualisiert PHP nicht zwangsläufig. Bei Hosting fragen Sie den Anbieter. Auf eigenen Servern zeigt php -v die Kommandozeilen-Version, die von der Web-Version abweichen kann. Prüfen Sie auch PHP-FPM, Container und Systempakete. Keine fremden Systeme ohne Erlaubnis aktiv testen.
Reicht ein WordPress-Update?
PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 sind veröffentlicht. Die PHP-Laufzeit muss unabhängig von WordPress aktualisiert werden.
Ein Update von WordPress oder dessen Plugins aktualisiert nicht zwangsläufig PHP auf dem Server. Die PHP-Version steht in WordPress unter Werkzeuge → Website-Zustand → Bericht → Server; die Namen können je nach Sprachversion abweichen. Bei Hosting-Anbietern zählen deren offizielle Hinweise. Wer selbst verwaltet, sollte PHP-Installationen erfassen, Backups und Wiederherstellung vorbereiten und die Zuständigkeit klären.
Da die Korrekturen jetzt vorliegen, sind die betroffenen Versionen abzugleichen, Herstellerupdates einzuspielen und Anmeldung, Veröffentlichungen und Formulare zu testen. Änderungen am Produktivserver auf gut Glück sind eine besonders teure Lotterie.
Was tun vor und nach dem Sicherheitsupdate?
PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 sind veröffentlicht. Die PHP-Laufzeit muss unabhängig von WordPress aktualisiert werden.
Erfassen Sie die PHP-Systeme, Zuständigkeiten und zuverlässig wiederherstellbare Sicherungen. Da der Fix bereitsteht, aktualisieren Sie die tatsächlich laufende PHP-Umgebung gemäß den Hinweisen des Projekts oder Anbieters. Starten Sie nötige Dienste neu, kontrollieren Sie die Version und testen Sie Anmeldung, Beiträge, Formulare, Bestellungen und Schnittstellen.
Bei Verzögerungen begrenzen Sie den öffentlichen Zugang, Datenbankrechte und Verbindungen. Eine Web-Firewall kann ergänzen, aber den Patch nicht ersetzen. Das Ändern nur einer Upload-Einstellung beweist keinen Schutz vor beiden Schwachstellen. Bei großem Schadenpotenzial sollten Sie eine vorübergehende Abschaltung oder Trennung erwägen.
Bei Einbruchsverdacht sichern Sie Protokolle und Beweise, prüfen ungewöhnliche Konten, Dateien und Verbindungen und holen Fachleute hinzu. Ein repariertes Schloss holt bereits gestohlene Kundendaten nicht zurück. KI kann das Suchen nach Zielen beschleunigen, doch eine Warnung ist kein Nachweis für massenhafte Einbrüche.
Was gilt für Websites ohne PHP?
Eine rein statische Website oder ein JavaScript/TypeScript-Dienst ohne jede PHP-Laufzeitumgebung ist nicht unmittelbar von einem PHP-Fehler betroffen. Zusätzliche Verwaltungssysteme, Anbieter oder Geräte könnten trotzdem PHP enthalten. Cloudflare vor der Website ist kein Nachweis für einen gepatchten Ursprungsserver.
Die drei Fragen lauten: Wo läuft PHP? Wer aktualisiert es? Wie wird die Funktion danach überprüft?
Was sollten normale Besucher tun?
Besucher können fremde Server nicht reparieren. Bei unerwarteten Aufforderungen zur „dringenden Sicherheitsüberprüfung“ die offizielle Website oder App selbst aufrufen und verdächtige Links meiden.
Häufige Fragen
Soll man PHP durch Python ersetzen? Ein kompletter Umbau ist meist nicht die schnelle Lösung. Zuerst den passenden PHP-Patch anwenden.
Müssen alle Passwörter sofort geändert werden? Nicht allein wegen dieser Meldung. Bei einer bestätigten Datenpanne den offiziellen Dienst aufsuchen.
Ist Cloudflare schon die Lösung? Nein. Ein vorgeschalteter Schutz bestätigt kein PHP-Update auf dem Ursprungsserver.
Bedeuten 9,2 Punkte eine Angriffsquote von 92 %? Nein, das ist eine Bewertung des Schweregrades.
Explodiert das Internet um 16 Uhr?
Der Termin war kein Internet-Explosionstimer, sondern der Liefertermin für Ersatzteile. Die Teile sind da. Betreiber müssen nun die tatsächlich laufende PHP-Version prüfen, aktualisieren, Funktionen testen und gegebenenfalls frühere Einbrüche untersuchen. Nur WordPress zu aktualisieren ist wie ein neues Ladenschild anzubringen und das kaputte Schloss zu behalten. Aktualisiert am 21. Oktober 2026, 16:26 UTC.
Quellen (12)
PHP Security Team, 2026-10-20: https://www.php.net/archive/2026.php#2026-10-20-1
IPA, 2026-10-21: https://www.ipa.go.jp/security/security-alert/2026/pre-alert20261021.html
WordPress documentation: https://wordpress.org/documentation/article/site-health-screen/
Cloudflare Workers languages: https://developers.cloudflare.com/workers/languages/
PHP manual, basic web execution: https://www.php.net/manual/en/tutorial.firstpage.php
Chrome DevTools, Network requests and response headers: https://developer.chrome.com/docs/devtools/network/reference
CERT-EU Security Advisory 2026-018, 2026-10-20/21: https://cert.europa.eu/publications/security-advisories/2026-018/
PHP official support periods: https://www.php.net/supported-versions.php
PHP Security Advisory, 2026-10-21: https://www.php.net/archive/2026.php
PHP Foundation, background and disclosure, 2026-10-21: https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
CVE-2026-109618 (PHP advisory): https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
CVE-2026-109619 (PHP advisory): https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
