{"id":22776,"date":"2026-10-22T09:21:00","date_gmt":"2026-10-22T07:21:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=22776"},"modified":"2026-10-22T10:53:36","modified_gmt":"2026-10-22T08:53:36","slug":"php2shell-schutz-updates-ungepatchte-websites","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/web-entwicklung\/php2shell-schutz-updates-ungepatchte-websites\/","title":{"rendered":"PHP2Shell: Was jetzt sch\u00fctzt und warum ungepatchte Websites bleiben"},"content":{"rendered":"

Stand: 22. Oktober 2026.<\/strong> PHP2Shell betrifft die technische Grundlage zahlreicher Websites: Zwei kritische Sicherheitsl\u00fccken k\u00f6nnen unter passenden Bedingungen die Ausf\u00fchrung fremden Codes ohne Anmeldung erm\u00f6glichen. Sicherheitsupdates liegen seit dem 21. Oktober vor. Die entscheidende Frage lautet deshalb inzwischen: Welche \u00f6ffentlich erreichbaren Installationen laufen tats\u00e4chlich mit korrigiertem PHP? [1]<\/a> [6]<\/a><\/p>

Neue Lage: Angriffsversuche schon vor der Ver\u00f6ffentlichung<\/h2>

AWS berichtet aus der eigenen MadPot-Telemetrie von einem PHP2Shell-Angriffsversuch am 17. Oktober 2026, also vor der \u00f6ffentlichen Bekanntgabe. F\u00fcr weitere beobachtete Versuche blieb offen, ob ein Angriff auf reale Zielsysteme erfolgreich gewesen w\u00e4re. Das ist ein belegtes Warnsignal, aber keine weltweite Opferz\u00e4hlung. Die Untersuchung m\u00f6glicherweise betroffener Systeme sollte deshalb nicht erst am Ver\u00f6ffentlichungstag beginnen. AWS: eigene Beobachtungen und Grenzen<\/a><\/p>\n

Was hinter PHP2Shell steckt<\/h2>\n

Die Kennungen lauten CVE-2026-109618<\/strong> und CVE-2026-109619<\/strong>. Beim ersten Fehler ger\u00e4t die Speicherverwaltung nach Speichermangel in einen ung\u00fcltigen Zustand. Beim zweiten bleiben interne Verweise auf bereits freigegebenen Speicher bestehen. Sp\u00e4tere Verarbeitung kann solche Zust\u00e4nde gef\u00e4hrlich weiterverwenden. Beide Probleme sitzen in PHP selbst. [3]<\/a> [4]<\/a><\/p>\n

\u201eAlle Versionen ab PHP 5\u201c beschreibt die au\u00dfergew\u00f6hnliche Reichweite, ersetzt aber keine Paketpr\u00fcfung. Alte 5er- und 7er-Zweige geh\u00f6ren ebenso zur Pr\u00fcfung wie PHP 8. cPanel f\u00fchrt auch \u00e4ltere PHP-Pakete und konkrete korrigierte Anbieterrevisionen auf. Der Wechsel von PHP 7 auf irgendeine PHP-8-Version w\u00e4re daher kein ausreichender Nachweis. [7]<\/a><\/p>\n

Besonders kritisch ist Apache mit mod_php: Ein best\u00e4tigter Angriffsweg greift bereits vor dem Anwendungscode. Auch PHP-FPM darf nicht als sicher gelten; die PHP Foundation berichtet dort ebenfalls best\u00e4tigte Codeausf\u00fchrung \u00fcber anwendungsabh\u00e4ngige Wege. Ein WordPress-Login sch\u00fctzt folglich nicht zuverl\u00e4ssig vor einem Fehler in der darunterliegenden Laufzeit. [2]<\/a><\/p>\n

Welche Updates sch\u00fctzen?<\/h2>\n

Die korrigierten offiziellen Ver\u00f6ffentlichungen sind 8.2.35, 8.3.36, 8.4.27 und 8.5.12<\/strong>. F\u00fcr die jeweilige Reihe gilt dieser oder ein neuerer korrigierter Stand. PHP 8.1 und \u00e4ltere Reihen erhalten keine regul\u00e4ren Ver\u00f6ffentlichungen mehr vom PHP-Projekt. F\u00fcr 7.4, 8.0 und 8.1 gibt es ausnahmsweise minimale Quellcode-Backports; Distributoren und LTS-Anbieter k\u00f6nnen eigene korrigierte Pakete liefern. [1]<\/a><\/p>\n

Eine alte Basisversionsnummer beweist deshalb nicht automatisch einen fehlenden Patch. Entscheidend sind die vollst\u00e4ndige Paketrevision und die Best\u00e4tigung f\u00fcr beide<\/em> CVEs. Umgekehrt beweist \u201ePHP 8\u201c keinen Schutz. [7]<\/a><\/p>\n

\"Vier
Ein Update ist erst im laufenden Webbetrieb wirksam.<\/figcaption><\/figure>\n

Vom Paketupdate zum gesch\u00fctzten Betrieb<\/h2>\n
  1. Bestand erfassen:<\/strong> Domains, PHP-Pools, Container, alte Testinstallationen und eingebettete Verwaltungsoberfl\u00e4chen geh\u00f6ren zur Inventur.<\/li>
  2. Korrektur belegen:<\/strong> F\u00fcr jede Laufzeit sind Paketquelle, Revision und Behebung beider CVEs zu dokumentieren.<\/li>
  3. Laufende Instanzen erneuern:<\/strong> PHP-Worker m\u00fcssen den neuen Stand laden. Eigene Container ben\u00f6tigen ein korrigiertes Image und ein erneutes Deployment. Ein Update des Hosts ver\u00e4ndert kein bereits gebautes Containerimage. [8]<\/a><\/li>
  4. Webbetrieb kontrollieren:<\/strong> Die Kommandozeile kann eine andere PHP-Installation verwenden als die Website. Erst die Zuordnung der Domain zur tats\u00e4chlich laufenden Version samt Funktionspr\u00fcfung schlie\u00dft die Kontrolle ab.<\/li><\/ol>\n

    Falls ein Patch kurzfristig unm\u00f6glich bleibt, empfiehlt ENISA die Pr\u00fcfung einer Isolation \u00f6ffentlich erreichbarer Anwendungen. Eine statische Wartungsseite vor PHP kann dabei den Betrieb sichtbar unterbrechen, ohne weitere Anfragen an die gef\u00e4hrdete Laufzeit weiterzugeben. Ein Wartungsplugin innerhalb derselben PHP-Anwendung erreicht dieses Ziel nicht zuverl\u00e4ssig. [5]<\/a><\/p>\n

    Die offiziellen Konfigurationsma\u00dfnahmen sind lediglich \u00dcbergangshilfen. Beispielsweise blockiert session.upload_progress.enabled=0<\/code> bestimmte best\u00e4tigte Session-Angriffswege, aber keine vollst\u00e4ndige Klasse m\u00f6glicher Varianten. Auch \u00c4nderungen an Speichergrenzen sind kein pauschaler Reparaturschalter. Unbegrenzter PHP-Speicher kann zus\u00e4tzliche Verf\u00fcgbarkeitsrisiken schaffen. Solche Eingriffe ben\u00f6tigen eine abgestimmte Begrenzung au\u00dferhalb von PHP und ersetzen den Patch nicht. [3]<\/a> [4]<\/a><\/p>\n

    Was ohne Update passieren kann<\/h2>\n

    Der Ausgangspunkt ist Codeausf\u00fchrung mit den Rechten des Webprozesses, nicht automatisch ein Root-Zugang. Daraus ergeben sich abh\u00e4ngig von Berechtigungen und erreichbaren Geheimnissen erhebliche Folgerisiken: ausgelesene Datenbankzug\u00e4nge, gestohlene Kundendaten, ver\u00e4nderte Inhalte, eingeschleuste Schadsoftware oder missbrauchte Schnittstellenschl\u00fcssel. Weitere Angriffe auf interne Dienste sind m\u00f6glich, sofern Netzwege und Rechte solche Zugriffe zulassen. [3]<\/a><\/p>\n

    F\u00fcr einen Shop kann bereits eine ver\u00e4nderte Zahlungsseite schwerer wiegen als ein sichtbarer Ausfall. Dazu kommen Untersuchung, Wiederherstellung, Ausfallzeiten und Vertrauensverlust. Ein sp\u00e4terer Patch entfernt keine bereits eingerichtete Hintert\u00fcr. Bei konkreten Einbruchsspuren geh\u00f6ren Isolation, Beweissicherung, Pr\u00fcfung der Zug\u00e4nge und Wiederherstellung aus einem vertrauensw\u00fcrdigen Stand zur Reaktion.<\/p>\n

    Werden die Updates wirklich \u00fcberall installiert?<\/h2>\n

    Einsch\u00e4tzung:<\/strong> Ein schneller erster R\u00fcckgang der gef\u00e4hrdeten Installationen ist plausibel, ein vollst\u00e4ndiger Abschluss innerhalb weniger Tage kaum. Zentral betreute Plattformen k\u00f6nnen viele Websites gleichzeitig korrigieren. Bei individuellen Servern h\u00e4ngt das Ergebnis an Zust\u00e4ndigkeiten, Paketverf\u00fcgbarkeit, Kompatibilit\u00e4t und kontrollierten Neustarts. Google Cloud unterscheidet ausdr\u00fccklich zwischen automatisch aktualisierten Laufzeiten und Diensten mit notwendigem Redeployment. [8]<\/a><\/p>\n

    Besonders hartn\u00e4ckig d\u00fcrfte der Restbestand werden: aufgegebene Projekte, alte Agenturinstallationen, Container ohne Wartungsprozess und Anwendungen mit Abh\u00e4ngigkeit von abgek\u00fcndigten PHP-Reihen. Verz\u00f6gerungen sind dabei nicht automatisch Nachl\u00e4ssigkeit einzelner Administratoren. Fehlende Budgets, unklare Verantwortung und ungepr\u00fcfte Altsoftware k\u00f6nnen einen technisch einfachen Patch organisatorisch blockieren. Eine konkrete weltweite Updatequote w\u00e4re derzeit Spekulation.<\/p>\n

    Wie viele Websites bleiben bedroht?<\/h2>\n

    W3Techs meldet am 22. Oktober PHP bei 69,3 Prozent der Websites mit bekannter serverseitiger Programmiersprache<\/strong>. Innerhalb des erkannten PHP-Bestands entfallen 26,9 Prozent auf PHP 7 und 7,7 Prozent auf PHP 5: zusammen 34,6 Prozent. Das beschreibt Verbreitung und Altbestand, keine gemessene Zahl ungepatchter Websites. [9]<\/a><\/p>\n

    Eine belastbare absolute Restzahl l\u00e4sst sich daraus nicht berechnen. Anbieter-Backports, unterschiedliche Konfigurationen, verdeckte Versionsangaben und mehrere Websites pro Server verhindern die direkte Gleichsetzung. Auch einzelne Webseiten, Domains und Server sind unterschiedliche Z\u00e4hleinheiten.<\/p>\n

    Als reine Rechenillustration: Von einer Million tats\u00e4chlich betroffener Installationen blieben bei 95 Prozent erfolgreich abgeschlossenen Updates noch 50.000 ungepatcht. Das ist keine Messung und keine Prognose<\/strong>. Die Rechnung zeigt lediglich, warum selbst eine hohe Updatequote bei gro\u00dfer Verbreitung einen erheblichen Restbestand zul\u00e4sst. F\u00fcr die konkrete Website z\u00e4hlt der nachgewiesene Patchstand wesentlich mehr als jede globale Prozentzahl.<\/p>\n

    Linux-Praxis: zuerst die tats\u00e4chlich verwendete Installation erfassen<\/h2>\n

    Die folgenden Paketbeispiele gelten f\u00fcr Debian-\/Ubuntu-Systeme mit APT und bereits eingerichteten, vertrauensw\u00fcrdigen Paketquellen. Die jeweilige PHP-Reihe muss dort schon installiert sein. RPM-Systeme, Hosting-Panels und selbst gebaute Container ben\u00f6tigen den passenden Anbieterablauf. Eine willk\u00fcrlich erg\u00e4nzte Fremdquelle w\u00e4re keine belastbare Reparaturstrategie.<\/p>\n

    Vor dem Eingriff geh\u00f6ren eine wiederherstellbare Sicherung, die Zuordnung von Domains zu PHP-Pools und ein kurzer Funktionstestplan zum Ablauf. Paketinstallationen k\u00f6nnen Dienste bereits w\u00e4hrend der Installation neu starten. Ein Wartungsfenster muss daher vor dem Installationsbefehl beginnen. Die Bestandsaufnahme zeigt CLI und Dienste, ersetzt aber noch nicht die Kontrolle des Webhandlers:<\/p>\n\n

    Shell<\/span>Linux: PHP-Bestand erfassen<\/span>