[CVE-2025-51586] PrestaShop Admin Login Controller Leaks Administrator Emails

TL;DR
The password reset endpoint in PrestaShop versions 1.7 up to 8.2.2 discloses the email address that belongs to any Back Office account when the request contains a valid id_employee but an invalid reset_token. Attackers can sweep the ID space to build a full list of administrator identities, dramatically increasing the success rate of phishing and credential-stuffing campaigns. The flaw is fixed in 8.2.3.

1. Summary

The bug is a textbook user enumeration issue yet its impact goes well beyond curiosity. Obtaining a confirmed list of administrator email addresses allows attackers to focus password spraying, social-engineering and MFA-prompt bombing on real targets instead of wasting requests on nonexistent accounts.

2. Context – why a leaked email equals revenue loss in ecommerce

PrestaShop powers close to 300 000 online stores according to the project’s own statistics. Every installation ships with a Back Office that administrators use to manage orders, customers and the product catalogue. Although best practice is to restrict this interface to trusted networks, many merchants expose it to the public internet so they can work from anywhere. Because the same Back Office controls payment modules and database credentials, an attacker who compromises an account can usually pivot to full shop takeover. Knowing the exact email that maps to each privileged account removes a significant barrier for that attack chain.

3. Technical Details – a missing guard in AdminLoginController

The password-reset process in PrestaShop is driven by two parameters: id_employee, which is a sequential numeric primary key, and reset_token, a high-entropy string stored in the database. The vulnerable code path inside AdminLoginController::processForgot() performs the following steps:

1. Load the employee record that matches id_employee.
2. Check whether the supplied reset_token matches the one stored in the database.
3. Regardless of the outcome of step 2, render the password-reset form and include the email address in a hidden HTML input named email.

Step 3 should only execute if the token check succeeds, but a misplaced return statement after the form rendering short-circuits the normal flow. Consequently, anyone can retrieve the email address as long as the id_employee exists.

An attacker scripts the following request loop:

# Enumerate first 200 employee IDs
for i in $(seq 1 200); do
  curl -sk "https://shop.example.com/admin-dev/index.php?controller=AdminLogin&id_employee=$i&reset_token=invalid" |
  grep -oP '(?<=name="email" value=")[^"]+' >> leaked_emails.txt
done

In practice the entire enumeration completes in seconds because the id_employee field is monotonically increasing and the server response is small.

Patch analysis

Version 8.2.3 moves the form rendering into an if ($isTokenValid) block and exits early when validation fails. The diff also regenerates the token after every successful reset, preventing replay attacks.

4. Impact – from reconnaissance to account takeover

While no passwords are directly exposed, confirmed administrator email addresses dramatically lower the cost of further attacks. Attackers can:

• Launch targeted credential stuffing with breached password databases that include the same email.
• Craft convincing password-reset phishing pages because victims expect a reset link.
• Abuse fallback flows such as “contact support to verify identity” with believable personal information.

In the higher-risk scenarios where the Back Office is not restricted by IP, a single successful login hands over full control of the store, payment integrations and sometimes customer PII stored in the database.

5. Remediation – upgrade or isolate

Updating PrestaShop to 8.2.3 is the definitive fix. Because the code change is small, applying the vendor patch or cherry-picking the commit to a custom fork is low risk. Store owners who cannot upgrade immediately should at minimum limit access to /admin*/ paths with a reverse-proxy ACL or VPN. Deleting unused employee accounts also shrinks the ID space and reduces exposure.

6. Timeline

7. References

• Researcher advisory and PoC: https://maxime-morel.github.io/advisories/2025/CVE-2025-51586.md
• PrestaShop 8.2.3 release notes: https://github.com/PrestaShop/PrestaShop/releases/tag/8.2.1
• Project homepage: https://prestashop.com/

About Volerion

Volerion delivers AI-driven enrichment minutes after a CVE goes live. A single call to our REST API returns CVSS 4.0 vectors, exploitability metrics and affected products complete with remediation. Additionally, we offer different scoring profiles, complete with insight into the eight comprehensive categories that make up the final score. Our API is also available in the tradditional NVD API 2.0 format, so integration is as simple as swapping hosts. Spend less time parsing CVEs and more time closing them.

How the Volerion Risk Score Fits With CVSS, EPSS and KEV

At the time of writing:

• This CVE is scored at 7.5 using CVSS 3.1, reflecting high confidentiality impact with low attack complexity but no integrity or availability loss.
• EPSS currently assigns a score of 0, meaning there is insufficient data to provide a prediction for exploitation in the next 30 days.
• The vulnerability is not listed in CISA’s KEV catalog.

The Volerion Risk Score brings these signals together and layers them with additional factors such as affected product prevalence, exploit maturity and remediation effort. For CVE-2025-51586 the score is 7.8. That places it in our high-risk band even though the raw CVSS impact is moderate, because the bug enables precise targeted attacks against a lucrative ecommerce platform.