PHP2Shell: Was PrestaShop-Shops gegen CVE-2026-109618 und CVE-2026-109619 tun sollten, auch wenn kein Upgrade möglich ist

Am 21. Oktober 2026 veröffentlichte das PHP-Projekt eine Notfallversion wegen zweier kritischer Sicherheitslücken in PHP selbst, die inzwischen unter dem Namen PHP2Shell bekannt sind: CVE-2026-109618 und CVE-2026-109619. Beide können es Angreifern ermöglichen, ohne Anmeldung Code auf einem Webserver auszuführen, bei manchen Konfigurationen sogar, bevor eine einzige Zeile Ihres Shop-Codes ausgeführt wurde.

Für die meisten Websites lautet der Rat kurz und knapp: PHP aktualisieren und neu starten. Bei PrestaShop-Shops ist es komplizierter, und genau deshalb haben wir diesen Artikel geschrieben. Jede PrestaShop-Version vor 9.0 unterstützt offiziell höchstens PHP 8.1. Für PHP 8.1 und alle älteren Versionen wurde jedoch keine offizielle bereinigte Version veröffentlicht. Ein großer Teil der PrestaShop-Shops weltweit kann diese Woche also nicht einfach „PHP aktualisieren“.

Dieser Leitfaden erklärt die Sicherheitslücken, zeigt, wie Sie die tatsächliche Gefährdung Ihres Shops feststellen (die Versionsnummer allein reicht dafür nicht), und beschreibt das Vorgehen für jede PrestaShop-Version. Außerdem stellen wir die Übergangslösung vor, die wir bei Shops einsetzen, die sich derzeit nicht upgraden lassen: Wir stellen sie zunächst auf einer Staging-Kopie auf ein vom Anbieter gepatchtes PHP 7.4 um und beheben die dabei auftretenden Code-Probleme. Das ist eine Brücke, kein dauerhaftes Ziel. Es ist aber auch deutlich besser, als den Shop ungeschützt weiterzubetreiben oder abzuschalten.

Was PHP2Shell ist, einfach erklärt

Beide Lücken stecken in der PHP-Engine, also in dem Teil, der eine Webanfrage entgegennimmt und vorbereitet, bevor Ihr Shop-Code startet. Deshalb kann weder ein PrestaShop-Update noch ein Modul oder Theme diese Lücken schließen. Das kann nur eine bereinigte PHP-Version.

Forschende haben außerdem gezeigt, dass Angreifer ohne Anmeldung den Arbeitsspeicher von PHP-Workern auslesen können. Dort können Passwörter, Sitzungstokens und API-Schlüssel aus den Anfragen anderer Besucher liegen. Deshalb ist der Abschnitt zur Bereinigung am Ende dieses Leitfadens auch dann relevant, wenn niemand etwas auf Ihrem Server eingeschleust hat.

Betroffen ist jede PHP-Installation, die Webanfragen verarbeitet: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das PHP-Projekt stuft das Risiko bei mod_php am höchsten ein. Dort hat es einen Exploit demonstriert, der greift, bevor irgendein Anwendungscode ausgeführt wird. Für PrestaShop-Betreiber ist dieses Detail entscheidend: Die Anmeldung im Backoffice, der Wartungsmodus des Shops und sämtliche Sicherheitsmodule werden erst ausgeführt, nachdem PHP die Anfrage bereits geparst hat. Keines davon hält den Angriff auf.

Der Schutz muss vor PHP greifen. Alles innerhalb von PrestaShop läuft erst, wenn der Schaden schon entstanden ist.

Der zeitliche Ablauf

Warum es PrestaShop-Shops schwerer haben

Diese Tabelle zeigt das Problem. Sie stellt die höchste offiziell unterstützte PHP-Version jeder PrestaShop-Versionsreihe laut den PrestaShop-Systemanforderungen der Frage gegenüber, ob dafür eine offizielle bereinigte PHP-Version existiert.

„Nein“ in der dritten Spalte bedeutet nicht, dass es keinen Fix gibt. Es bedeutet, dass der Fix von einer anderen Stelle als php.net kommen muss: von einer Linux-Distribution, vom Anbieter Ihres Hosting-Panels, von einem Anbieter für Langzeitsupport oder aus einer PHP-Version, die Sie mit dem minimalen Backport des PHP-Projekts selbst aus dem Quellcode bauen. Dort müssen die meisten PrestaShop-Shops diese Woche suchen, und dort findet sich auch die gute Nachricht.

