Kritische PHP-Lücken: Warum ein CMS-Update allein nicht reicht
Zwei Schwachstellen können Angreifern die Ausführung von Code auf Webservern ermöglichen. Korrekturen sind verfügbar. Für Schweizer Website-Betreiber zählt jetzt die tatsächlich eingesetzte Laufzeit.
Das PHP-Projekt hat am 21. Oktober 2026 Sicherheitsupdates gegen zwei kritische Schwachstellen veröffentlicht. Die Fehler können unter bestimmten Bedingungen erlauben, dass Angreifer ohne Anmeldung Code auf einem Webserver ausführen. Für Betreiber von Onlineshops, Vereinsseiten oder digitalen Dienstleistungen in der Schweiz ist deshalb die eingesetzte Server-Software entscheidend, nicht allein die sichtbare Website.
Die Korrekturen sind in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 enthalten. Die beiden Lücken werden als CVE-2026-109618 und CVE-2026-109619 geführt. Die gemeinsame Warnung europäischer Cybersicherheitsstellen, darunter ENISA und CERT-EU, fordert Organisationen zu sofortigem Handeln auf. Vorrang haben öffentlich erreichbare Systeme.
Die Schwachstelle liegt unter dem CMS
PHP ist eine Programmiersprache mit einer Laufzeitumgebung auf dem Server. Darauf bauen zahlreiche Webanwendungen auf. Ein Betreiber kann deshalb PHP einsetzen, ohne die Sprache selbst zu programmieren. Die Verantwortung für die technische Aktualisierung liegt je nach Vertrag beim Hostinganbieter, bei einer betreuenden Agentur oder beim eigenen IT-Team.
WordPress stellt in seiner eigenen Sicherheitsmeldung klar, dass es sich nicht um WordPress-spezifische Fehler handelt. Ein WordPress-Update ist für diese Lücken weder vorgesehen noch erforderlich. Stattdessen muss die PHP-Installation korrigiert werden. Im WordPress-Bereich für den Website-Zustand lassen sich Angaben zur Server-Version nachsehen; auch viele Hosting-Verwaltungen zeigen sie an.
Für einen kleinen Betrieb ist deshalb eine präzise Rückfrage hilfreicher als die pauschale Versicherung, die Website sei aktuell: Welche PHP-Version bedient die öffentliche Anwendung, und welche Korrektur hat der Anbieter eingespielt? Die Aktualität von Erweiterungen und CMS bleibt wichtig, beantwortet aber diese andere Frage nicht.
Versionsnummern brauchen den richtigen Kontext
Wer Originalversionen des PHP-Projekts verwendet, kann die genannten korrigierten Ausgaben vergleichen. Bei Linux-Distributionen und langfristig betreuten Anbieterpaketen können Sicherheitskorrekturen auch in bestehende Paketreihen zurückübertragen werden. Dann zählt zusätzlich die Sicherheitsmeldung des konkreten Lieferanten. Eine bloss ältere angezeigte Hauptversion genügt nicht für eine abschliessende Bewertung.
Umgekehrt bedeutet ein fehlender regulärer Updatepfad keine Entwarnung. PHP 8.1 und ältere Reihen erhalten vom PHP-Projekt keine normalen Sicherheitsausgaben mehr. Einige Anbieter stellen eigene Rückportierungen bereit. Betreiber müssen deren Gültigkeit für die eingesetzte Installation klären oder auf eine unterstützte, korrigierte Reihe wechseln.
Nicht jeder gefährdete Server ist bereits gehackt
Die Lücken betreffen die Speicherverwaltung und Fehlerbehandlung. Nach Darstellung des PHP-Projekts ist das Risiko bei Apache mit mod_php besonders hoch; auch andere verbreitete PHP-Betriebsarten müssen geprüft werden. Für die Öffentlichkeit ist dabei die Unterscheidung zentral: Ein nachgewiesener Angriffsweg zeigt ein reales Sicherheitsrisiko. Er beweist nicht, dass jede entsprechende Website bereits übernommen wurde.
ENISA empfiehlt, Anwendungen und Dienstleister zu erfassen und die Updates einzuspielen. Wo eine rasche Behebung nicht möglich ist, sollen Organisationen erwägen, die betroffenen Anwendungen vorübergehend vom öffentlichen Netz zu isolieren. Das PHP-Projekt betont seinerseits, dass vorläufige Konfigurationsmassnahmen nur einzelne Angriffswege reduzieren und keinen vollständigen Schutz ersetzen.
Eine nachvollziehbare Bestätigung sollte festhalten, welches System geprüft wurde und auf welchen Stand es gebracht worden ist. Bei ausgelagerten Diensten darf dabei keine Zuständigkeitslücke zwischen Agentur und Hoster bleiben. Die von den europäischen Stellen empfohlene Bestandsaufnahme dient genau dazu, auch PHP in Produkten zu finden, die auf den ersten Blick anders heissen.
KI findet Fehler, Menschen tragen die Behebung
OpenAI berichtet, dass die Sicherheitsfirma Calif mithilfe eines KI-Modells eine kritische Lücke untersuchte und Wiz beide Schwachstellen unabhängig meldete. Das ist die Darstellung eines beteiligten Unternehmens. Sie ist nicht mit der Behauptung gleichzusetzen, eine KI habe das Problem allein entdeckt und gelöst.
Die PHP Foundation beschreibt eine längere Vorgeschichte: Erste Anzeichen eines der Probleme gab es bereits 2024. Kompatibilität, mögliche Nebenwirkungen und knappe Fachressourcen erschwerten die Entscheidung für einen Fix. Die Stiftung räumt strukturelle Fehler ein und berichtet von veränderten Abläufen. Das begrenzt die einfache Erfolgserzählung über automatische Sicherheit.
Für Schweizer Betreiber folgt daraus eine überprüfbare Aufgabe: Zuständigkeit festlegen, betroffene Laufzeiten erfassen und die installierte Korrektur bestätigen lassen. Ein sicher klingender Produktname oder ein erfolgreiches CMS-Update genügt nicht. Entscheidend ist, ob genau die Software behoben wurde, die die öffentlichen Anfragen tatsächlich verarbeitet.
