inventory-management-system CVE-2026-90599

Exploitation requires: (1) the victim must be authenticated to the inventory-management-system at the time of the attack - the forged request is only valid if the session cookie is active; (2) the victim must be socially engineered into visiting an attacker-controlled page or clicking a crafted link (UI:P); (3) the application must be network-accessible from the attacker's delivery vector (AV:N). Factors limiting exploitation: the application must be deployed and reachable, which is unlikely outside of small/personal environments; the attacker must know the target application URL; and the impact is confined to low-severity integrity changes (VI:L) with no confidentiality or availability impact. No elevated attacker privileges are required (PR:N), but victim authentication is a hard prerequisite.

Real-world risk is low. The CVSS 4.0 score of 2.1 accurately reflects the constrained impact: exploitation requires user interaction (UI:P), affects only integrity at a low level (VI:L), and has no confidentiality or availability impact. The product is an obscure, unmaintained-looking hobby or student project on GitHub with no apparent enterprise deployment footprint, which further depresses practical risk. A POC exists (E:P in the CVSS supplemental vector), elevating exploitation ease slightly, but the attack requires social engineering a victim who is simultaneously authenticated to the application. The project has not responded to the disclosure, and no patch is available, but the narrow deployment scope means this is unlikely to represent a meaningful threat surface for most organizations. EPSS data was not provided in the input; based on product obscurity and low CVSS score, exploitation probability is expected to be extremely low.

An attacker crafts a malicious HTML page containing a hidden form that submits a request to the target application's includes/process.php endpoint (e.g., to update user data). The attacker social-engineers an authenticated inventory-system user into visiting the malicious page - for example via a phishing email. The victim's browser silently sends the forged request with their valid session cookie, causing the application to perform the unauthorized action without the victim's awareness. A proof-of-concept script (poc_idor_updateuser.py) is publicly available, though it requires adaptation for specific deployments.