Jede Zeile ohne grüne Zelle ist auf einen Backport des Anbieters oder die 7.4-Brücke angewiesen.

Schritt 1: Finden Sie heraus, womit Ihr Shop tatsächlich läuft

Hier lauern zwei Fallen, in die fast jeder tappt.

Die erste Falle: Das PHP, das Sie per SSH sehen, ist nicht unbedingt das PHP, mit dem Ihr Shop läuft. Auf Servern sind häufig mehrere PHP-Versionen parallel installiert. Die Kommandozeile kann eine andere verwenden als der Webserver. Öffnen Sie in PrestaShop Erweiterte Einstellungen > Informationen (Advanced Parameters > Information): Die dort angezeigte PHP-Version verarbeitet tatsächlich die Anfragen Ihres Shops. Die PHP-Einstellung für die Domain in Ihrem Hosting-Panel sollte dieselbe Version nennen.

Die zweite Falle: Die Versionsnummer verrät nicht, ob die Patches installiert sind. Distributionen und Hosting-Anbieter übernehmen Sicherheitskorrekturen als Backports in Ihre bestehende Version und behalten deren alte Nummer bei. Ein „PHP 7.4.33“ kann auf einem Server vollständig bereinigt und auf einem anderen völlig ungeschützt sein. Den Nachweis liefert der Sicherheitshinweis des Anbieters für genau Ihr Paket oder eine schriftliche Antwort Ihres Hosters.

# Optional: some servers advertise their PHP version. This does not prove patch status.
curl -sS -I https://www.example-shop.com/ | grep -i '^X-Powered-By:'

# Supporting evidence from package changelogs. A hit for both CVEs is a good sign.
# No hit proves nothing: some vendors only log a version update. Then ask the vendor.
# Adjust the package name to the PHP version and handler that serves your shop.

# Debian and Ubuntu
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php7.4-fpm/changelog.Debian.gz

# RHEL, AlmaLinux, Rocky and CloudLinux system PHP
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'

# cPanel EasyApache (ea-php) and CloudLinux PHP Selector (alt-php)
rpm -q --changelog ea-php74-php-fpm | grep -E 'CVE-2026-10961[89]'
rpm -q --changelog alt-php74-common | grep -E 'CVE-2026-10961[89]'

Ihr Hoster hat womöglich schon eine gepatchte alte PHP-Version, sogar PHP 5

Das wissen viele Betreiber älterer Shops nicht: Mehrere Hosting-Anbieter liefern eigene Builds alter PHP-Versionen aus und haben auch diese gepatcht:

• CloudLinux PHP Selector (alt-php): Bereinigte Builds für PHP 5.2 bis 5.6, 7.0 bis 7.4 und 8.0 bis 8.5 wurden am 22. Oktober in die Stable-Repositories für CloudLinux 7, 8 und 9 aufgenommen (CloudLinux 10 erhält sie über das Repository von TuxCare).
• CloudLinux-Builds von cPanel PHP (ea-php): von ea-php52 bis ea-php85 gepatcht, unter Beibehaltung der alten Versionsnummern.
• cPanels eigenes EasyApache PHP: offizielle Versionen für 8.2 bis 8.5 und Backports für 8.1 (8.1.34-5), 8.0 (8.0.30-12) und 7.4 (7.4.33-19). cPanels eigene Builds für 7.3 und älter erhielten keinen Fix. Diese Nutzer verweist cPanel an TuxCare.
• Red Hat und seine Rebuilds: Die Fixes werden nach und nach für die einzelnen Streams veröffentlicht. Prüfen Sie die Errata für genau den PHP-Stream, der auf Ihrem Server aktiviert ist. Gehen Sie nicht davon aus, dass ein einfaches Systemupdate ausgereicht hat: Frühe Meldungen führten einige Streams als bereinigt auf, während andere noch warteten.
• TuxCare Endless Lifecycle Support: kostenpflichtiger Langzeitsupport mit Patches für PHP-Versionen, deren regulärer Support beendet ist.

