PrestaShop 9.2.1 und 8.2.9 beheben PHP-Objekt-Injection ohne Authentifizierung und weitere schwerwiegende Schwachstellen

Was passiert ist

Am 9. November 2026 veröffentlichte PrestaShop zehn Sicherheitshinweise mit hohem Schweregrad. Der schwerwiegendste ist GHSA-h2q4-7fp7-m5jp: Wenn der Install-Ordner weiterhin erreichbar ist, kann ein nicht authentifizierter Angreifer das Sitzungscookie des Installers fälschen und eine PHP-Objekt-Injection auslösen, um eine Remotecodeausführung mit den Rechten des Webserver-Benutzers zu erzielen. Eine verwandte Installer-Schwachstelle, GHSA-8rxw-79mh-gmm5, ermöglicht es einem nicht authentifizierten Besucher, den Installer erneut auszuführen, die live verwendeten Datenbank-Zugangsdaten auszulesen, die Konfigurationsdatei des Shops zu überschreiben oder die Datenbank mit einem vom Angreifer gewählten Administratorkonto neu zu installieren.

Mehrere Schwachstellen betreffen die Webservice- und Admin-API. GHSA-3f36-4qv4-vfgh ermöglicht es einem auf einen Shop beschränkten Webservice-Schlüssel, in jedem Shop Aktionen auszuführen; GHSA-hjwq-7qvv-qxj4 erlaubt es einem Schlüssel, der einem Shop zugeordnet ist, Kundendatensätze einschließlich Passwort-Hashes in jedem Shop zu lesen und zu verändern. GHSA-wrmc-gmx5-9hhc ermöglicht bei Anhängen eine Pfad-Traversal-Schwachstelle zum Lesen und Löschen von Dateien außerhalb des Download-Verzeichnisses; der Download ist für jedermann erreichbar. Ein Admin-API-Client mit api_client_write kann sich selbst jeden installierten Scope gewähren (GHSA-p292-3rh4-vm4p), was zum Hochladen von Modulen und zur Codeausführung führen kann.

Zu den Schwachstellen im Back-Office zählen gespeichertes Cross-Site-Scripting über hochgeladene SVG-Dateien sowie beliebiges Schreiben von Dateien über E-Mail-Übersetzungen, was zu Remotecodeausführung führen kann. Zwei Race-Conditions ermöglichen doppelte Bestellungen aus einem einzelnen Warenkorb und die Umgehung der Nutzungsgrenzen von Warenkorb-Regeln. PrestaShop hat keine dieser Schwachstellen als in freier Wildbahn ausgenutzt gemeldet, und keine wurde vor den Sicherheitshinweisen öffentlich bekanntgegeben.

Wer betroffen ist

PrestaShop 9.0.0 bis vor 9.2.1 und 8.0.0 bis vor 8.2.9 sind von der Mehrzahl dieser Sicherheitshinweise betroffen. GHSA-p292-3rh4-vm4p betrifft nur 9.0.0 bis vor 9.2.1. GHSA-8rxw-79mh-gmm5 nennt Versionen vor 8.2.9 sowie 9.0.0 bis vor 9.2.1; seit 9.2.0 wird der Install-Ordner nach erfolgreicher Installation automatisch entfernt, daher besteht das Risiko vor allem dort, wo dieses Entfernen fehlschlug, sowie bei 8.x-Shops, in denen der Ordner nicht manuell gelöscht wurde.

Was jetzt zu tun ist

1. Spielen Sie die korrigierten Versionen ein: PrestaShop 9.2.1 für Shops im 9.x-Zweig oder PrestaShop 8.2.9 für Shops mit älteren 8.x-Versionen. GHSA-p292-3rh4-vm4p wird nur in 9.2.1 behoben.
2. Löschen Sie den Install-Ordner vom Server, sobald der Shop installiert ist. Ist er noch vorhanden, tun Sie dies sofort; das entschärft die beiden Installer-Schwachstellen ohne Authentifizierung.
3. Überprüfen Sie die Webservice-API. Deaktivieren Sie sie, wenn sie nicht verwendet wird. Behandeln Sie bis zum Update jeden auf einen Shop beschränkten Schlüssel als für jeden Shop gültig; erteilen Sie nicht vertrauenswürdigen Schlüsseln keine Schreibberechtigung für Anhänge; gewähren Sie Berechtigungen für Kundendaten nur vollständig vertrauenswürdigen Integrationen.
4. Überprüfen Sie Admin-API-Clients mit api_client_write. Behalten Sie diesen Berechtigungsumfang nur bei Clients, denen sämtliche installierten Berechtigungsumfänge anvertraut werden können, und löschen Sie nicht benötigte API-Clients.
5. Schränken Sie die Back-Office-Berechtigungen ein: Dateimanager- und Logo-Upload-Rechte sollten nur vollständig vertrauenswürdigen Mitarbeitenden eingeräumt werden; die Berechtigung zum Bearbeiten von Übersetzungen sollte ebenso eingeschränkt werden.
6. Für die beiden Race-Conditions im Checkout gibt es keine Problemumgehung; das Update ist die einzige Gegenmaßnahme.

Wie man es erkennt

Prüfen Sie, ob der Install-Ordner in Ihrem Shop erreichbar ist; entfernen Sie ihn in jedem Fall. Überprüfen Sie die Webservice- und Admin-API-Client-Scopes auf Schlüssel mit mehr Berechtigungen als nötig, und auditieren Sie Back-Office-Konten, die Dateien hochladen oder Übersetzungen bearbeiten können. Achten Sie beim Pfad-Traversal über E-Mail-Übersetzungen auf unerwartete Dateien in Verzeichnissen, die für den Webserver-Benutzer beschreibbar sind.

Über den Patch hinaus

Diese Sicherheitshinweise zeigen, wie selbst gehosteter E-Commerce mehr Angriffsfläche bieten kann als die Storefront selbst: ein zurückgebliebener Install-Ordner, übermäßig berechtigte API-Schlüssel und Race-Conditions in der Checkout-Logik. Die schwerwiegendsten Schwachstellen sind ohne Anmeldedaten über das Netzwerk erreichbar, wenn ein Install-Ordner verbleibt; mit Virtual CISO Services (vCISO) unterstützen wir Sie dabei, genau diese Risiken zu finden. Mit Implementierungs- & Bewertungsleistungen lassen sich Injection-, Deserialisierungs- und Authentifizierungsschwachstellen testen, bevor daraus ein Sicherheitshinweis wird. Wurde eine dieser Schwachstellen ausgenutzt, erkennt Managed Detection & Response (MDR) die daraus folgende Codeausführung und den Missbrauch von Berechtigungen.