{"id":842428,"date":"2026-10-22T11:49:18","date_gmt":"2026-10-22T11:49:18","guid":{"rendered":"https:\/\/www.knowband.com\/blog\/?p=842411\/"},"modified":"2026-10-22T11:58:28","modified_gmt":"2026-10-22T11:58:28","slug":"kritische-php-sicherheitsl%c3%bccken-oktober-2026-was-jeder-prestashop-shopbetreiber-jetzt-tun-muss","status":"publish","type":"post","link":"https:\/\/www.knowband.com\/blog\/de\/nachrichten\/kritische-php-sicherheitsl%c3%bccken-oktober-2026-was-jeder-prestashop-shopbetreiber-jetzt-tun-muss\/","title":{"rendered":"Kritische PHP-Sicherheitsl\u00fccken (Oktober 2026): Was jeder PrestaShop-Shopbetreiber jetzt tun muss"},"content":{"rendered":"

Lesen Sie dies zuerst. PHP hat am 21. Oktober zwei kritische Sicherheitsl\u00fccken behoben. L\u00e4uft Ihr Shop mit einer ungepatchten PHP-Version, kann ein Angreifer m\u00f6glicherweise ohne Anmeldung Code auf dem Server ausf\u00fchren. Beide Sicherheitsl\u00fccken betreffen PrestaShop nicht. Sie ben\u00f6tigen heute drei Antworten: Welche PHP-Version verwenden Sie? Hat Ihr Hosting-Anbieter die Fehlerbehebung bereits installiert (lassen Sie sich dies schriftlich best\u00e4tigen)? Wurde PHP seitdem neu gestartet?<\/p>\n

Die meisten Sicherheitsmeldungen handeln von Plugins oder Themes, und die L\u00f6sung ist ein Klick auf \u201eAktualisieren\u201c. Hier ist es anders. Ihr Problem liegt im Kern Ihres Shops, und die L\u00f6sung befindet sich auf dem Server \u2013 au\u00dferhalb des Einflussbereichs des Backends. Deshalb wird es leicht \u00fcbersehen, und deshalb sollten Sie sich einen Nachmittag Zeit nehmen, um es in Ruhe und systematisch zu beheben.<\/span><\/p>\n

Wie sich das entwickelt hat<\/b><\/h2>\n

Das PHP-Team warnte am 20. Oktober vor bevorstehenden Sicherheitsupdates. Diese wurden am 21. Oktober entdeckt und erhielten die CVE-Nummern CVE-2026-109618 und CVE-2026-109619. Beide Schwachstellen erreichen auf der CVSS-v4.0-Skala einen Wert von 9.2 und sind als \u00e4u\u00dferst kritisch eingestuft. Sie tragen den Namen \u201ephp2shell\u201c. Eine gemeinsame Sicherheitswarnung wurde von der Europ\u00e4ischen Kommission (GD CNECT), ENISA, CERT-EU, Europol EC3 und dem CSIRTs-Netzwerk herausgegeben.<\/span><\/p>\n

Die Europ\u00e4ische Kommission (GD CNECT), ENISA, CERT-EU, Europol EC3 und das CSIRTs-Netzwerk gaben daraufhin eine gemeinsame Erkl\u00e4rung ab, in der sie die Organisationen zum Handeln aufforderten. <\/span><\/p>\n

Korrigierte Versionen: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35.<\/span><\/p>\n

Was ist eigentlich kaputt?<\/b><\/h2>\n

\"\"<\/a><\/p>\n

Beide Schwachstellen k\u00f6nnen zur Ausf\u00fchrung von Schadcode ohne Authentifizierung f\u00fchren. Anders ausgedr\u00fcckt: Ein Unbekannter im Internet k\u00f6nnte Ihren Server dazu bringen, seine Anweisungen auszuf\u00fchren.<\/span><\/p>\n

CVE-2026-109618 ist ein Problem mit der Speicherverwaltung. Stellen Sie sich vor, PHP erstellt den Arbeitsbereich f\u00fcr eine eingehende Anfrage und der Server hat mittendrin keinen Speicher mehr. PHP stoppt, aber die nachfolgende Aufr\u00e4umroutine geht f\u00e4lschlicherweise davon aus, dass der halbfertige Arbeitsbereich vollst\u00e4ndig ist und verarbeitet ihn.<\/span><\/p>\n

CVE-2026-109619 \u00e4hnelt eher einem Nachwirkungsfehler. Daten, die zu einer Anfrage geh\u00f6rten, bleiben nach der Freigabe ihres Speichers weiterhin vorhanden und k\u00f6nnen von einer sp\u00e4teren Anfrage desselben Workers verwendet und als vertrauensw\u00fcrdig eingestuft werden.<\/span><\/p>\n

Beachten Sie, wo sich beides befindet: innerhalb von PHP. PrestaShop tr\u00e4gt keine Schuld und kann sich auch nicht dagegen verteidigen, da der Angriff erfolgen kann, bevor auch nur eine Zeile PrestaShop-Code ausgef\u00fchrt wurde. Daher \u00e4ndert ein Modul- oder Core-Update hier nichts. <\/span>Das PHP-Update behebt das Problem.<\/b><\/p>\n

Wessen Problem ist das?<\/b><\/h2>\n

Alle M\u00f6glichkeiten, PHP f\u00fcr Webanwendungen auszuf\u00fchren, werden ber\u00fccksichtigt: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Apache mit mod_php stellt den schlimmsten Fall dar, da der Angriff vor Ausf\u00fchrung des Anwendungscodes erfolgen kann.<\/span><\/p>\n

Was Sie tun m\u00fcssen, h\u00e4ngt von Ihrer Hosting-Umgebung und demjenigen ab, der Ihre PHP-Installation verwaltet:<\/p>\n\n\n\n\n\n\n\n\n
Hosting-Umgebung<\/th>\nWer verwaltet PHP?<\/th>\nEmpfohlene Ma\u00dfnahme<\/th>\n<\/tr>\n<\/thead>\n
Shared Hosting<\/td>\nIhr Hosting-Anbieter<\/td>\nKontaktieren Sie Ihren Hosting-Anbieter und bitten Sie um eine Best\u00e4tigung, dass die relevanten PHP-Sicherheitskorrekturen in Ihrer Umgebung angewendet wurden.<\/td>\n<\/tr>\n
VPS oder dedizierter Server<\/td>\nSie oder Ihr Systemadministrator<\/td>\nInstallieren Sie die passenden Sicherheitsupdates f\u00fcr Ihre PHP-Version oder Ihr Betriebssystempaket und starten Sie gegebenenfalls die entsprechenden PHP-Dienste neu.<\/td>\n<\/tr>\n
Docker oder Containerisiertes Hosting<\/td>\nDas Team, das f\u00fcr das Container-Image verantwortlich ist<\/td>\nErstellen Sie das Image neu, indem Sie ein PHP-Basis-Image mit den entsprechenden Sicherheitskorrekturen verwenden, und stellen Sie es anschlie\u00dfend erneut bereit, um die laufende Umgebung zu \u00fcberpr\u00fcfen.<\/td>\n<\/tr>\n
\u00c4ltere oder nicht unterst\u00fctzte PHP-Versionen<\/td>\nIhr Hosting-Anbieter oder Serveradministrator<\/td>\nPr\u00fcfen Sie, ob ein Backport f\u00fcr die Sicherheitsupdates des Anbieters verf\u00fcgbar ist. Falls nicht, planen Sie nach Pr\u00fcfung der Kompatibilit\u00e4t mit Ihrem Shop, Theme und Ihren Modulen den Wechsel zu einer unterst\u00fctzten PHP-Version.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Ihre Checkliste f\u00fcr heute<\/b><\/h2>\n
    \n
  1. Schlagen Sie die PHP-Version nach.<\/b> Backoffice, Erweiterte Parameter, Informationen.<\/span><\/li>\n
  2. Schreiben Sie an Ihren Gastgeber.<\/b> Fragen Sie direkt: \u201eWurden unsere Server gegen CVE-2026-109618 und CVE-2026-109619 gepatcht und wurden alle PHP-Prozesse neu gestartet?\u201c Notieren Sie sich die Antwort. Hinweis: Manche Distributionen installieren den Patch im Hintergrund, ohne die Versionsnummer zu \u00e4ndern. Daher l\u00e4sst sich anhand der Versionsnummer nicht feststellen, ob der Server anf\u00e4llig ist.<\/span><\/li>\n
  3. Aktualisieren Sie das Programm und starten Sie es anschlie\u00dfend neu.<\/b> Wechseln Sie zu einer korrigierten Version oder einem vom Hersteller gepatchten Paket. Starten Sie alle PHP-Prozesse neu. Ein Neustart wird oft vergessen. Erstellen Sie bei Docker die Images neu.<\/span><\/li>\n
  4. L\u00e4uft das mit PHP 8.1 oder \u00e4lter?<\/b> Das PHP-Projekt hat minimale Backports f\u00fcr 7.4, 8.0 und 8.1 ver\u00f6ffentlicht, und viele Linux-Distributionen und LTS-Anbieter liefern gepatchte Pakete aus. Pr\u00fcfen Sie, ob dies auch f\u00fcr Ihre Distribution gilt. Planen Sie in jedem Fall den Umstieg auf eine unterst\u00fctzte Version.<\/span><\/li>\n
  5. Denken Sie als N\u00e4chstes an PrestaShop.<\/b> W\u00e4hlen Sie eine Version, die Ihre Ziel-PHP-Version unterst\u00fctzt (siehe Tabelle unten). Diese Version muss nach dem Patch installiert werden, nicht davor.<\/span><\/li>\n<\/ol>\n

    Noch kein Patch verf\u00fcgbar? Die EU-Richtlinien schlagen eine Option vor: die betroffene Anwendung bis zur Behebung des Fehlers vom \u00f6ffentlichen Netzwerk zu trennen. F\u00fcr ein Gesch\u00e4ft mag das drastisch sein, aber es ist gut, diese M\u00f6glichkeit in Betracht zu ziehen.<\/span><\/p>\n

    \u00dcberbr\u00fcckungsl\u00f6sungen, w\u00e4hrend Sie warten<\/b><\/h2>\n

    PHP selbst vertritt die Position, dass keine Schutzma\u00dfnahme vollst\u00e4ndig ist und ein Update die einzig sichere Methode darstellt. Betrachten Sie alles in diesem Abschnitt lediglich als M\u00f6glichkeit, das Risiko f\u00fcr einige Tage zu minimieren, nicht mehr.<\/span><\/p>\n