Die gleiche Bezeichnung „PHP 7.1“ im Hosting-Panel kann bei einem Hoster also eine gepatchte und beim nächsten eine verwundbare Version meinen. Bevor Sie Arbeiten am Code planen, stellen Sie Ihrem Hoster eine präzise Frage. Diese Nachricht können Sie direkt übernehmen:

Betreff: PHP2Shell (CVE-2026-109618, CVE-2026-109619) in meinem Hosting-Konto

Guten Tag,
mein Shop läuft auf Ihren Servern mit PHP X.Y (Handler: PHP-FPM / mod_php / LiteSpeed).
Enthält der PHP-Build, der meine Website bedient, die Korrekturen für
CVE-2026-109618 und CVE-2026-109619? Bitte nennen Sie mir die genaue Paketversion
und bestätigen Sie, ob die PHP-Prozesse seit der Installation neu gestartet wurden.
Falls es für meine Version keinen Fix gibt: Auf welche gepatchten PHP-Versionen
kann ich in meinem Tarif umstellen?
Vielen Dank.

Lautet die Antwort „Ja, beide Lücken sind geschlossen und die Prozesse wurden neu gestartet“, ist der dringende Teil erledigt, ohne eine Zeile Code anzufassen. Lesen Sie den Abschnitt zur Untersuchung einer möglichen Kompromittierung und planen Sie Ihr Upgrade anschließend in Ruhe.

Schritt 2: Wählen Sie den Weg für Ihre PrestaShop-Version

Unabhängig von Ihrer Version ist die erste Wahl immer dieselbe: ein bereinigtes Paket für den PHP-Versionszweig, auf dem Ihr Shop bereits läuft. Der Wechsel zu einem anderen PHP-Versionszweig ist ein größerer Schritt. Er führt immer zuerst über eine Staging-Kopie, auf der Sie Ihre Module, Overrides und den Bestellprozess testen.

Fragen Sie Ihren Hoster, bevor Sie Code-Arbeiten planen: Am günstigsten ist ein gepatchter Build, der Ihnen bereits zur Verfügung steht.

PrestaShop 9

Aktualisieren Sie auf die bereinigte Version Ihres Zweigs: 8.2.35, 8.3.36 oder 8.4.27, bei 9.1 auch 8.5.12. Starten Sie PHP neu und kontrollieren Sie die Version auf der Seite Informationen. Läuft Ihr 9.0-Shop noch mit PHP 8.1, ist der Umstieg auf 8.2 oder neuer ein Wechsel des Versionszweigs: Testen Sie ihn zuerst auf Staging oder verwenden Sie vorübergehend eine vom Anbieter gepatchte 8.1-Version.

PrestaShop 8.0 bis 8.2

Diese Versionen unterstützen offiziell PHP 7.2 bis 8.1, und für keine davon gibt es eine bereinigte Veröffentlichung von php.net. Dennoch bieten die Anbieter mehr Möglichkeiten, als es zunächst scheint: eine gepatchte 8.1-Version (cPanels 8.1.34-5, CloudLinux alt-php81, das php8.1-Paket von Ubuntu 22.04, TuxCare), aber auch gepatchtes PHP 8.0 oder 7.4 derselben Anbieter. Alle liegen im offiziell unterstützten Bereich von PrestaShop 8. Steht Ihnen nirgends ein gepatchter Build zur Verfügung, ist ein Upgrade auf PrestaShop 9 die dauerhafte Lösung. Setzen Sie die unten beschriebenen vorübergehenden Maßnahmen um, bis eine bereinigte Laufzeitumgebung verfügbar ist.

PrestaShop 1.7.8

PHP 7.4 ist hier die offizielle Obergrenze, und gepatchte 7.4-Builds sind relativ leicht zu finden: cPanel 7.4.33-19, CloudLinux alt-php74, TuxCare und Distributionspakete, sofern Ihr Anbieter sie veröffentlicht hat. Läuft Ihr Shop mit einer älteren PHP-Version, bleibt der Wechsel auf ein gepatchtes PHP 7.4 innerhalb des offiziell unterstützten Bereichs von 1.7.8. Testen Sie ihn trotzdem auf Staging.

