SourceCodester Inventory System EUVD-2026-104123

Exploitation requires an authenticated session with at least low-level access to the Inventory System (PR:L) so the attacker can reach the Purchase Records Handler and submit a purchase via /api/transactions_handler.php?action=save_purchase. The injected payload is delivered through the Product_Name, Product_Code, or Vendor_Name parameters. Triggering the payload requires passive user interaction (UI:P) - a second user, typically an operator or administrator, must subsequently view the page that renders the stored purchase record. Limiting factors: valid account needed (no anonymous exploitation), a victim must open the affected view, and the product's tiny deployment base sharply narrows realistic targeting. Confirmed only against SourceCodester Inventory System 1.0.

This is a genuine-but-low-priority issue. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:L/VA:N, score 5.1 MEDIUM) describes a network-reachable cross-site scripting flaw that nonetheless requires BOTH low-level authentication (PR:L) and passive victim interaction (UI:P) - two gating factors that materially reduce real-world exploitability. The exploitation-maturity flag (E:P) and the GitHub reference confirm publicly available exploit code exists, but there is NO CISA KEV listing and NO EPSS score was provided, so there is no evidence of active or automated exploitation. Signals are internally consistent (POC present, modest impact, authentication + interaction required) rather than conflicting. The dominant real-world limiter is not the CVSS score but the affected product itself: SourceCodester Inventory System is a small hobby/educational PHP application with negligible enterprise deployment, so even a working exploit has a tiny addressable attack surface. Treat as a standard patch-cycle item, not an emergency; the high-CVSS-looking 'remote' attribute is offset by authentication, user interaction, and near-zero prevalence.

An authenticated low-privilege user submits a purchase record via /api/transactions_handler.php?action=save_purchase with a malicious script payload in the Product_Name, Product_Code, or Vendor_Name field; the payload is stored and later rendered unsanitized, so when another operator (e.g. an administrator) views the purchase records their browser executes the injected JavaScript, enabling session hijacking or actions in their context. Public exploit code for this exact vector exists on GitHub, lowering the barrier to reproduction.