PrestaShop Checkout Zero-Click Account Takeover via ExpressCheckout Endpoint (CVE-2025-61922)
by g0vguy (script author credited as "S 1 D E R") · 2026-07-06
- Severity
- Critical
- CVE
- CVE-2025-61922
- Category
- web
- Affected product
- PrestaShop Checkout module (ps_checkout)
- Affected versions
- Below 5.0.5
- Disclosed
- 2026-07-06
- Patch status
- unpatched
Tags
References
Archive entry
intelseclab/poc-archiveMetadata
| Field | Value |
|---|---|
| Date Added | 2026-07-06 |
| Last Updated | 2026-07 |
| Author / Researcher | g0vguy (script author credited as “S 1 D E R”) |
| CVE / Advisory | CVE-2025-61922 |
| Category | web |
| Severity | Critical |
| CVSS Score | 9.1 |
| Status | PoC |
| Tags | prestashop, ps_checkout, account-takeover, express-checkout, paypal, zero-click, session-hijacking, e-commerce, cwe-287 |
| Related | N/A |
Affected Target
| Field | Value |
|---|---|
| Software / System | PrestaShop Checkout module (ps_checkout) |
| Versions Affected | Below 5.0.5 |
| Language / Platform | PHP (PrestaShop module), PoC written in Python |
| Authentication Required | No (unauthenticated) |
| Network Access Required | Yes (HTTP POST to the PrestaShop storefront) |
Summary
The PrestaShop Checkout module exposes an ExpressCheckout endpoint (/module/ps_checkout/ExpressCheckout) that is meant to handle PayPal Express Checkout order confirmation callbacks. Versions of the module prior to 5.0.5 fail to properly verify that the caller is actually authorized to act as the paying customer before establishing a session. An unauthenticated attacker can POST a JSON payload referencing an arbitrary victim email address as the PayPal payer, and the endpoint responds by establishing (and returning, via Set-Cookie) a logged-in session for that customer account — a true zero-click account takeover requiring only knowledge of the victim’s email address.
Vulnerability Details
Root Cause
The ExpressCheckout handler trusts the order.payer.email_address field supplied in the client-controlled JSON body to identify which customer account to authenticate as, without validating that the request actually originated from a legitimate, verified PayPal transaction tied to that customer. Because the order ID (orderID) is not meaningfully validated either (the PoC uses the placeholder value "1" for any request), the module ends up performing an authentication/session-issuance action driven entirely by attacker-supplied identity data.
Attack Vector
- Attacker sends an unauthenticated
POSTrequest to/module/ps_checkout/ExpressCheckouton the target PrestaShop store. - The JSON body includes a
payer.email_addressfield set to the victim’s known email address:1 2 3 4 5 6 7 8{ "orderID": "1", "order": { "payer": { "email_address": "victim@example.com" } } } - The vulnerable endpoint processes this as if it were a legitimate PayPal Express Checkout callback for that customer and returns
Set-Cookieheaders containing a valid, authenticated PrestaShop session for the victim’s account (the PoC notes this can occur even alongside an HTTP 500 response). - The attacker replays the captured session cookie against the store (e.g.,
/my-account) to confirm full access to the victim’s account — order history, saved addresses, payment details, etc.
Impact
Complete, unauthenticated takeover of any customer account on a vulnerable PrestaShop store given only the victim’s email address — no password, OTP, or prior interaction from the victim required. This exposes personal data, order/payment history, and saved addresses, and could be leveraged for fraud (e.g., placing orders using stored payment methods, harvesting PII at scale by iterating known/leaked email addresses).
Environment / Lab Setup
Target: PrestaShop store with ps_checkout (PrestaShop Checkout) module < 5.0.5 installed and enabled
Attacker: Any host capable of issuing raw HTTP requests (Python 3 + `requests` library used by the PoC)
Proof of Concept
PoC Script
See
CVE-2025-61922.pyin this folder.
| |
The script has three subcommands:
check— sends anOPTIONSrequest to/module/ps_checkout/ExpressCheckoutand inspects theAllowheader / status code to fingerprint whether the vulnerable endpoint is present.takeover— POSTs the crafted JSON payload (with the victim’s email as the PayPal payer) and inspects the response forSet-Cookiesession cookies.test— replays a captured cookie string against/my-accountand checks the response body for authenticated-session indicators (“My account”, “Order history”, “Sign out”, “Logout”) to confirm the takeover succeeded.
Detection & Indicators of Compromise
Signs of compromise:
- Requests to
/module/ps_checkout/ExpressCheckoutfrom IPs/User-Agents inconsistent with PayPal’s callback infrastructure Set-Cookieresponses issued from ExpressCheckout fororderIDvalues that do not correspond to real, in-progress orders- Customer account activity (logins, order views) not preceded by a normal login flow for that account
Remediation
| Action | Detail |
|---|---|
| Primary fix | Update the PrestaShop Checkout (ps_checkout) module to version 5.0.5 or later, which validates that ExpressCheckout callbacks correspond to a real, verified PayPal transaction before issuing a session |
| Interim mitigation | Disable/restrict the ps_checkout ExpressCheckout endpoint until patched; monitor for anomalous requests to /module/ps_checkout/ExpressCheckout; force re-authentication for sensitive account actions (payment methods, address changes) |
References
Notes
Mirrored from https://github.com/g0vguy/CVE-2025-61922-PoC on 2026-07-06.
| |