PrestaShop 1.6.1.x und 1.7.0 bis 1.7.7

Bei diesen Versionen liegt die offizielle Grenze bei PHP 7.1, 7.2 oder 7.3. Fragen Sie Ihren Hoster zuerst, ob es für Ihre aktuelle Version einen gepatchten Build gibt (siehe oben). Falls ja, wechseln Sie darauf, und der dringende Teil ist erledigt. Falls nicht, kommt unsere Übergangslösung ins Spiel.

Unsere Übergangslösung: eine Brücke mit gepatchtem PHP 7.4

So gehen wir tatsächlich bei den von uns betreuten Shops vor, die sich diesen Monat nicht upgraden lassen. Die Idee: Der Shop läuft mit einer PHP-7.4-Version, die ein Anbieter weiterhin mit Patches versorgt, obwohl seine PrestaShop-Version offiziell nur ältere PHP-Versionen unterstützt. Die Code-Stellen, die damit nicht zurechtkommen, beheben wir. Unserer Erfahrung nach erzeugt der Core von PrestaShop 1.6.1 und 1.7 unter 7.4 überwiegend Notices und Deprecation-Meldungen, keine fatalen Fehler. Was wirklich ausfällt, sind meist einige alte Module und Overrides. Es ist eine Übergangslösung, und das benennen wir klar: Sie bewegen sich eine Zeit lang außerhalb der offiziellen Support-Matrix von PrestaShop. Dafür schließt sie die Lücke, und Ihr Shop kann weiter verkaufen, während Sie das eigentliche Upgrade planen.

Eine Brücke, kein dauerhaftes Ziel: Sie schließt die Lücke und hält den Shop bis zum eigentlichen Upgrade im Verkauf.

Ein konkretes Beispiel dafür, warum 7.4 funktioniert, wo PHP 8 scheitern würde: Die mit PrestaShop 1.6.1.23 ausgelieferte Datei Cookie.php enthält $this->_path{0}. Unter PHP 7.4 gilt diese Syntax mit geschweiften Klammern lediglich als veraltet. Unter PHP 8.0 führt sie zu einem fatalen Fehler. Diese eine Zeile entscheidet darüber, ob die Brücke trägt oder der Shop gar nicht mehr lädt.

1. Erstellen Sie eine Staging-Kopie und sichern Sie sie ab

Kopieren Sie Dateien und Datenbank an einen separaten Ort, etwa auf eine passwortgeschützte Subdomain. Bevor die Kopie auch nur eine einzige Anfrage beantwortet, gehen Sie so vor:

• Verbinden Sie sie mit ihrer eigenen Datenbank. Die kopierte Konfiguration enthält noch die Zugangsdaten der Live-Datenbank (config/settings.inc.php bei 1.6, app/config/parameters.php bei 1.7). Ersetzen Sie diese durch die Zugangsdaten der Staging-Datenbank, idealerweise mit einem Datenbankbenutzer, der keinen Zugriff auf das Produktivsystem hat. Alle folgenden Schritte setzen voraus, dass Sie dies zuerst erledigt haben.
• Unterbinden Sie ausgehende Verbindungen. Bevor die Kopie ihre erste Anfrage beantwortet oder einen Job ausführt, sperren Sie auf Serverebene, unabhängig von PrestaShop, ausgehende E-Mails und Verbindungen zu Ihren Live-Diensten (Zahlungs-, Versanddienstleister- und Marktplatz-APIs). Erlauben Sie nur die Sandbox-Dienste, die Sie testen möchten. PrestaShop-Einstellungen allein reichen nicht aus: Manche Module versenden E-Mails oder kommunizieren mit Marktplätzen über eigene Verbindungen. Deaktivieren Sie anschließend die kopierten Cronjobs und schalten Sie jedes Zahlungsmodul in den Test- oder Sandbox-Modus.
• Halten Sie Besucher und Suchmaschinen fern, indem Sie auf dem Webserver einen Passwortschutz einrichten.

Führen Sie dann ausschließlich in der Staging-Datenbank Folgendes aus:

-- STAGING DATABASE ONLY. Replace ps_ with your table prefix.
-- 1. PrestaShop itself never sends email from this copy
UPDATE ps_configuration SET value = '3' WHERE name = 'PS_MAIL_METHOD';

