Welcart e-Commerce EUVD-2026-111718

Requires an authenticated WordPress account with the Author role or higher on a site running the Welcart e-Commerce plugin before 2.12.6. The specific trigger is that the plugin's capability check for SKU operations is not tied to the product being edited, so any such authenticated user can read, modify, create, delete and re-order SKU data (prices, confidential cost prices, stock levels) of products owned by other users. Limiting factors: exploitation depends on the attacker first obtaining an Author-level-or-higher account (sites without open Author self-registration materially reduce exposure); no administrative access and no user interaction are required, and the attack is over the network against the plugin's default behavior once that account exists.

All quantitative signals point to this being a genuine but low-priority issue rather than an urgent threat. The official CVSS base score is only 3.8 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N), EPSS is 0.15% (4th percentile - very low predicted exploitation probability), the vulnerability is NOT on CISA KEV, no public exploit is identified, and the vuln.today Decision label is 'monitor'. These signals are consistent with each other, so the appropriate posture is scheduled patching, not emergency response. One internal inconsistency should be flagged: the official vector uses PR:H (administrative privilege), yet the description states exploitation requires only 'Author-level access or higher', which in WordPress is a low-privilege, non-administrative role. This suggests the real privilege barrier is lower than PR:H implies, so the practical severity is likely somewhat higher than 3.8 - verify the privilege model with the vendor/WPScan advisory. No SSVC exploitation/automatable/technical-impact decision points were supplied, so that framework cannot be independently applied here.

An attacker who already holds an Author-level (or higher) account on a WordPress site running Welcart e-Commerce before 2.12.6 sends SKU edit/create/delete/reorder requests targeting products they do not own. Because the plugin's capability check is not bound to the specific product, the server processes the request and the attacker reads confidential cost prices or tampers with prices and stock levels across the catalog. No public exploit code is identified at time of analysis, so an attacker would need to craft the requests from knowledge of the advisory.