StockAgile EUVD-2026-86618

Requires a valid authenticated StockAgile account (PR:L) able to write to the REST endpoint '/inventory/configuration/payment-methods' (payment-method configuration feature), submitting script payloads via the 'code', 'name', or other text fields which are not correctly filtered or validated. Execution additionally requires a second authenticated user to view the affected data in the management panel (UI:P victim interaction). Limiting factors: attacker must first obtain panel authentication, the injected script only fires when a victim renders the stored value, and impact is confined to the victim's browser session (no server-side code execution, no scope change).

This is a genuine but low-priority stored XSS. The authoritative signal is the vendor CVSS 4.0 vector (5.1, medium) with AV:N/AC:L/PR:L/UI:P: exploitation is network-reachable but requires the attacker to already hold an authenticated account (PR:L) AND requires a victim user to view the injected payment-method data in the panel (UI:P, passive interaction). Impact is capped at VC:L/VI:L/VA:N with no scope/subsequent-system impact (SC:N/SI:N/SA:N), consistent with script execution in another authenticated user's browser session rather than server compromise. There is no EPSS score, no CISA KEV listing, and no public POC referenced, so the exploitation status is: no public exploit identified at time of analysis. Nothing in the data conflicts - CVSS network vector aligns with the REST-endpoint description, and the authenticated requirement (PR:L) aligns with 'previously authenticated attacker' in the text. Net: a real, patch-worthy defect but not an urgent, widely-exploited threat; it is a medium-CVSS issue whose real-world risk is further limited by the need for both authentication and victim interaction.

An attacker with a valid low-privileged StockAgile account submits a crafted value containing JavaScript in the 'code' or 'name' field of the REST endpoint /inventory/configuration/payment-methods, which is stored unfiltered. When another authenticated user (e.g. an administrator) later views the payment-methods configuration in the management panel, the script executes in their browser session, enabling session/token theft or actions in their context. No public exploit code is identified at time of analysis, though the attack is technically simple.