-- 2. Point the copy at its own address (single shop, installed at the domain root)
SELECT id_shop_url, id_shop, domain, domain_ssl, physical_uri FROM ps_shop_url;
UPDATE ps_shop_url
SET domain = 'staging.example-shop.com', domain_ssl = 'staging.example-shop.com', physical_uri = '/'
WHERE id_shop_url = 1;
UPDATE ps_configuration SET value = 'staging.example-shop.com'
WHERE name IN ('PS_SHOP_DOMAIN', 'PS_SHOP_DOMAIN_SSL');

Ordnen Sie bei einer Multistore-Installation jede Shop-URL einzeln zu, statt das Beispiel für einen einzelnen Shop zu verwenden.

2. Stellen Sie die Kopie auf gepatchtes PHP 7.4 um und erfassen Sie alle Fehler

Wählen Sie in Ihrem Hosting-Panel das gepatchte PHP 7.4 für die Staging-Website. Setzen Sie error_reporting auf E_ALL, protokollieren Sie Fehler in einer Datei und lassen Sie sie nicht auf der Seite anzeigen. Prüfen Sie, ob tatsächlich Einträge im Protokoll ankommen, und sortieren Sie die Fehler anschließend nach Häufigkeit, die häufigsten zuerst:

# Rank PHP errors on staging, most frequent first (standard PHP log format)
grep -E 'PHP (Fatal error|Parse error|Recoverable fatal error|Warning|Notice|Deprecated):' /path/to/php-error.log \
  | sed -E 's/^\[[^]]*\] //' | sort | uniq -c | sort -rn | head -40

3. Prüfen Sie den Code an den typischen Problemstellen

Bevor Sie sich durch den Shop klicken, zeigt eine kurze statische Suche in Modulen, Overrides und Theme die üblichen Verdächtigen. Diese Prüfliste ist nicht vollständig: Sie übersieht indirekte Aufrufe, über mehrere Zeilen verteilte Aufrufe und manche Zugriffe mit geschweiften Klammern. Ein leeres Ergebnis belegt deshalb keine Kompatibilität. Prüfen Sie jeden Treffer.

# Functions that PHP 7.x removed or deprecated
grep -rnE --include='*.php' \
  '\beach\s*\(|create_function\s*\(|get_magic_quotes_(gpc|runtime)\s*\(|\bmysql_[a-z_]+\s*\(|\beregi?(_replace)?\s*\(|\bsplit\s*\(|mcrypt_[a-z_]+\s*\(' \
  modules override themes

# preg_replace calls: check each one for the removed /e modifier
grep -rnE --include='*.php' '\bpreg_replace\s*\(' modules override themes

# String offsets with curly braces ($str{0}), deprecated in PHP 7.4
grep -rnE --include='*.php' '\$[A-Za-z_][A-Za-z0-9_]*\{[^}$]*\}' modules override themes

# Syntax check of every PHP file with the target PHP binary, from the staging root
# (its name varies: php7.4, php74, /opt/cpanel/ea-php74/root/usr/bin/php ...)
find . -type f -name '*.php' -exec php7.4 -l {} \; | grep -v '^No syntax errors'

Eine fehlerfreie Syntaxprüfung belegt nur, dass sich die Dateien parsen lassen. Sie sagt nichts über fehlende Erweiterungen oder das Verhalten im Bestellprozess aus. Dafür ist Schritt 5 da.

4. Beheben Sie die Probleme, mit der kleinsten Änderung zuerst

Diese Probleme begegnen uns am häufigsten, wenn ein alter Shop auf PHP 7.4 wechselt. Daneben steht jeweils die passende Korrektur:

Beheben Sie zuerst fatale Fehler, dann Warnungen im Bestellprozess und anschließend den Rest. Notices und Deprecation-Meldungen sind nicht harmlos, nur weil Besucher sie nie sehen: Der eigene Error-Handler eines Moduls kann daraus Exceptions machen, und eine Flut solcher Meldungen kann die Festplatte füllen. Gibt es ein Update vom Modulautor, ziehen Sie es einem eigenen Patch vor. Halten Sie außerdem schriftlich fest, welche Dateien Sie ändern: Diese Liste brauchen Sie für die Live-Umstellung und später erneut beim eigentlichen Upgrade. Wenn Sie ohnehin an der Konfiguration arbeiten, entfernen Sie die php_value- und php_flag-Zeilen in .htaccess für Einstellungen, die PHP nicht mehr kennt. Der PHP-Sicherheitshinweis fordert ausdrücklich dazu auf, ungültige oder veraltete Einstellungen auf Anfrageebene zu entfernen.

