InvoicePlane missing object-level authorization lets Secondary Administrators demote the Primary Administrator

InvoicePlane is a self-hosted open source application for managing invoices, clients, and payments. In version 1.7.2, Users::form() performs no object-level authorization check on user_id = 1. A Secondary Administrator (user_type = 1, user_id!= 1) can rewrite the Primary Administrator's user_type to 2 (Guest / read-only), destroying the root account's privilege and locking the legitimate owner out of the instance. At time of publication, there are no publicly available patches.

• InvoicePlane InvoicePlane 1.7.2: confirmed affected.
• The record and advisory do not list a patched release; the status of other versions is not established by the available evidence.
• The relevant deployment condition is an instance with a Secondary Administrator who can reach user-management functionality.

InvoicePlane's Users::form() takes the target record ID from the route but does not check whether the acting administrator is authorized to modify that object. The method distinguishes only between self-editing and editing another account; for non-self edits, a submitted user_type can be assigned to the target, including the Primary Administrator. The path is reachable by an authenticated Secondary Administrator through the user-management interface or the underlying HTTP request; no unauthenticated state or additional CSRF bypass is required. When the role changes, invalidate_user_sessions($id) revokes the affected account's sessions, amplifying the lockout. The model's mass-assignment protection does not close this path because the controller explicitly assigns user_type; deployment-specific request handling and logging remain unknown.

The flaw is remotely reachable through the user-management interface or the corresponding HTTP request. Exploitation requires a valid authenticated Secondary Administrator account (user_type = 1, user_id != 1); no unauthenticated path is described. No victim interaction, additional CSRF bypass, or privilege beyond the attacker's existing Secondary Administrator access is required. user_id = 1 is a fixed identifier for the Primary Administrator and can be identified from the standard user listing. The public advisory contains reproduction details, but the available evidence does not establish exploitation in the wild, a campaign, or a specific incident.

The flaw lets an account that already has Secondary Administrator access change the Primary Administrator's privilege attribute, but it does not show the attacker gaining a privilege level that the account did not already possess. The technical result is that user_id = 1 can be changed to user_type = 2, preventing the Primary Administrator from performing administrative functions and potentially invalidating active sessions. The instance may become administratively locked away from its legitimate owner while the Secondary Administrator becomes the effective sole administrator. There is no direct evidence of a confidentiality impact; the effect on business data outside administrative access is not established.

A Secondary Administrator can break the trust boundary between administrative accounts by downgrading the root account. The Primary Administrator may have their sessions revoked and lose access to administrative functions, leaving the instance under the effective control of the attacker or any remaining Secondary Administrators. Recovery may require direct database access because the legitimate owner can no longer reverse the change through the application UI. The available evidence does not confirm disclosure or modification of invoice, client, or payment data; the confirmed impact is concentrated on administrative authority and operational access.

1. Implement a single global object-level authorization guard at the top of Users::form(), before validation, db_array(), the user_type assignment, saving, and the GET render path. The guard should reject every operation on user_id = 1 when the actor is not the Primary Administrator and return 403.
2. Do not protect only password, email, or role fields individually. The guard must cover every mutation of user_id = 1, including current fields and fields added later.
3. Verify the change by testing that GET and POST requests for user_id = 1 from a Secondary Administrator are rejected, ip_users.user_type remains 1, and the Primary Administrator can still edit their own profile.
4. The record does not provide a specific publicly released patch. Until the guard can be deployed, restricting the access and operational scope of Secondary Administrator accounts is a temporary risk-reduction measure, not a complete fix.

1. Inventory InvoicePlane instances and identify deployments running the affected version.
2. Inspect the ip_users table to confirm that user_id = 1 still has user_type = 1, and identify Secondary Administrator accounts with user_type = 1 and user_id != 1.
3. Review application or reverse-proxy logs, where available, for requests to /users/form/1 made by a Secondary Administrator. Correlate them with requests that submit user_type = 2 and with session invalidation for the Primary Administrator. This is precautionary monitoring, not a confirmed IOC.
4. Review operational signals such as an unexpected Primary Administrator logout or loss of administrative access occurring with a role change.
5. After deploying the guard, verify that a Secondary Administrator receives 403 when viewing or submitting changes to user_id = 1, that the role remains user_type = 1, and that the Primary Administrator can still edit their own profile. The absence of matching log evidence does not prove that an instance is safe.