--- title: "PHP2Shell: Welche PHP-Versionen sicher sind und was jetzt zu tun ist" description: "Zwei kritische PHP-Sicherheitslücken, CVE-2026-109618 und CVE-2026-109619, sind in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 behoben. Wer betroffen ist, welche Versionen sicher sind, was Sie auf Ihren Servern prüfen sollten und was zu tun ist, wenn Sie noch PHP 8.1 oder älter betreiben." author: "Luboš Zápotočný" published: "2026-10-21" language: "de" canonical: "https://zapolu.com/de/blog/php2shell-php-aktualisieren/" --- # PHP2Shell: Welche PHP-Versionen sicher sind und was jetzt zu tun ist Am 21. Oktober 2026 veröffentlichte das PHP-Projekt die Versionen [PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35](https://www.php.net/archive/2026.php#2026-10-21-5), um zwei kritische Sicherheitslücken zu beheben, CVE-2026-109618 und CVE-2026-109619. Beide erlauben es einem Angreifer, ohne Anmeldung Code auf einem Webserver auszuführen. Die beiden Lücken sind allgemein unter dem Namen PHP2Shell bekannt, benannt nach dem Exploit-Tool, das die Forscher aus beiden Fehlern gebaut haben ([Zusammenfassung von Sansec](https://sansec.io/research/php2shell)). Die Sicherheitsmeldung von PHP hält fest, dass „nur ein Update eine vollständige Lösung“ ist. Alle Herstellerangaben in diesem Beitrag wurden am 21. Oktober 2026 anhand der verlinkten Quelle geprüft. ## Betroffene Systeme Laut der [PHP-Ankündigung](https://www.php.net/archive/2026.php#2026-10-21-5) betrifft das Risiko „alle PHP-Installationen, die Web-Requests verarbeiten“, unabhängig davon, wie PHP an den Webserver angebunden ist. Das schließt Magento-, Mage-OS-, WordPress-, Drupal-, Laravel- und Symfony-Anwendungen sowie jeden eigenen PHP-Code ein. Sansec berichtet, dass die Forscher auf Magento 2.4.9, WordPress, Drupal, Nextcloud und weiteren Anwendungen ohne Anmeldung Code ausgeführt haben. PHP verarbeitet den Request des Angreifers, bevor er die Anwendung überhaupt erreicht. Daher können weder der eigene Code eines Shops noch seine Erweiterungen den Angriff blockieren. Die zweite Sicherheitslücke kann zudem offenlegen, was der Server im Arbeitsspeicher hält. Ein Server, der eine anfällige Version betrieb und dabei aus dem Internet erreichbar war, kann Passwörter, API-Schlüssel oder Sitzungsdaten preisgegeben haben. Nach dem Update empfiehlt es sich, die Zugangsdaten dieses Servers zu ändern. Shopify-Händler müssen keine eigene PHP-Installation aktualisieren, da Shopify die Plattform hostet ([FAQ von Shopify](https://www.shopify.com/faq)). Eigene Apps, die in PHP geschrieben sind und auf Ihren eigenen Servern laufen, sind wie jeder andere PHP-Code betroffen. ## Sichere Versionen | Branch | Sicher ab | Ende des Sicherheitssupports | | ------ | --------- | --------------------- | | 8.5 | 8.5.12 | 31. Dezember 2029 | | 8.4 | 8.4.27 | 31. Dezember 2028 | | 8.3 | 8.3.36 | 31. Dezember 2027 | | 8.2 | 8.2.35 | 31. Dezember 2026 | | 8.1 und älter | keine Korrektur durch das PHP-Projekt | beendet | Die Supportdaten stammen von der PHP-Seite zu den [unterstützten Versionen](https://www.php.net/supported-versions.php). Ein System mit PHP 8.2 braucht dieses Update jetzt und vor Jahresende einen Wechsel auf einen neueren Branch, es sei denn, es nutzt die eigenen PHP-Pakete von Debian 12, die das Long-Term-Support-Team von Debian pflegt ([DLA-4848-1](https://security-tracker.debian.org/tracker/DLA-4848-1)). ## Prüfpunkte auf Ihren Servern Das Einspielen des Updates ist in der Regel schnell erledigt. Das größte Risiko liegt in der Annahme, es sei installiert, obwohl dies nicht der Fall ist. Diese Fragen sollten Sie dem Betreiber Ihrer Server stellen: - **Welche PHP-Version läuft tatsächlich auf dem Webserver?** Sie kann von der Version auf der Kommandozeile abweichen, und auf einem Server können mehrere PHP-Versionen parallel laufen. - **Belegt die Versionsnummer die Korrektur?** Ubuntu etwa portiert die Korrektur in sein älteres PHP-Paket zurück, sodass ein gepatchter Server mit Ubuntu 24.04 weiterhin PHP 8.3.6 meldet ([Hinweis von Ubuntu](https://ubuntu.com/security/notices/USN-8948-1)). Dort muss die Paketversion mit dem Hinweis des Herstellers übereinstimmen. - **Wurde PHP nach dem Update neu gestartet?** Ein laufender PHP-Prozess behält den alten Code im Speicher, bis er neu gestartet wird. - **Wurden die Docker-Images neu gebaut?** Ein laufender Container aktualisiert sich nicht selbst. Die offiziellen PHP-Images auf Docker Hub wurden im Laufe des 21. Oktober mit den korrigierten Versionen neu gebaut. Ein Image, das vorher auf ihrer Grundlage gebaut wurde, enthält daher noch eine anfällige Version. - **Kümmert sich der Hosting-Anbieter darum?** Bei Adobe Commerce on Cloud nennt Adobes [Seite zu den PHP-Einstellungen](https://experienceleague.adobe.com/en/docs/commerce-on-cloud/user-guide/configure/app/php-settings) nicht, wann das PHP-Patch-Release aktualisiert wird, und wir haben am 21. Oktober keinen Hinweis von Adobe zu diesen Sicherheitslücken gefunden. Prüfen Sie die Version nach dem nächsten Deployment, und wenden Sie sich an den Adobe Support, falls sie noch unter dem sicheren Release liegt. ## Magento-Shops mit älteren Versionen Laut Adobes [Systemanforderungen](https://experienceleague.adobe.com/en/docs/commerce-operations/installation-guide/system-requirements) kann ein Magento-Shop nur bestimmte PHP-Versionen nutzen. Shops mit Version 2.4.8 oder 2.4.9 können bereits heute auf ein sicheres Release wechseln. Ein Shop mit Version 2.4.7 kann PHP 8.3 nutzen, und diese Version ist PHP 8.2 als Ziel vorzuziehen. Die neuesten Patches von 2.4.4 und 2.4.5 unterstützen nur PHP 8.1, das vom PHP-Projekt keine Korrekturen mehr erhält, und für diese Versionsreihen ist Adobes Sicherheitssupport bereits ausgelaufen ([Lifecycle Policy](https://experienceleague.adobe.com/en/docs/commerce-operations/release/planning/lifecycle-policy)). Ein solcher Shop ist bis zum abgeschlossenen Magento-Upgrade auf eine Korrektur seines Betriebssystemherstellers angewiesen (nächster Abschnitt). ## PHP 8.1 und älter Das PHP-Projekt veröffentlicht für 8.1 und ältere Versionen keine Releases mehr. Es hat minimale Korrekturen als Quellcode für 8.1, 8.0 und 7.4 bereitgestellt und verweist Nutzer an ihre Hersteller. Einige Hersteller haben sie bereits ausgeliefert: - **Ubuntu** hat die Korrektur für PHP 8.1 unter Ubuntu 22.04 mit den regulären Updates ausgeliefert ([USN-8948-1](https://ubuntu.com/security/notices/USN-8948-1)), für ältere PHP-Versionen auf älteren Ubuntu-Releases nur für Kunden von Ubuntu Pro ([USN-8948-2](https://ubuntu.com/security/notices/USN-8948-2)). - **Die Repositories von Ondřej Surý**, eine verbreitete Quelle für PHP unter Debian und Ubuntu, haben korrigierte Builds von PHP 5.6 bis 8.1 veröffentlicht ([PPA](https://launchpad.net/~ondrej/+archive/ubuntu/php)). - **Red Hat** hatte die Pakete für PHP 7.4 unter RHEL 8 korrigiert, für die übrigen PHP-Versionen unter RHEL 8, 9 und 10 aber noch keine Korrektur bereitgestellt ([Daten von Red Hat](https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-109618.json)). Das PHP-Projekt bezeichnet diese Korrekturen als „Minimal mitigation for EOL version“. Sie schließen die bekannten Angriffswege in einer Version, die sonst keine Sicherheitskorrekturen erhält. Das Upgrade auf eine unterstützte PHP-Version bleibt dennoch erforderlich. ## Übergangsmaßnahmen bis zum Update PHP nennt Konfigurationsänderungen, die das Risiko senken, und hält fest, dass sie „die Angriffsfläche für bestimmte Angriffswege verringern, eine Installation aber nicht sicher machen“. Dazu gehören das Abschalten des Session-Upload-Fortschritts und das Senken der maximalen Request-Größe. Die vollständige Liste steht in der [PHP-Ankündigung](https://www.php.net/archive/2026.php#2026-10-21-5). Cloudflare hat zudem für diese Sicherheitslücken [Firewall-Regeln ausgerollt](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/). Beides senkt das Risiko, bis das Update installiert ist. Das Blockieren von Multipart-Requests, dem Format, das Browser für Datei-Uploads verwenden, wird mitunter als Notlösung vorgeschlagen. In einem Magento-Shop blockiert das laut [Analyse von Sansec](https://sansec.io/research/php2shell) auch das Hochladen von Produktbildern im Admin und in manchen Shops den Warenkorb oder den Checkout. Geben Sie nach jeder solchen Änderung eine Testbestellung auf. ## Stand der Ausnutzung Cloudflare berichtet, dass die Details vor der Veröffentlichung bekannt wurden und man „Angriffsverkehr gegen unsere Kunden beobachtet“ habe ([Beitrag von Cloudflare](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/)). Bei unserer Prüfung am 21. Oktober war noch keine der beiden CVEs im [Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) der CISA verzeichnet. Wenn Sie nicht sicher sind, welche PHP-Version auf Ihren Servern läuft oder ob das Update auf allen Servern angekommen ist, prüfen und aktualisieren wir Ihre Server. Die PHP-Laufzeitumgebung aktuell zu halten ist Teil unserer [laufenden Betreuung](/de/services/ongoing-care/), und für ein einmaliges Update genügt [eine Nachricht an uns](/de/contact/).