InvoicePlane CVE-2026-100392

Requires an authenticated Secondary Administrator account (user_type = 1 with user_id != 1) on an InvoicePlane 1.7.2 instance that provisions more than one administrator. The attacker uses the standard Users::form() user-edit endpoint against the Primary Administrator (user_id = 1), which performs no object-level authorization check, and sets user_type = 2 (Guest/read-only). Limiting factors: the deployment must have at least one non-primary administrator (single-admin installs are not exposed to this insider vector), the attacker must already possess or compromise that high-privilege account (PR:H), and impact is a privilege-destruction/lockout rather than data theft. No patch is currently available, so mitigation depends on restricting who holds secondary-admin roles.

This is a genuine but bounded integrity/privilege-abuse issue rather than a broadly weaponizable flaw. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:L) scores 7.0 and is internally consistent with the description: network-reachable, low complexity, but requiring HIGH privileges (PR:H) because the attacker must already hold a Secondary Administrator account (user_type=1). The impact is integrity-dominant (VI:H - silently rewriting the Primary Administrator's user_type) with only a limited availability effect (VA:L - the legitimate owner is locked into read-only, not a full service outage) and no confidentiality loss (VC:N). No EPSS score, no CISA KEV listing, and no public exploit code are present in the provided data, so exploitation is not confirmed or automated in the wild. The dominant limiting factor is PR:H: this is an insider/second-admin abuse or a post-compromise escalation, not something an anonymous internet attacker can trigger. Net: a real, credible privilege-destruction/lockout bug worth patching for multi-admin deployments, but not an emergency mass-exploitation candidate. Note one caveat: no vendor patch exists yet ('no publicly available patches'), which raises operational urgency for exposed multi-admin instances despite the modest exploitation probability.

A Secondary Administrator account (user_type=1, user_id != 1) - either a legitimate-but-malicious co-admin or an account taken over by an attacker - opens the user-edit form Users::form() targeting user_id=1 and submits a changed user_type=2 (Guest/read-only). Because no object-level authorization check protects the Primary Administrator, the root owner is instantly demoted and locked out of administering the instance. No public exploit code is identified at time of analysis; exploitation requires an existing high-privilege administrator session.