PrestaShop Checkout CVE-2025-61924

Requires an authenticated attacker with high-privilege PrestaShop backoffice access and the ability to reach the ps_checkout module's PayPal account configuration; the flawed array_search() loose comparison is then abused to bypass validation and target the merchant account. Affects ps_checkout versions < 4.4.1 and >= 5.0.0 through < 5.0.5 across PrestaShop 1.7/8/9. Limiting factors: no remote unauthenticated path, no user interaction needed but backoffice privileges are mandatory (PR:H), and sites on patched builds (4.4.1 / 5.0.5) are not affected. No workarounds exist, so upgrading is the only mitigation.

This is a genuinely low-priority issue despite being a payment-related flaw. The CVSS 3.1 base score is only 3.8, driven primarily by the PR:H requirement - the attacker must already possess high-privileged PrestaShop backoffice access before the wrong usage of PHP array_search() (loose/type-juggling comparison, CWE-184) can be abused to bypass validation and hijack the target PayPal merchant account. EPSS is low at 0.27% (18th percentile), consistent with the high privilege barrier and the absence of any remote-unauthenticated path. There is no CISA KEV listing and no public proof-of-concept referenced, so there is no evidence of active exploitation or widespread weaponization. The signals are internally consistent: a high-privilege, insider-or-post-compromise flaw rather than a mass-exploitable vulnerability. The one tension worth flagging is impact magnitude - the official vector rates impact as C:L/I:L, but 'merchant account hijacking' that reroutes store payouts is a meaningful integrity impact on the business, so the real-world financial consequence may exceed what the 3.8 score suggests even though exploitability remains constrained by the backoffice privilege requirement.

A malicious or compromised PrestaShop backoffice user with configuration access to the ps_checkout module submits a crafted merchant-account value that slips past the flawed array_search() validation, causing the store to link a PayPal merchant account the attacker controls. Subsequent customer payments are then routed to the attacker's account. No public exploit code is identified, and the attack requires existing high-privilege backoffice access (AV:N/AC:L/PR:H/UI:N).