Shopware: Passwort-Ruecksetzlink der Administration folgt dem Host-Header

Der Link in der echten Ruecksetzmail entsteht aus dem Host der Anfrage, den ein anonymer Aufrufer frei setzt.

Advisory-ID: TP-2026-095
Produkt: Shopware (E-Commerce-Plattform, Symfony und PHP)
Schwachstellentyp: Schwacher Passwort-Wiederherstellungsmechanismus (CWE-640)
CVE: beantragt (GitHub CNA), Vergabe ausstehend
CVSS 3.1: 9.3 (Kritisch) · CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N
Betroffene Versionen: <= 6.6.10.22 sowie 6.7.0.0 bis 6.7.13.0
Hersteller-Advisory: GHSA-xj2c-8fw5-mr6m
Behoben in: 6.6.10.23 und 6.7.13.1
Gemeldet: 10. Juli 2026

Zusammenfassung

Die Administration von Shopware bietet eine Passwort-Wiederherstellung, die den Ruecksetzlink per Mail schickt. Der Host in diesem Link stammt aus der eingehenden HTTP-Anfrage und wird nicht gegen eine Liste zulaessiger Namen geprueft. Der ausloesende Endpunkt verlangt keine Anmeldung, weshalb ein beliebiger Angreifer mit gesetztem Host-Header eine Ruecksetzmail an eine bekannte Administrator-Adresse ausloest. Die Mail ist echt, kommt von der richtigen Shopware-Instanz und traegt deren Gestaltung, nur zeigt ihr Link auf die Domaene des Angreifers. Oeffnet die Administration den Link, uebergibt sie den Ruecksetz-Hash an den Angreifer, der damit das Passwort setzt und vollen Zugriff auf die Administration erhaelt.

Ursache

UserRecoveryService baut die Ruecksetz-URL ueber den Symfony-Router zusammen und haengt den Hash an (Core/System/User/Recovery/UserRecoveryService.php:84 und :90). Den Host des RequestContext fuellt Symfony aus der eingehenden Anfrage, und Shopware legt weder default_uri noch request_context.host fest. Die mitgelieferte Konfiguration setzt framework.router.trusted_hosts: ~ und laesst damit jeden Host zu (src/Core/Framework/Resources/config/packages/framework.yaml:13). Der ausloesende Endpunkt POST /api/_action/user/user-recovery traegt auth_required => false und ist damit vollstaendig anonym erreichbar (Core/System/User/Api/UserRecoveryController.php:27). Der Ruecksetzpfad fuer Kunden im Storefront ist nicht betroffen, weil er die geprueften Domaenen des Verkaufskanals verwendet; nur der Weg der Administration leitet den Host aus der Anfrage ab.

Proof of Concept

# 1. Anonym, mit gesetztem Host-Header:
POST /api/_action/user/user-recovery
Host: angreifer.example
{"email": "<adresse der administration>"}
-> 200

# 2. Shopware verschickt eine echte Ruecksetzmail an die Administration:
#    http://angreifer.example/admin#/login/user-recovery/<hash>

# 3. Oeffnet die Administration den Link, erreicht der Hash den Angreifer.
#    Anonym das Passwort setzen:
PATCH /api/_action/user/user-recovery/password
{"hash": "<hash>", "password": "...", "passwordConfirm": "..."}

Die Abhilfe ohne Aktualisierung besteht darin, die Pruefung vertrauenswuerdiger Hosts in Symfony zu aktivieren oder den Webserver so einzustellen, dass er unerwartete Host-Header ablehnt.

Auswirkung

  • Uebernahme eines Administrationskontos durch einen anonymen Angreifer, der lediglich die zugehoerige Mail-Adresse kennen muss.
  • Deutlich hoehere Erfolgsaussicht als bei Phishing, weil die Mail echt ist, von der richtigen Instanz stammt und im erwarteten Ablauf eintrifft.
  • Voller Zugriff auf die Administration des Shops nach der Uebernahme, einschliesslich Bestell- und Kundendaten.
  • Betroffen sind Installationen, die den Host der Anfrage durchreichen, was das offizielle Abbild und die uebliche Einstellung vieler Reverse-Proxies tun.

Referenzen

Steckt so etwas in Ihrer Software?

Diese Schwachstelle hat unser Team im Rahmen seiner Arbeit gefunden. Lassen Sie Ihre Anwendungen von denselben Spezialisten prüfen, mit einem Penetrationstest von turingpoint.

Pentest anfragen