CVE-2026-100371: InvoicePlane: Incomplete Authorization Remediation in Users::form() Enables Primary Administrator Account Takeover via Email Reassignment and Password Recovery
InvoicePlane is a self-hosted open source application for managing invoices, clients, and payments. In version 1.7.2, an authorization guard to Users::changepassword(), was added to address a previous authorization flaw that allowed a secondary administrator (usertype=1, userid != 1) to directly change the password of the primary administrator (userid=1) through users/changepassword/{id}. That remediation, however, protects only the direct password-change operation. It does not protect the identity attribute that password recovery actually trusts: useremail. Users::form() applies no equivalent object-level authorization check when editing the primary administrator's account, and useremail is not included in PROTECTEDFIELDS. A secondary administrator can therefore rewrite the primary administrator's email address, then drive the public password-recovery flow — which resolves the account by useremail — to receive the reset token and take over userid=1. The result is an alternate attack path that achieves the same impact PR #1638 was intended to prevent: cross-administrator full account takeover of the primary administrator. This issue has been patched via commit 8616fa4.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch 8616fa4
Event History
Frequently Asked Questions
Who can exploit this issue?
A secondary administrator account (user_type=1 with a user_id other than 1) can exploit it against the primary administrator account (user_id=1). The attacker must be able to use the administrative user-editing functionality and the public password-recovery flow.
How does the takeover work despite the password-change authorization guard?
The guard protects the direct Users::change_password() operation, but Users::form() does not apply an equivalent object-level check when editing the primary administrator. A secondary administrator can change the primary administrator's user_email, then request a password reset; the recovery flow looks up the account by email and sends the reset token to the attacker-controlled address.
What should be done if the installation cannot be patched immediately?
Restrict secondary administrator access, since those accounts can edit the primary administrator's email address and initiate the recovery path. Monitor the primary administrator account's email address and password-reset activity for unauthorized changes.
How can administrators determine whether an account may already have been targeted?
Check whether the primary administrator account's user_email has been changed unexpectedly and review password-recovery activity associated with that account. An unauthorized email reassignment followed by a password reset is consistent with this attack path.
What patch is identified for this issue?
The issue is described as patched by commit 8616fa45a61c1694b55bb9116e293269a0ced06a.