PrestaShop Virtual POS Module EUVD-2026-95755

Exploitation requires that the target PrestaShop store has the Sipay Electronic Money and Payment Services Virtual POS Module installed and active at a version from 26.8.1 up to (but not including) 26.9.1. The flaw lies in the module's cryptographic signature verification path (CWE-347, 'Jwt Attack' tag), so an attacker must reach the endpoint that processes signed payment data/JWTs - per the CVSS vector this is network-reachable with no authentication (PR:N) and no user interaction (UI:N). The principal LIMITING factor is deployment: the module is a Turkish payment-gateway integration, so the exposure is confined to merchants using Sipay with PrestaShop rather than default PrestaShop installations generally.

The input signals are largely one-directional but incomplete. CVSS 3.1 is scored 9.8 CRITICAL (AV:N/AC:L/PR:N/UI:N) indicating a remote, unauthenticated, low-complexity attack - consistent with the CWE-347 (Improper Verification of Cryptographic Signature) classification and the 'Jwt Attack' tag, which together point to a JWT/payment-callback signature-spoofing bypass. However, several key triage signals are MISSING: no EPSS score, no CISA KEV listing, and no POC reference were provided, so exploitation likelihood cannot be quantified from the data - status is 'no public exploit identified at time of analysis.' There is also internal tension in the severity claim: a pure signature-verification bypass primarily yields an integrity impact (forging a valid-looking signed payment/authorization), so the vendor/NVD's C:H/I:H/A:H (particularly A:H availability impact) appears inflated for this vulnerability class and should be verified with the vendor advisory. Net: this is a genuinely high-priority flaw for the specific population that runs this module (unauthenticated remote signature spoofing in a payment path is inherently serious), but the real-world risk is bounded by the module's limited deployment footprint rather than by exploit maturity, which is currently unknown.

An attacker crafts a forged request containing a payment confirmation or JWT whose signature is not properly verified by the Sipay Virtual POS module, causing the application to accept it as authentic. This allows the attacker to spoof a successful payment/authorization (e.g., marking an order as paid) or tamper with signed data without possessing the legitimate signing key. No public exploit code has been identified at the time of analysis.