InvoicePlane CVE-2026-100371

Requires an authenticated secondary administrator account (user_type=1, user_id != 1) on the InvoicePlane instance. The exploit abuses Users::form() which lacks the object-level authorization check that guards Users::change_password() and Users::delete(), combined with user_email being absent from PROTECTED_FIELDS. The second stage relies on the built-in public/logged-out password-recovery flow (sessions/passwordreset) that resolves accounts by user_email. Limiting factors: attacker must already hold an admin account (not unauthenticated despite the CVSS PR:N), and only affects InvoicePlane 1.7.2 prior to commit 8616fa4; no user interaction from the victim is needed and no non-default configuration is required.

This is a genuine authorization defect (CWE-863, broken object-level authorization) confirmed by a vendor GitHub Security Advisory (GHSA-77hm-22wp-96wp) and a patch commit (8616fa4), with corroborating PR diff evidence showing the incomplete prior fix (PR #1638). The vendor CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N/VC:N/VI:H) yields 8.7 (High), but PR:N is inconsistent with the description: exploitation REQUIRES an authenticated secondary administrator account (user_type=1, user_id != 1). The network vector and low complexity are accurate, but privilege requirement should be PR:H/PR:L, not PR:N - this materially lowers real-world risk versus the headline score. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no evidence of active or imminent exploitation. The realistic risk is an insider/second-admin privilege-escalation-to-primary-admin path rather than an internet-facing unauthenticated compromise. Priority is moderate: high impact (full primary-admin takeover) but a meaningful precondition (existing admin access) and a niche product footprint temper urgency. EPSS/KEV absence is not itself an error but reinforces that this is not a mass-exploitation candidate.

A malicious or compromised secondary administrator edits the primary administrator's account via Users::form(), rewriting user_email (not covered by PROTECTED_FIELDS or any object-level check) to an address they control. They then trigger the public logged-out password-recovery flow, which resolves the account by user_email, receive the reset token, and take over user_id=1. No public exploit code was provided, but the attack is deterministic and requires only existing admin access plus low attack complexity.