CVE-2026-90566: Privilege Escalation via Unvalidated usertype in inventory-management-system

Overview

A privilege-escalation vulnerability has been disclosed in inventory-management-system, an open-source PHP inventory management application maintained by GitHub user Rizwan17. Tracked as CVE-2026-90566, the flaw sits in the account-registration flow: the createUserAccount function inside register.php — part of the application's Registration Handler component — trusts a client-supplied usertype parameter without validating it against the current user's actual privilege level.

In practice, this means anyone able to reach the public registration endpoint can submit a value such as admin (or another privileged role) in the usertype field and have the application create an account with that elevated role from the moment it's created — no prior authentication, approval step, or separate escalation action required.

The issue was publicly disclosed on September 13, 2026, and affects the project up to commit bfe78a330d01bb26b9daec5dc9ecd5c77900e03f.

Technical Details

How It Works

The registration handler accepts a usertype field submitted by the client and passes it through to account creation with little or no server-side check that the requester is actually authorized to assign that role. Because the application's normal registration workflow is intended for unauthenticated, self-service sign-up, an attacker can simply modify the submitted form data — for example, changing usertype=user to usertype=admin in the HTTP request — and receive an account provisioned with administrative or otherwise elevated permissions.

This class of bug is sometimes described as "mass assignment" or "unrestricted parameter" privilege escalation: the server trusts a field the client should never be allowed to set directly, and there is no secondary authorization check (such as requiring an existing administrator to approve or assign elevated roles) before the privilege takes effect.

Impact Assessment

Successful exploitation gives an attacker a fully functional account with elevated privileges inside the target inventory-management-system deployment — potentially administrative control over inventory records, user management, and any other functionality gated behind the admin/privileged usertype value. Depending on how the application is deployed, that could extend to modifying stock records, viewing other users' data, or creating additional privileged accounts.

It's worth being precise about scope here: this is a niche, low-adoption open-source project, not a widely deployed enterprise platform. The practical blast radius is limited to organizations that have specifically adopted this particular Rizwan17 codebase for inventory management and exposed its registration endpoint to untrusted users. That said, for anyone running this software, the impact of an unauthenticated path to admin-level access is serious — hence the CVSS 7.3 (High) rating — and it's a useful reminder of a broader, very common class of bug in home-grown and small-team PHP applications: trusting role/permission fields that arrive from the client.

Affected Versions

The project appears to use continuous, rolling commits rather than tagged releases, so there is no discrete "vulnerable version number" — only the commit hash referenced in the advisory. As of publication, the maintainer has reportedly been notified via an issue report but has not yet responded or shipped a fix.

A related finding, CVE-2026-90565, was disclosed against the same project's dashboard.php around the same time, involving improper access control via a manipulated userid argument. If you run this codebase, treat both as part of the same broader "trust the client's identity/role claims" pattern and review the whole authorization layer, not just the registration path.

Mitigation

Because no official patch is confirmed yet, treat the following as compensating controls until the maintainer ships a fix:

• Do not expose the registration endpoint to untrusted networks if it isn't strictly needed — restrict register.php to trusted/internal access, or place it behind an authentication proxy.
• Patch the code directly if you're self-hosting: strip or hard-code the usertype value server-side for public self-registration (e.g., always assign the lowest-privilege role), and require an explicit, separately-authorized step for any account to become admin.
• Audit existing accounts for any user records with an unexpectedly privileged usertype that weren't provisioned through an approved process.
• Monitor the upstream repository for a fix commit or release and apply it promptly once available.
• General guidance: never trust a role, permission level, or usertype-style field submitted directly by the client during self-service registration — assign privileges server-side, based on server-controlled logic, not user input.

Sources

• NVD — CVE-2026-90566