Stand: 21. Oktober 2026. Die Lage entwickelt sich laufend. Massgeblich sind immer die offizielle Sicherheitsmeldung des PHP-Projekts und die Hinweise Ihres Hosters oder Ihrer Linux-Distribution (siehe Quellen am Ende des Beitrags).
Das Wichtigste in Kürze
- PHP2Shell bezeichnet zwei kritische Schwachstellen im PHP-Interpreter (CVE-2026-109618 und CVE-2026-109619, je CVSS 9.2), die Remote Code Execution ohne Anmeldung ermöglichen.
- Die Lücken stecken in PHP selbst, nicht in WordPress, Shopware & Co. – auch tadellos programmierte Websites sind betroffen, und zwar praktisch alle Versionen ab PHP 5.4.
- Gepatcht sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. PHP 8.1 und älter erhalten vom PHP-Projekt kein offizielles Update mehr.
- Erste Angriffsversuche wurden bereits beobachtet. Notmassnahmen und WAF-Regeln verkleinern das Risiko, ersetzen das Update aber nicht.
- Mehr als jede dritte PHP-Website läuft laut W3Techs noch auf PHP 5 oder 7. Für sie führt der sichere Weg über eine Code-Migration auf PHP 8.2+ – idealerweise direkt auf 8.4 oder 8.5.
Was ist PHP2Shell?
PHP2Shell ist der Spitzname für zwei Schwachstellen, die das PHP-Projekt am 21. Oktober 2026 mit Notfall-Updates geschlossen hat. Beide sind mit CVSS 9.2 (v4.0) als kritisch eingestuft und erlauben im schlimmsten Fall, dass ein Angreifer ohne Benutzerkonto eigenen Code auf dem Webserver ausführt – eine sogenannte Remote Code Execution (RCE). Laut PHP-Sicherheitsteam reicht bei Apache mit mod_php eine einzige präparierte Anfrage, und zwar bevor überhaupt Code der eigentlichen Website läuft.
Gefunden haben die Lücken Wiz Research, das Sicherheitsunternehmen Calif und das Codex-Security-Team von OpenAI. Bemerkenswert: Die fehlerhaften Stellen steckten seit über zehn Jahren im PHP-Code. Erst moderne KI-Modelle haben nach Aussage der Forschenden die Hürde so weit gesenkt, dass daraus ein funktionierender Exploit wurde. Nachdem Informationen vorzeitig an die Öffentlichkeit gelangt waren, zog das PHP-Projekt die Veröffentlichung auf den 21. Oktober, 14:00 Uhr UTC vor. Sicherheitsfirmen melden bereits erste Angriffsversuche, zum Teil schon vor Erscheinen des Patches.
Die zwei Lücken im Überblick
| Lücke | Was passiert (vereinfacht) | Teilschutz bis zum Update |
|---|---|---|
| CVE-2026-109618 – RCE via OOM corruption | Läuft PHP während einer Anfrage in sein Speicherlimit, kann die Fehlerbehandlung halb initialisierte interne Daten hinterlassen. Beim Aufräumen behandelt PHP diese fälschlich als gültig. | memory_limit nicht überschreibbar auf -1 setzen (nur mit Container- oder cgroup-Limit), post_max_size tief halten, Anfragegrösse am Webserver begrenzen |
| CVE-2026-109619 – RCE via stale global state | Interner Zustand einer Anfrage überlebt, obwohl sein Speicher bereits freigegeben ist. Die nächste Anfrage im selben PHP-Prozess kann diesen veralteten Zustand verwenden. | session.upload_progress.enabled=0 setzen und alle Worker neu starten; unter PHP 8.5 zusätzlich fatal_error_backtraces=0 |
Sicherheitsforscher weisen zudem darauf hin, dass sich unter Umständen auch ohne vollständige Codeausführung Speicher der PHP-Prozesse auslesen lässt. Darin können Passwörter, Session-Token, API-Schlüssel oder Zertifikate aus fremden Anfragen liegen. Ein erfolgreicher Angriff ist damit nicht nur ein Problem für die Website, sondern auch für alle Systeme, mit denen sie verbunden ist – vom Online-Shop bis zur Buchhaltungsschnittstelle.
Wer ist betroffen?
Kurz: fast jede Website und Webanwendung, die mit PHP läuft. Laut PHP-Advisory sind alle Installationen gefährdet, die Webanfragen verarbeiten – unabhängig davon, ob PHP über PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed eingebunden ist. Das höchste Risiko sieht das PHP-Team bei mod_php. Typische Systeme in Schweizer KMU:
Ein Plugin- oder CMS-Update schliesst PHP2Shell nicht. Die Lücke sitzt eine Ebene tiefer, im PHP-Interpreter auf dem Server. Geschlossen wird sie nur durch ein Update von PHP selbst – beim eigenen Server durch Ihre IT, beim Hosting durch den Hoster.
Welche PHP-Versionen gepatcht sind – und welche nicht
| PHP-Version | Status nach PHP2Shell | Sicherheitsupdates bis |
|---|---|---|
| PHP 8.5 | Gepatcht ab 8.5.12 | 31.12.2029 |
| PHP 8.4 | Gepatcht ab 8.4.27 | 31.12.2028 |
| PHP 8.3 | Gepatcht ab 8.3.36 | 31.12.2027 |
| PHP 8.2 | Gepatcht ab 8.2.35 | 31.12.2026 – in gut zehn Wochen ist Schluss |
| PHP 8.1, 8.0, 7.4 | Kein offizielles Release; nur minimale Quellcode-Backports oder Pakete von Distributionen und LTS-Anbietern | bereits ausgelaufen |
| PHP 7.3 und älter, PHP 5 | Kein Patch vom PHP-Projekt; allenfalls über kommerzielle LTS-Anbieter | seit Jahren ausgelaufen |
Wie gross das Problem ist, zeigt die Statistik: Laut W3Techs läuft PHP auf 69.3 % aller Websites mit bekannter Server-Sprache. Davon nutzen 27 % noch PHP 7 und 7.7 % sogar PHP 5 (Stand 21. Oktober 2026). Mehr als jede dritte PHP-Website läuft damit auf einer Version, für die es keinen regulären Patch gibt – die ebenfalls ausgelaufenen Versionen 8.0 und 8.1 noch nicht mitgezählt.
Achtung bei Linux-Servern: Debian, Ubuntu, Red Hat und andere Distributionen spielen Sicherheitsfixes oft unter der alten Versionsnummer ein. Ob Ihr Server geschützt ist, erkennen Sie deshalb nicht an der Versionsnummer allein, sondern am Changelog des Pakets – dort müssen CVE-2026-109618 und CVE-2026-109619 auftauchen.
Sofortmassnahmen: Was Sie heute tun sollten
Inventar machen
Welche Websites, Shops und Webanwendungen laufen bei Ihnen auf PHP – und auf welcher Version? Denken Sie auch an Microsites, alte Kampagnenseiten, das Intranet und Tools, die ein externer Entwickler einmal gebaut hat. Die Version zeigt das Hosting-Panel oder der Befehl php -v auf dem Server.
PHP aktualisieren und alle Worker neu starten
Auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisieren bzw. die gepatchten Pakete Ihrer Distribution einspielen. Danach PHP-FPM, Apache und alle übrigen PHP-Prozesse neu starten – sonst läuft der verwundbare Code im Speicher weiter.
Den Hoster in die Pflicht nehmen
Bei Shared oder Managed Hosting liegt das PHP-Update beim Anbieter. Fragen Sie schriftlich nach, ob die gepatchten Versionen eingespielt sind, und stellen Sie im Control Panel eine unterstützte PHP-Version ein – mindestens 8.2, besser 8.4 oder 8.5 –, sofern Ihre Anwendung damit läuft.
Notmassnahmen, wenn das Update nicht sofort geht
Die vom PHP-Team genannten Einstellungen (siehe Kasten unten) blockieren bekannte Angriffswege, aber nicht alle. Das britische NCSC rät, Systeme vom Netz zu nehmen, die sich nicht umgehend patchen lassen. Für eine Website, die Kundendaten verarbeitet, ist das die ehrlichste Option.
WAF als zusätzliche Schicht
Cloudflare hat Schutzregeln gegen PHP2Shell schon vor der Veröffentlichung aktiviert, auch im Gratis-Plan. Das verschafft Zeit, ist laut Cloudflare aber ausdrücklich kein Ersatz für das PHP-Update: Angreifer haben ihre Payloads bereits angepasst, um die Filter zu umgehen.
Auf Spuren prüfen und Zugangsdaten wechseln
Mögliche Hinweise sind ungewöhnliche Multipart-Anfragen mit anschliessenden Memory-Limit-Fehlern oder gehäuften HTTP-500-Fehlern, auffällig grosse PHPSESSID-Cookies in Antworten und unerklärliche Neustarts von PHP-Workern. Bei Verdacht: Datenbank-Passwörter, API-Schlüssel und Tokens rotieren, den Incident-Response-Plan auslösen und den Vorfall dem Bundesamt für Cybersicherheit (BACS) melden.
Notmassnahmen laut PHP-Advisory – kein Ersatz für das Update
; php.ini oder FPM-Pool – danach ALLE Worker neu starten
session.upload_progress.enabled = 0 ; CVE-2026-109619
fatal_error_backtraces = 0 ; nur PHP 8.5
post_max_size = 8M ; 32M, wenn Uploads nötig sind
; FPM-Pool, nur zusammen mit Container-/cgroup-Limit (CVE-2026-109618):
php_admin_value[memory_limit] = -1Wichtig: Diese Werte müssen in der php.ini, im FPM-Pool oder in der Server-Konfiguration stehen. Per ini_set() oder .user.ini gesetzt, greifen sie zu spät. Auch das Ausblenden von Fehlermeldungen hilft nicht. Und: Das Speicherlimit aufzuheben, ohne eine Grenze auf Container- oder Systemebene zu setzen, kann den Server bei Last in die Knie zwingen. Lassen Sie solche Eingriffe von Ihrer IT oder Ihrem Hoster vornehmen – und planen Sie das eigentliche Update trotzdem sofort ein. Wie Sie Updates generell schneller und verlässlich ausrollen, zeigt unser Ratgeber zum Patch-Management.
Das eigentliche Problem: alter Code auf alter PHP-Version
Für viele KMU ist das PHP-Update nicht in fünf Minuten erledigt – weil die Website oder das Kundenportal auf einer neueren PHP-Version schlicht nicht mehr läuft. Ein typisches Bild: Eine Agentur oder ein Freelancer hat die Anwendung vor Jahren für PHP 5.6 oder 7.x gebaut, seither wurde nur das Nötigste angepasst, und der Hoster hat die alte PHP-Version auf Wunsch weiterlaufen lassen. Das ging lange gut. Mit PHP2Shell nicht mehr.
Der Grund: Seit PHP 5 hat sich die Sprache stark verändert, vor allem mit den Versionen 7.0 und 8.0. Funktionen wurden entfernt, Vergleiche verhalten sich anders, aus Warnungen wurden harte Fehler. Ein Versionssprung ohne Code-Anpassung endet oft mit einer weissen Seite – oder schlimmer: mit stillen Logikfehlern, etwa in Preisberechnungen oder Login-Prüfungen.
| Änderung | Seit | Folge im alten Code |
|---|---|---|
| mysql_*-Funktionen entfernt | PHP 7.0 | Datenbankzugriff bricht komplett – Umstellung auf PDO oder mysqli mit Prepared Statements nötig |
| each() und create_function() entfernt | PHP 8.0 | Fatal Error, sobald die Stelle im Code durchlaufen wird |
| Neue Vergleichslogik: 0 == "abc" ist jetzt false | PHP 8.0 | Stille Logikfehler in Prüfungen, Filtern und Berechtigungen |
| Interne Funktionen werfen TypeError und ValueError | PHP 8.0 | Abbruch der Anfrage statt Warnung im Log |
| String-Zugriff mit geschweiften Klammern ($text{0}) entfernt | PHP 8.0 | Syntaxfehler – die Datei lädt gar nicht erst |
| null an interne Funktionen, z. B. strlen(null) | PHP 8.1 | Deprecation-Meldungen, künftig harte Fehler |
| Dynamische Properties, "${var}"-Interpolation, utf8_encode() | PHP 8.2 | Deprecation-Meldungen, in PHP 9 voraussichtlich Fehler |
Dazu kommen veraltete Frameworks und Erweiterungen: Anwendungen auf Laravel 5, Zend Framework 1 oder CodeIgniter 2 wurden nie für PHP 8 gebaut, und manches WordPress-Plugin wird seit Jahren nicht mehr gepflegt. Genau diese Systeme stehen heute oft auf PHP 7.x – und damit ohne offiziellen PHP2Shell-Fix da. Einen Überblick über weitere Systeme, deren Support 2026 endet, finden Sie in unserem Beitrag IT End-of-Life 2026.
So bringen wir Ihren PHP-Code auf 8.2+
Genau hier setzt GIAR Digital an: Wir schreiben bestehenden PHP-Code so um, dass er auf PHP 8.2 und neuer sauber läuft – ohne dass Sie Ihre Anwendung neu erfinden müssen. Das Ziel ist nicht nur, PHP2Shell zu schliessen, sondern wieder auf einer Version zu stehen, die regelmässig Sicherheitsupdates erhält. So gehen wir vor:
Sofort absichern
Bevor wir am Code arbeiten, schliessen wir das akute Risiko: gepatchte PHP-Pakete, wo möglich; Notmassnahmen und WAF-Regeln, wo nicht – plus Prüfung auf Spuren eines Angriffs.
Code-Analyse und Aufwandschätzung
Wir prüfen Ihre Codebasis automatisiert auf Inkompatibilitäten, unter anderem mit PHPCompatibility und PHPStan, und erfassen die Abhängigkeiten über Composer. Sie sehen, was angepasst werden muss, und erhalten eine konkrete Aufwandschätzung mit Meilensteinen.
Automatisiert modernisieren, von Hand prüfen
Mechanische Änderungen – entfernte Funktionen, veraltete Syntax, Typ-Deklarationen – erledigt das Refactoring-Werkzeug Rector regelbasiert. Was die Logik betrifft, etwa geänderte Vergleiche oder Datenbankzugriffe, prüfen und überarbeiten unsere Entwickler von Hand. Alte mysql_*-Aufrufe ersetzen wir durch PDO mit Prepared Statements – das schliesst nebenbei SQL-Injection-Lücken.
Testen auf Staging
Vor der Umstellung sichern Tests das heutige Verhalten ab. Die modernisierte Version läuft zuerst auf einer Staging-Umgebung mit der Ziel-PHP-Version, bis alle wichtigen Abläufe – Login, Bestellungen, Formulare, Schnittstellen – nachweislich funktionieren.
Go-live und Betrieb
Umstellung mit Rückfallplan, danach Überwachung der Fehler-Logs. Auf Wunsch übernehmen wir Hosting, Sicherheits-Updates und Wartung, damit Ihre Anwendung nicht wieder jahrelang auf einer alten Version stehen bleibt.
Unsere Empfehlung zur Zielversion: mindestens PHP 8.2, denn nur 8.2 und neuer erhalten den offiziellen PHP2Shell-Fix. Weil PHP 8.2 aber schon am 31. Dezember 2026 seine letzten Sicherheitsupdates bekommt, empfehlen wir in der Regel, direkt auf PHP 8.4 (Sicherheitsupdates bis Ende 2028) oder 8.5 (bis Ende 2029) zu gehen. Der Mehraufwand gegenüber 8.2 ist meist klein – und verschafft Ihnen mehrere Jahre Ruhe.
Modernisieren, neu bauen oder ersetzen?
| Ausgangslage | Unser Rat |
|---|---|
| Eigene Anwendung mit wertvoller Geschäftslogik, Code einigermassen strukturiert | Modernisieren: schrittweise auf PHP 8.4 oder 8.5 heben und dabei Tests ergänzen |
| WordPress-Website oder Shop mit veraltetem Theme und verwaisten Plugins | Plugins ersetzen, Theme aktualisieren oder neu aufsetzen, dann die PHP-Version anheben |
| Gewachsener PHP-5-Code ohne Struktur und Dokumentation, aber geschäftskritisch | Gezielte Neuentwicklung, oft als MVP mit den wichtigsten Funktionen zuerst |
| Standardaufgabe wie Newsletter oder Terminbuchung, für die es gute Software gibt | Durch eine Standardlösung ersetzen statt aufwendig migrieren |
Was kostet das? Das hängt vom Umfang und Zustand des Codes ab – eine schlanke Website ist in der Regel deutlich schneller umgestellt als ein über Jahre gewachsenes Kundenportal. Wir arbeiten transparent nach Aufwand zu den Ansätzen unserer Custom-Software-Entwicklung (CHF 130–160 pro Stunde). Nach der Code-Analyse wissen Sie, womit Sie rechnen müssen. Ist eine Neuentwicklung sinnvoller, starten wir schlank mit einem MVP.
Fazit: Patchen ist Pflicht, modernisieren die nachhaltige Lösung
PHP2Shell gehört zu den gravierendsten PHP-Lücken seit Jahren: Sie betrifft praktisch jede PHP-Installation, ist ohne Login ausnutzbar und wird bereits angegriffen. Wer auf PHP 8.2 bis 8.5 läuft, kommt mit wenig Aufwand davon – aktualisieren, Worker neu starten, Spuren prüfen.
Wer noch auf PHP 7 oder älter festsitzt, sollte die Lücke als Weckruf verstehen. Notmassnahmen kaufen Zeit, aber keine Sicherheit. Der nachhaltige Weg ist, den Code auf PHP 8.2+ zu heben – am besten direkt auf 8.4 oder 8.5 – und ihn danach regelmässig aktuell zu halten. Wie Sie Schwachstellen künftig früher erkennen, beschreibt unser Ratgeber zum Vulnerability Management; für den Ernstfall gehört ein Incident-Response-Plan in die Schublade. Ob Ihre Websites und Systeme über PHP2Shell hinaus angreifbar sind, zeigt ein Penetrationstest.
PHP-Check für Ihre Websites und Anwendungen
Wir prüfen, welche Ihrer Systeme von PHP2Shell betroffen sind, schliessen die Lücke und schreiben Ihren Code auf PHP 8.2+ um – auf Wunsch direkt für PHP 8.4 oder 8.5. Pragmatisch, mit Tests und klarer Aufwandschätzung.
PHP-Check anfragen