Vitepos POS EUVD-2026-102677

Exploitation requires an authenticated WordPress session with 'vendor-level access and above' in the Vitepos POS plugin, and the attacker must reach the affected POS API endpoints (e.g. the vendor/outlet/purchase APIs) that process the src_by[] filter parameters. The specific trigger is supplying attacker-controlled values in src_by[].val.start / src_by[].val.end while using the 'bt' (BETWEEN) operator, which routes into the unpatched SQL branch left exposed after the 3.6.0 fix. Limiting factors: the required privileged vendor role prevents anonymous or low-privilege exploitation, and sites that are not running Vitepos / WooCommerce or that lack active vendor accounts are not exposed; the injection is blind, so extraction is slower and noisier than an in-band SQLi.

This is a moderate-priority issue rather than an emergency. The CVSS 3.1 vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 6.5) indicates a network-reachable, low-complexity blind SQL injection that nonetheless requires authentication - specifically 'vendor-level access and above' per the description, consistent with PR:L. Impact is confidentiality-only (C:H, I:N, A:N): the flaw enables database extraction, not data tampering or denial of service. No EPSS score, CISA KEV listing, or public POC was provided in the input, so per the precision rules there is no public exploit identified at time of analysis and no evidence of active exploitation. The most important nuance is that this is explicitly an INCOMPLETE FIX: version 3.6.0 patched the gt/lt/le/ge operator branches but left the 'bt' (BETWEEN) operator branch vulnerable, meaning a defender who believed they were patched at 3.6.0/3.6.1 remains exposed - this elevates practical risk for organizations that assumed the earlier CVE was resolved. The authentication barrier (a privileged vendor role must already be compromised or malicious) materially limits mass exploitation, pointing to insider or post-compromise abuse rather than opportunistic internet-wide scanning.

An attacker who holds or has compromised a vendor-level (or higher) POS account sends a crafted API request manipulating the src_by[].val.start / src_by[].val.end parameters with the 'bt' BETWEEN operator, injecting additional SQL into the unprepared query. Because the injection is blind, they iteratively infer data through boolean/time-based responses to extract sensitive database contents such as customer records or WordPress credentials/secrets. No public proof-of-concept exploit was identified in the provided data.