PrestaShop Checkout CVE-2025-61923

Requires an authenticated session in the PrestaShop backoffice (administrative/operator area) with access to the ps_checkout module - per CVSS PR:H, this is not a remote unauthenticated flaw. The vulnerable code path is a backoffice input lacking validation, so the attacker must be able to reach and submit to that backoffice endpoint. Affected deployments are those running ps_checkout versions prior to 4.4.1 (branch 4.x) or 5.0.0-5.0.4 (branch 5.x) across PrestaShop 1.7, 8, and 9; no workaround exists, so only upgrading to 4.4.1 or 5.0.5 removes the exposure. The limiting factor is the high-privilege backoffice requirement; impact is bounded to file disclosure (read-only), with no integrity or availability effect.

This is a genuine but low-priority issue, consistent across most signals. The CVSS vector (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N) scores 4.1 (Medium) and its defining constraint is PR:H - exploitation requires authenticated access to the PrestaShop backoffice (an administrative/operator context), which sharply limits the attacker population to insiders or anyone who has already compromised an admin session. Impact is confidentiality-only (C:L, I:N, A:N): file disclosure, not code execution or data tampering. EPSS is 0.92% (59th percentile), i.e. low absolute exploitation probability, which aligns with the high-privilege barrier. The CVE is NOT on CISA KEV and no public exploit code is referenced, so exploitation status is 'no public exploit identified at time of analysis.' No signals conflict here - the low EPSS, high-privilege requirement, confidentiality-only impact, and absence of KEV/POC all point the same direction. One point to verify: the input scores C:L, but 'arbitrary file disclosure' via directory traversal can expose highly sensitive files (configuration secrets, credentials, private keys), which could warrant a higher confidentiality rating than L - worth validating against the vendor's intent. SSVC framing: exploitation=none observed, automatable=no (requires authenticated backoffice access and is not internet-wide scrapeable), technical impact=partial - supporting a 'Track' rather than 'Act' decision.

An attacker who already holds (or has hijacked) a PrestaShop backoffice account with sufficient privileges sends a crafted request to the ps_checkout module backoffice endpoint containing directory-traversal sequences in an unvalidated path parameter. The server resolves the path outside the intended directory and returns the contents of an arbitrary file, such as the PrestaShop configuration holding database credentials or API secrets. No public proof-of-concept is referenced, and the attack requires prior authenticated backoffice access.