osCommerce2 EUVD-2026-92249

Exploitation targets the include function in includes/classes/payment.php via manipulation of the MODULE_PAYMENT_INSTALLED argument on the Payment Page component, enabling CWE-94 code injection. Per the CVSS 4.0 vector, two concrete limiting factors apply: the attacker must already possess high privileges (PR:H - i.e. administrative/backend access to the store's payment configuration, not an anonymous web visitor), and passive user interaction is required (UI:P) to reach the vulnerable payment flow. Affected deployments are osCommerce2 up to and including 2.3.4.1; no confirmed upstream patch exists because the project has not responded to the report, so unpatched installations remain exposed but only to already-privileged actors.

This is a medium-severity issue (CVSS 4.0 base score 4.8) whose real-world priority is modest despite the alarming 'code injection / RCE' framing. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:P/VC:L/VI:L/VA:L) shows the two most important limiting signals: PR:H (the attacker already needs high privileges) and UI:P (passive user interaction is required), and all three impact metrics are only Low rather than High - inconsistent with the full-server-compromise that 'code injection' usually implies. Exploitation status is 'publicly available exploit code exists' (E:P, VulDB-linked GitHub issue), but there is NO CISA KEV listing and no EPSS score was supplied, so there is no evidence of active, widespread exploitation - POC availability must not be conflated with in-the-wild use. No SSVC decision data (automatable, exploitation status) was provided. The headline tension: the 'RCE'/'Code Injection' tags and CWE-94 suggest critical impact, yet the authoritative CVSS vector rates impact only Low across C/I/A and requires high privileges plus user interaction, so this reads as a privilege-dependent code-injection bug rather than an unauthenticated remote takeover. Compounding the risk only marginally, the project was notified via an issue report and has NOT responded, meaning no official patch is confirmed available; this keeps the door open longer but is offset by the high privilege prerequisite.

An attacker who already holds high-privilege (administrative/backend) access to an osCommerce2 store manipulates the MODULE_PAYMENT_INSTALLED argument handled by the include function in includes/classes/payment.php, injecting attacker-controlled code that the payment page subsequently includes/executes. A publicly available exploit referenced from the osCommerce GitHub issue tracker demonstrates the technique, and passive user interaction is needed to trigger the vulnerable payment-page flow.