<?php
// config/defines_custom.inc.php (PrestaShop 1.6 includes this file automatically)
// PHP 7.2+ ships without mcrypt, but the 1.6.1 cookie signature still reads this
// constant. Same value as the mcrypt extension defined, so existing cookies stay valid.
if (!defined('MCRYPT_RIJNDAEL_128')) {
    define('MCRYPT_RIJNDAEL_128', 'rijndael-128');
}

Dieser Code ist gemeint, unverändert aus PrestaShop 1.6.1.23 (classes/Rijndael.php):

// PrestaShop 1.6.1.23, classes/Rijndael.php
protected function generateHmac($encrypted)
{
    $macKey = $this->generateKeygenS2k('sha256', $this->_key, $this->_iv, 32);
    return hash_hmac(
        'sha256',
        $this->_iv . MCRYPT_RIJNDAEL_128 . $encrypted,
        $macKey
    );
}

5. Testen Sie alle geschäftsrelevanten Abläufe und stellen Sie dann mit den Korrekturen um

Gehen Sie auf Staging alles durch, was Umsatz bringt oder Arbeit auslöst: Startseite, Kategorieseiten mit Filtern, Suche, Produktseiten mit Varianten, Warenkorb, Bestellprozess mit jedem Versanddienstleister und jeder Zahlungsart im Testmodus, Bestellbestätigung, Bestellseite im Backoffice, Rechnungs- und Lieferschein-PDFs, die Konfigurationsseite jedes Moduls, Importe und die Cron-URLs.

Bleibt das Protokoll ruhig, planen Sie die Live-Umstellung für eine umsatzschwache Stunde:

• Erstellen Sie ein Backup, dessen Wiederherstellung Sie tatsächlich schon einmal durchgeführt haben, von Dateien und Datenbank.
• Übertragen Sie die getesteten Code-Korrekturen und stellen Sie PHP im selben Schritt um. Die Korrekturen liegen nur auf Staging, bis Sie sie übertragen. Überschreiben Sie niemals die Live-Datenbank mit der Staging-Datenbank.
• Prüfen Sie sofort den Bestellprozess und beobachten Sie anschließend 48 Stunden lang das Fehlerprotokoll.
• Falls Sie zurückwechseln müssen auf die alte, ungepatchte PHP-Version, beschränken Sie währenddessen den Zugriff auf den Shop. Halten Sie diese Beschränkung aufrecht, bis wieder eine bereinigte Laufzeitumgebung läuft.

Bis die Patches installiert sind: vorübergehende Maßnahmen

Das PHP-Projekt hat Maßnahmen veröffentlicht, die das Risiko durch bestimmte Angriffswege verringern. Nach eigener Aussage machen sie eine Installation nicht sicher. Nur ein Update schließt die Lücken vollständig. Auch eine sichere Wartefrist verschaffen diese Maßnahmen nicht. Dennoch lohnt es sich, sie für die Stunden oder Tage umzusetzen, bis Ihr Shop mit einer bereinigten PHP-Version läuft. So wenden Sie sie auf einen PrestaShop-Shop an.

PHP-Einstellungen

Diese Einstellungen müssen in php.ini, im PHP-FPM-Pool oder in der Serverkonfiguration gesetzt werden, nicht in .user.ini und nicht mit ini_set(). Starten Sie anschließend jeden PHP-Worker neu.

; Temporary PHP2Shell measures in php.ini (restart PHP afterwards)
; PrestaShop's core does not use upload progress tracking, so this is safe to switch off
session.upload_progress.enabled = 0
; Smaller request bodies. Example values: use your shop's real needs,
; and never raise a lower limit you already have
post_max_size = 32M
upload_max_filesize = 24M
max_file_uploads = 10

