CVE-2024-34716

What it actually does

CVE-2024-34716 is a stored cross-site scripting vulnerability in PrestaShop 8.1.0 through versions before 8.1.6 when the customer-thread feature flag is enabled. An unauthenticated attacker can submit a malicious attachment through the front-office contact form; when an administrator opens that attachment in the back office, attacker-controlled JavaScript executes in the administrator’s authenticated browser context. Because the script can access the administrator session context and PrestaShop security token, it can perform authenticated administrative actions within that administrator’s permissions, potentially resulting in full store compromise, data theft, payment or configuration tampering, malicious module installation, or persistent back-office access.

Why it matters to the business

A successful attack can allow a remote attacker to take over sensitive e-commerce administration functions after tricking or waiting for an administrator to open a malicious customer-service attachment. For an online store, this can lead to customer data exposure, order manipulation, fraudulent refunds or payment redirection, storefront defacement, malware or skimmer injection, loss of customer trust, and operational disruption. The CVSS score is critical and the EPSS score is elevated, indicating meaningful exploitation likelihood even though it is not currently listed in CISA KEV and no named ransomware use is reported. Stores running affected PrestaShop 8.1.x versions with the customer-thread feature enabled should treat remediation as urgent.

How an attack unfolds

An attacker visits the public PrestaShop contact form and submits a customer-thread message with an attachment that contains executable HTML or JavaScript content designed to run when rendered or opened by an administrator in the back office. The attacker does not need an account or prior privileges. Later, an administrator reviews the customer-service thread and opens the attachment. The malicious script executes under the trusted back-office origin in the administrator’s browser, allowing it to read security tokens or use the active administrator session to issue authenticated requests. From there, the script can make administrative changes such as creating or modifying users, changing store settings, installing or configuring modules, altering templates, injecting persistent scripts, or accessing order and customer information, depending on the administrator’s privileges.

How to fix it

Upgrade affected PrestaShop installations to version 8.1.6 or later. For source-based deployments, ensure the fix corresponding to commit 1f94ac86408b0946bc140b3c054fad07213f0254 is present. If immediate upgrade is not possible, disable the customer-thread feature flag as the documented workaround. Additionally, restrict contact-form attachment types to non-executable formats, force downloads instead of inline rendering for user-supplied files, validate file MIME type and extension server-side, and prevent uploaded content from being served in an executable browser context. After remediation, invalidate active administrator sessions, rotate credentials for privileged accounts if compromise is suspected, and audit recent administrative changes made after customer-service attachments were opened.

How to confirm the fix worked

Confirm the deployed PrestaShop version is 8.1.6 or later, or verify that the source tree contains commit 1f94ac86408b0946bc140b3c054fad07213f0254. Confirm the customer-thread feature flag is disabled if the environment has not yet been upgraded. Review the contact form behavior to ensure potentially active content uploaded by users is rejected, sanitized, or served only as a safe download with a non-executable content type. Perform a controlled test in a non-production environment by uploading a benign proof-of-concept attachment containing harmless script markup and verifying that it does not execute when viewed from the back office. Validate that existing customer-service attachments are not rendered inline in an authenticated administrative context.

Typical attack path

1. Identify a PrestaShop 8.1.0–8.1.5 store with the customer-thread feature enabled and an exposed front-office contact form.
2. Create a malicious attachment containing stored XSS payload content, such as HTML, SVG, or script-capable markup disguised as a customer-service file.
3. Submit the attachment through the public contact form as part of a customer-thread message.
4. Wait for a back-office administrator to open or preview the attachment while authenticated.
5. Execute JavaScript in the administrator’s browser session and read or reuse available session context and security tokens.
6. Send authenticated back-office requests to perform actions allowed by the administrator’s role.
7. Establish persistence or monetize access by creating administrative users, modifying modules/templates, stealing customer/order data, or changing payment-related configuration.

How to detect it

Look for evidence of suspicious contact-form uploads followed by administrator interaction with the submitted attachment. Relevant sources include web server access logs, WAF logs, PrestaShop application logs, back-office audit logs, file-upload storage, endpoint/browser telemetry for administrator workstations where available, and records of customer-service messages or attachments. Hunt for unauthenticated POST requests to the contact form that include file uploads, especially from unusual IPs, followed by back-office requests to view the associated customer thread or download/open the attachment. Inspect uploaded attachments for active content such as script tags, SVG onload handlers, JavaScript URLs, event-handler attributes, iframes, or obfuscated JavaScript. After any suspected trigger event, review back-office activity for unexpected creation of administrator accounts, role or permission changes, module installation, template/theme modification, payment configuration changes, customer/order exports, or other privileged actions occurring shortly after the attachment was opened. Because the payload executes in the administrator’s browser, network logs may show a sequence of legitimate authenticated back-office requests rather than a conventional server-side exploit; correlation by timing, administrator session, and the originating customer-service attachment is essential.

• POST /contact
• submitMessage
• controller=contact
• controller=AdminCustomerThreads
• AdminCustomerThreads
• multipart/form-data
• <script
• </script>
• javascript:
• onerror=
• onload=
• <svg
• <iframe
• document.cookie
• localStorage
• sessionStorage
• fetch(
• XMLHttpRequest
• prestashop_token
• token=

What your security team should do

• Patch PrestaShop to 8.1.6 or later immediately, prioritizing internet-facing stores using the customer-thread feature.
• If patching cannot be completed quickly, disable the customer-thread feature flag and block executable or script-capable attachments on the contact form.
• Search historical contact-form submissions and customer-service threads for suspicious attachments submitted before remediation.
• Review administrative activity after any suspicious attachment was opened, focusing on new admin users, permission changes, module installation, theme/template edits, payment configuration changes, and unusual exports of customer or order data.
• Invalidate administrator sessions and require re-authentication after patching; reset privileged credentials if logs suggest suspicious back-office actions.
• Add detection logic for public contact-form uploads followed by back-office access to the same attachment or customer-service thread.
• Harden file-upload handling across the storefront by allowlisting attachment types, enforcing safe content disposition, and scanning uploaded content for HTML/JavaScript payloads.