OpenCart Virtual POS CVE-2026-85531

Exploitation requires that the target OpenCart store has the Sipay Electronic Money and Payment Services Virtual POS Module installed and active at a version from 26.8.2 up to (but not including) 26.9.1, with its payment-callback/token-verification endpoint reachable over the network. The core precondition is that the module's signature-verification routine improperly validates the cryptographic signature (CWE-347), so an attacker can submit a forged or tampered signed token (e.g. a JWT) and have it accepted. Limiting factors: exploitation is constrained to deployments running this specific vulnerable module and version range; stores on 26.9.1+ or not using this module are unaffected. Per CVSS PR:N/UI:N no authentication or user interaction is needed, so there is no credential or victim-interaction barrier beyond network reachability of the vulnerable endpoint.

The input CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, base 9.8) describes a network-reachable, low-complexity, unauthenticated flaw, and the CWE-347 classification plus the 'Jwt Attack' and 'Information Disclosure' tags point to a cryptographic-signature verification bypass - most plausibly JWT signature spoofing in the Sipay payment callback/token flow. If exploitable as scored, an attacker could forge a trusted signed message (e.g. a payment-confirmation token) without credentials, which is a genuinely serious integrity issue for a payment module. However, the risk signals are incomplete and partly inconsistent: no EPSS probability, no CISA KEV listing, and no public POC were provided, so there is no evidence of real-world exploitation - this is a high-CVSS issue without corroborating exploitation signals, suggesting it should be patched promptly but is not yet a confirmed active-attack priority. Note also a likely overstatement in the input vector: a signature-spoofing/JWT bypass most naturally yields integrity and confidentiality impact, not high availability impact, so the A:H component (and thus the 9.8 total) should be verified against the vendor/CERT advisory.

An unauthenticated remote attacker crafts a forged JWT or signed payment message with a spoofed/invalid signature that the module fails to properly verify, causing it to accept the forged token as authentic. The attacker uses this to impersonate a legitimate Sipay payment callback - for example asserting a successful payment that never occurred, or extracting information carried in the token. No public exploit code was identified at time of analysis, and low attack complexity (AC:L) means a working forgery requires no special timing or environmental conditions.