; In a PHP-FPM pool file (for example /etc/php/7.4/fpm/pool.d/shop.conf) the same
; settings look like this; remove the leading semicolons to activate them:
; php_admin_flag[session.upload_progress.enabled] = off
; php_admin_value[post_max_size] = 32M
; php_admin_value[upload_max_filesize] = 24M

Testen Sie nach der Änderung der Limits die Uploads, die Ihr Team tatsächlich nutzt: Ein großes Modularchiv oder ein großes Produktbild kann die Grenzen überschreiten. Die offizielle Liste empfiehlt gegen die Out-of-Memory-Lücke außerdem memory_limit = -1, so durchgesetzt, dass keine Anwendungseinstellung wieder ein Limit setzen kann. Damit kann eine einzelne Anfrage den gesamten Arbeitsspeicher des Servers belegen. Diese Maßnahme eignet sich daher nur für Administratoren, die PHP durch ein Speicherlimit auf Container- oder cgroup-Ebene begrenzen können und wissen, was beim Erreichen dieser Grenze passiert. Sie schließt die Lücke nicht vollständig. Zudem warnt der Sicherheitshinweis davor, stattdessen RLIMIT_AS oder RLIMIT_DATA zu verwenden. Überlassen Sie dies beim Shared Hosting Ihrem Hoster. Für PHP 8.5 nennt der Sicherheitshinweis außerdem fatal_error_backtraces = 0.

Lehnen Sie Uploads dort ab, wo der Shop sie nicht braucht

Der bekannte Exploit kommt als multipart/form-data-Anfrage, also in dem Format, das Browser für Datei-Uploads verwenden. Die meisten Bereiche des PrestaShop-Frontoffice benötigen es nie. Eine Sperre außerhalb des Backoffice unterbricht diesen bekannten Angriffsweg. Was dadurch nicht mehr funktioniert: Dateianhänge im Kontaktformular, Dateifelder bei der Produktanpassung und alle Module, mit denen Kunden Dateien hochladen können. Für die meisten Shops ist das für einige Tage ein vertretbarer Kompromiss.

Eine Voraussetzung vorweg: Die Ausnahme für das Backoffice ist nur sinnvoll, wenn der Zugriff darauf auf Webserver-Ebene auf Ihre eigenen IP-Adressen beschränkt ist. Anfragen von allen anderen Adressen dürfen PHP gar nicht erst erreichen. Eine PrestaShop-Anmeldeseite schützt nicht vor einer Lücke, die greift, bevor PrestaShop läuft. Unser Artikel zur Backoffice-Sicherheit enthält fertige IP-Freigabelisten für Apache und nginx. Können Sie das Backoffice nicht entsprechend absichern, lassen Sie die Ausnahme weg und setzen Sie auch Backoffice-Uploads für einige Tage aus.

Setzen Sie diese Regeln bei Apache ganz an den Anfang der .htaccess Ihres Shops, oberhalb der Zeile # ~~start~~. So bleiben sie erhalten, wenn PrestaShop die Datei neu erzeugt. Ersetzen Sie admin-folder-name durch Ihren Backoffice-Ordner:

# Temporary PHP2Shell measure: refuse multipart requests outside the back office.
# Remove after patching.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteCond %{REQUEST_URI} !^/admin-folder-name/
RewriteRule ^ - [F]
</IfModule>

Die Regel funktioniert nur, wenn mod_rewrite aktiv ist und in .htaccess-Dateien verwendet werden darf. Testen Sie sie deshalb: Ein harmloser Upload über das Kontaktformular sollte jetzt eine 403-Fehlerseite auslösen. Diese Fehlerseite darf selbst kein PHP-Skript sein.

Bei nginx gehört dies in den server-Block Ihres Shops:

# Temporary PHP2Shell measure: refuse multipart requests outside the back office.
set $block_multipart 0;
if ($http_content_type ~* "multipart/form-data") { set $block_multipart 1; }
if ($uri ~ "^/admin-folder-name/") { set $block_multipart 0; }
if ($block_multipart) { return 403; }

Verwenden Sie wie oben $uri, den normalisierten Pfad. Die unverarbeitete Variable $request_uri ließe sich mit einem Pfad wie /admin-folder-name/../index.php austricksen.

