PHP2Shell: Was passiert ist
und was ein PHP-Checker leisten kann
Deine Website sieht unverändert aus. Trotzdem kann ihre technische Grundlage dringend ein Update brauchen. Was die PHP-Sicherheitsmeldungen bedeuten und wie du aus einem Versionshinweis eine belastbare Prüfung machst.
Eine kritische Sicherheitsmeldung betrifft manchmal die Grundlage, auf der deine gesamte Website läuft. Genau das geschah im Oktober 2026 bei PHP. Die Sprache verarbeitet auf vielen Servern Anfragen, Formulare und dynamische Inhalte. Zwei Schwachstellen konnten unter bestimmten Bedingungen die Ausführung fremden Codes ermöglichen, ohne dass sich Angreifer anmelden mussten. Für Betreiber stellt sich deshalb eine praktische Frage: Wie lässt sich feststellen, ob der eigene Server die notwendigen Korrekturen tatsächlich verwendet?
Was im Oktober passiert ist
CERT-EU dokumentiert eine Vorankündigung des PHP-Projekts vom 20. Oktober und die Veröffentlichung der Sicherheitsupdates am 21. Oktober 2026. Die beiden Lücken tragen die Kennungen CVE-2026-109618 und CVE-2026-109619. Die Bezeichnung PHP2Shell wird für diesen Zusammenhang verwendet. Die Probleme liegen in PHP selbst; allein ein Update des sichtbaren Shopsystems beantwortet die Frage nach dem PHP-Patchstand deshalb nicht.
Das Schweizer Bundesamt für Cybersicherheit BACS empfiehlt, auch interne Anwendungen und Produkte mit eingebautem PHP zu erfassen. Eine gefährdete Installation muss nicht als offensichtliche PHP-Website erkennbar sein. Bei Hosting und Herstellerprodukten sollten Verantwortliche die Behebung bestätigen lassen.
Wie die beiden Fehler funktionieren
Beim ersten Fehler, CVE-2026-109618, geht es um die Behandlung von Speichermangel. PHP kann die Verarbeitung einer Anfrage abbrechen, während interne Daten noch unvollständig vorbereitet sind. Beim anschliessenden Aufräumen werden solche Daten möglicherweise trotzdem als gültig behandelt. Daraus kann eine Speicherbeschädigung entstehen, die sich für die Ausführung fremden Codes ausnutzen lässt. Das PHP-Team hat einen vollständigen Angriff für Apache mit mod_php bestätigt; die praktische Ausnutzbarkeit hängt unter anderem von der Betriebsumgebung ab.
Der zweite Fehler, CVE-2026-109619, betrifft veraltete interne Zustände. Ein PHP-Arbeitsprozess bearbeitet nacheinander verschiedene Anfragen. Dabei können Verweise auf Daten zurückbleiben, deren Speicher bereits freigegeben wurde. Greift eine spätere Anfrage auf diese Verweise zu, bevor sie zurückgesetzt werden, entsteht ein sogenannter Use-after-free-Fehler. Auch dieser kann zur Ausführung fremden Codes führen. Vereinfacht: Der Prozess arbeitet noch mit einem Verweis auf etwas, das in dieser Form nicht mehr existiert.
Welche Updates erforderlich sind
Die am 21. Oktober veröffentlichten PHP-Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12 enthalten die Korrekturen für die beiden ursprünglichen Lücken. Linux-Anbieter können die Fehlerbehebung auch in ihre bestehenden Pakete zurückübertragen. Eine ältere angezeigte Versionsnummer beweist deshalb nicht automatisch einen fehlenden Patch.
Das BACS empfiehlt, nach dem Update die betroffenen laufenden Prozesse neu zu starten und den tatsächlich verwendeten Stand zu kontrollieren. Auch eine Prüfung auf ungewöhnliche Vorgänge gehört dazu: Ein Update beseitigt keinen bereits erfolgten Einbruch. Eine Web Application Firewall allein ersetzt die Sicherheitsupdates ebenfalls nicht.
Zusätzlich prüfen: CVE-2026-115560. Der separate PHP-Hinweis vom 23. Oktober betrifft eine ungewöhnliche Kombination von Session-Einstellungen und einem Wechsel des Serialisierungsverfahrens zur Laufzeit. PHP empfiehlt, die Upload-Fortschrittsfunktion bis zum nächsten regulären Bugfix-Release zu deaktivieren. Die Einstellung muss administrativ wirksam sein; betroffene Arbeitsprozesse sind neu zu starten. Anwendungen, die das Serialisierungsverfahren nie zur Laufzeit wechseln, können die Funktion laut PHP aktiviert lassen. Die vier oben genannten Versionsstände sind kein Nachweis einer Behebung dieses zusätzlichen Falls.
Kritisch bedeutet nicht automatisch erfolgreich angegriffen
Das niederländische NCSC präzisierte seine Einschätzung am 23. Oktober: Die Ausnutzung sei komplex, die Gefahr grossflächigen Missbrauchs geringer als zunächst angenommen. Eine dort bekannte Meldung über möglichen Missbrauch im Ausland war noch kein bestätigter erfolgreicher Angriff. Die Empfehlung zum schnellen Aktualisieren blieb bestehen. Eine vorhandene Schwachstelle und eine nachgewiesene Kompromittierung sind unterschiedliche Befunde.
Was der Checker von OpenAI tatsächlich prüft
Der frei verfügbare php2shell-checker vergleicht im URL-Modus die öffentlich mitgeteilte PHP-Version mit den korrigierten Versionsständen. Dafür liest er die Antwort-Header Server und X-Powered-By. Antwort-Header sind technische Begleitinformationen, die ein Webserver beim Seitenabruf mitsendet. Er beginnt mit einer HEAD-Anfrage und wechselt nur bei den Antworten 405 oder 501 zu GET. Weiterleitungen verfolgt er nicht; den Seiteninhalt untersucht er nicht auf Angriffe.
Mit Serverzugriff lässt sich genauer prüfen, welches Paket die Website bedient und ob die Arbeitsprozesse aktualisiert wurden. Die PHP-Version der Kommandozeile kann dabei von der Website abweichen. Diese Zuordnung ist der entscheidende nächste Schritt nach einem öffentlichen Versionshinweis. Auch die vollständige Paketversion muss zur Sicherheitsmeldung des richtigen Betriebssystemanbieters passen.
Lokal mit Coding Agents arbeiten statt einen öffentlichen Prüfdienst bauen
Für eine erste Einordnung brauchst du kein zusätzliches Formular auf deiner Website. Der Checker lässt sich als kleines Node.js-Programm lokal ausführen. Node.js ist dabei die Laufzeitumgebung; die Kommandozeile ist das textbasierte Eingabefenster für einen Programmaufruf. Die Projektbeschreibung nennt als Beispiel:
node phpcheck.js "https://example.com"Das ist eine Anleitung, kein hier durchgeführter Test. Wenn du mit Codex, Claude Code oder einem anderen Coding Agent arbeitest, kannst du die nötigen Prüfschritte in einem lokalen Projekt vorbereiten. Für Codex beschreibt das Repository optional zwei Skills: phpcheck-url für den von aussen sichtbaren Versionshinweis und phpcheck-server für eine Prüfung mit berechtigtem Serverzugriff. Ein Skill bündelt Arbeitsanweisungen und gegebenenfalls Hilfsprogramme für eine wiederkehrende Aufgabe. Ob und wie sich diese Anleitungen in einem anderen Coding Agent verwenden lassen, musst du für das jeweilige Werkzeug prüfen. Die Installation ist ein eigener, bewusster Schritt und keine Voraussetzung dafür, diesen Beitrag zu verstehen.
Für den beschriebenen Prüfauftrag sind keine Schreibrechte auf deine Shopdatenbank nötig. Begrenze die Freigabe auf das Lesen der benötigten Versions-, Paket- und Prozessinformationen. Änderungen an PHP, Dienstneustarts, Installationen oder Konfigurationen sind davon getrennte Aufgaben und brauchen eine eigene Freigabe. Zugangsdaten und vertrauliche Konfigurationen gehören weder in öffentliche Prüfformulare noch in veröffentlichte Protokolle.
Drei Ergebnisse, aber kein Sicherheitszertifikat
- OK
- Die öffentlich angegebene stabile Version erreicht einen hinterlegten Korrekturstand. Der tatsächlich installierte Build ist damit nicht verifiziert.
- POTENTIALLY VULNERABLE
- Die angegebene Version liegt unter einem hinterlegten Stand. Das ist ein versionsbasierter Warnhinweis, kein Beweis für eine ungepatchte Installation. Anbieter können Korrekturen zurückübertragen haben.
- UNKNOWN
- Die Version ist verborgen, nicht erkennbar oder die Abfrage ist fehlgeschlagen. Unbekannt bedeutet weder sicher noch nachweislich verwundbar.
Der gegenwärtige URL-Check orientiert sich an den Korrekturständen vom 21. Oktober für CVE-2026-109618 und CVE-2026-109619. Daraus folgt keine Entwarnung für CVE-2026-115560. Prüfergebnis, geprüfte Lücken und Prüfdatum gehören deshalb zusammen.
Die PHP-Version lässt sich nicht erkennen. Wie kommst du trotzdem weiter?
Wenn der Checker keine PHP-Version findet, musst du die technischen Hintergründe nicht selbst durchschauen. Der nächste Ansprechpartner ist dein Hostinganbieter oder die Person, die deinen Server betreut. Entscheidend ist die Bestätigung, dass die tatsächlich laufende PHP-Installation die erforderlichen Sicherheitskorrekturen enthält.
Falls du nicht weisst, wen du fragen sollst oder wie du die Antwort beurteilen kannst, unterstütze ich dich bei der Abklärung. Wir prüfen die verfügbaren Hinweise, formulieren die richtigen Fragen und ordnen die Rückmeldung deines Anbieters verständlich ein. Du erfährst, was bestätigt ist, welche Informationen noch fehlen und ob weitere Schritte notwendig sind.
Das Ergebnis lautet: Behebung bestätigt, Handlungsbedarf festgestellt oder noch nicht ausreichend nachgewiesen. Zu jeder Einordnung gehören eine Begründung und der nächste Schritt. Reichen die Informationen deines Hosters nicht aus, bleibt der Status offen. Ein Server-Banner oder Versionsvergleich allein ist keine abschliessende Sicherheitsbestätigung. Updates und technische Eingriffe werden gesondert vereinbart.
PHP-Sicherheitsstatus klären lassen
Schick mir die Adresse deiner Website und, falls bekannt, den Namen deines Hostinganbieters. Für die erste Anfrage brauchst du keine Passwörter oder Zugangsdaten.
Was du jetzt konkret klären solltest
- Bestand und Verantwortung: Welche öffentlichen und internen Anwendungen verwenden PHP? Wer kann den laufenden Stand verbindlich bestätigen?
- Update und Laufzeit: Welches Anbieterpaket behebt die beiden ursprünglichen Lücken? Wurden die betroffenen Dienste und Arbeitsprozesse danach erneuert?
- Zusatzhinweis und Auffälligkeiten: Wurde CVE-2026-115560 gesondert bewertet? Gibt es ungewöhnliche Anfragen, Dateien oder Prozesse, die unabhängig vom Update untersucht werden müssen?
Bei selbst entwickelter Software reicht die sichtbare Funktionsfähigkeit ebenso wenig als Nachweis wie ein grünes Versionslabel. Die Prüfung vor dem Start mit echten Nutzern ordnet technische und betriebliche Fragen ein. Auch eine klar abgegrenzte Anwendung wie KaffeeMappe braucht einen nachvollziehbaren Betriebszustand. Die Checkliste zur Digitalisierung hilft dir, Zuständigkeiten und nächste Schritte festzuhalten.
Mein Fazit: Den Hinweis nutzen, den Betrieb verifizieren
Ein lokaler Versionscheck ist ein guter Einstieg, aber nicht das Ende der Arbeit. Entscheidend ist, ob genau die PHP-Installation deiner Website nachweislich korrigiert läuft. Lass dir diese Bestätigung vom Hostinganbieter oder den zuständigen Administratoren geben. So wird aus einer alarmierenden Meldung eine überschaubare Folge prüfbarer Aufgaben.
Neues aus dem Consulting Magazin