Der Schutz vor Ihrem Shop

• Cloudflare hat WAF-Regeln für die bekannten Angriffswege aktiviert, auch für kostenlose Tarife. Sie helfen nur, wenn der gesamte Datenverkehr zu Ihrem Shop tatsächlich über Cloudflare läuft und niemand Ihren Server direkt erreichen kann. Prüfen Sie bei kostenpflichtigen Tarifen außerdem, ob die verwalteten Regeln auf Blockieren eingestellt sind. Berichten zufolge suchen Angreifer nach Wegen, die Regeln zu umgehen.
• Imunify360, das häufig beim Shared Hosting eingesetzt wird, hat Regeln veröffentlicht, die das öffentliche Exploit-Tool und Varianten von CVE-2026-109619 blockieren. Laut CloudLinux decken diese Regeln CVE-2026-109618 noch nicht ab. Andere Firewalls haben jeweils eine eigene, abweichende Abdeckung.
• Der Wartungsmodus hilft nicht. PrestaShop entscheidet erst dann, die Wartungsseite anzuzeigen, wenn PHP die Anfrage bereits verarbeitet hat. Kann Ihr Hoster nicht zeitnah patchen, fragen Sie, ob er verhindern kann, dass nicht vertrauenswürdige Anfragen PHP überhaupt erreichen.

Nach dem Patchen: eine mögliche Kompromittierung untersuchen

Schon vor der Offenlegung wurden Versuche beobachtet. Die Lücke zum Auslesen des Arbeitsspeichers kann zudem Geheimnisse preisgeben, ohne Spuren in Ihrem Shop zu hinterlassen. War Ihr Shop nach Mitte Oktober mit ungepatchtem PHP im Internet erreichbar, nehmen Sie sich eine Stunde für diese Prüfungen. Sie finden damit typische Spuren. Ein unauffälliges Ergebnis beweist jedoch nicht, dass nichts passiert ist.

# Executable files in folders that should hold images and uploads.
# PrestaShop ships an index.php in nearly every folder: compare those with a clean copy too.
find img upload download -type f \( -iname '*.php' -o -iname '*.phtml' -o -iname '*.phar' \)

# Files changed since the first exploitation attempts (17 October 2026), caches included.
# Leads only: timestamps can be faked. Read the whole list.
find . -type f -newermt '2026-10-17 00:00:00 UTC'

-- Back-office accounts, newest first. Anything you do not recognise?
SELECT id_employee, firstname, lastname, email, active, last_connection_date
FROM ps_employee
ORDER BY id_employee DESC;

Am zuverlässigsten ist der Vergleich mit einer sauberen Kopie Ihrer PrestaShop-Version, Ihrer Module und einem Backup von vor dem 17. Oktober. Beziehen Sie JavaScript-Dateien ein, denn dort verstecken sich eingeschleuste Payment-Skimmer zum Abgreifen von Zahlungsdaten. Wenn Sie etwas finden, sichern Sie die Beweise und dämmen Sie den Angriff ein, bevor Sie ein Passwort ändern. Sonst werden die neuen Zugangsdaten auf demselben Weg ausgelesen.

Ersetzen Sie anschließend von einem vertrauenswürdigen Gerät aus die Geheimnisse, die durch das Speicherleck offengelegt worden sein könnten: sämtliche Backoffice-Passwörter, API-Schlüssel der Zahlungs-, Versanddienstleister- und Marktplatzmodule, Webservice-Schlüssel und SMTP-Passwörter. Ändern Sie das Datenbankpasswort gleichzeitig auf dem Datenbankserver und in der Shop-Konfiguration (config/settings.inc.php bei 1.6, app/config/parameters.php ab 1.7) sowie überall sonst, wo es für Verbindungen verwendet wird. Andernfalls fällt der Shop aus.

Häufig gestellte Fragen

Quellen

• PHP-Projekt: Sicherheitshinweis und Versionsankündigungen, mit den Sicherheitshinweisen GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp
• PrestaShop: Systemanforderungen für 1.6 und 1.7, 8 und 9
• CloudLinux: Abdeckung für PHP2Shell und Paketstatus
• Sansec: PHP2Shell-Analyse für den E-Commerce