InvoicePlane role downgrade fails to revoke administrative access

InvoicePlane is a self-hosted open source application for managing invoices, clients, and payments. Prior to 1.7.2, InvoicePlane fails to revoke administrative privileges after a role downgrade because Admin_Controller trusts the user_type snapshot stored in an existing session instead of revalidating ip_users.user_type. When one administrator downgrades another account, the target's active session continues to authorize administrative requests. The downgraded user can use Users::form() to set user_type back to 1, restoring the database role and making the privilege escalation persistent. This vulnerability is fixed in 1.7.2.

• The normalized record identifies InvoicePlane as affected in versions < 1.7.2.
• The project advisory specifically identifies 1.7.2-rc-2 as affected and 1.7.2 as patched.
• The available evidence does not establish the status of parallel release branches or versions later than the stated patched release. Do not infer that every later branch is unaffected.

InvoicePlane stores the user's user_type in the session at login, then uses that session value in Admin_Controller to make administrative authorization decisions instead of revalidating ip_users.user_type from the database on each request.

When administrator Y downgrades administrator X, the database role changes but X's active session is not destroyed or refreshed. The session-update logic handles only the case where the edited account is the currently authenticated account, so X's session continues to carry the administrative state and still passes the Admin_Controller check.

The still-authorized session allows the downgraded user to invoke administrative functionality, including user management. In Users::form(), the controller puts the user_type field from HTTP input back into the record even though the model protects that field. As a result, a user with the stale administrative session can set their own user_type back to 1; the value is written to the database and makes the restored privilege persistent.

The project advisory describes a tested scope of InvoicePlane on CodeIgniter 3 with the files session driver. The public record does not establish that every session configuration or every customized authorization implementation outside that scope behaves identically.

The vulnerability is reachable over the network and does not require user interaction. The key precondition is an active administrative session for the target account, followed by another administrator downgrading that account without invalidating the existing session.

After the downgrade, the target can continue sending administrative requests with the stale session. The project advisory provides reproduction evidence and a proof of concept showing retained administrative access, modification of other user accounts, and restoration of the target account's user_type.

The normalized record marks a public exploit as present, but it does not establish whether exploitation has occurred in production environments. The path requires an existing administrative privilege or access to an already-issued administrative session, not an unauthenticated guest account.

The flaw breaks privilege revocation at the point where an account is downgraded. The old session is still treated as an administrator session, so the target can continue performing administrative actions within the application.

The advisory confirms retained administrative access, modification of other user accounts, and restoration of the target account's user_type to 1, which writes administrator status back to the database. This creates persistent privilege escalation rather than only a temporary authorization mismatch in one session.

The directly established scope is InvoicePlane and its administrative functions. The record does not establish that the vulnerability by itself provides host access, crosses tenant boundaries, or affects systems outside the application.

• Downgrading an administrator does not provide a reliable privilege-revocation boundary, weakening access-control and offboarding procedures.
• A user who should have lower privileges can retain administrative control of the application through an existing session.
• That user can modify other accounts and restore their own role in the database, allowing the privileged state to survive session refresh.
• Depending on the administrative functions and data exposed to the account, the issue could enable unauthorized changes to users, invoices, clients, payments, or application settings.
• The confirmed evidence concerns administrative control within InvoicePlane; it does not establish impact on external systems.

1. Upgrade InvoicePlane to 1.7.2, which the project advisory identifies as patched. Do not treat another release or branch as safe without separate confirmation.
2. If an upgrade cannot be completed, change the authorization layer to revalidate ip_users.user_type on every administrative request, or use a server-side role cache that is reliably invalidated when roles change.
3. When an account's role changes, destroy or force-rotate all active sessions for that account so the change takes effect immediately.
4. Do not reintroduce protected fields such as user_type directly from request data. Apply role changes through an explicit administrative workflow with authorization checks and audit logging.
5. While remediating, review accounts that were downgraded and require reauthentication. Reducing session lifetime and rotating the session identifier can reduce the lifetime of stale authorization, but these measures do not replace correcting the authorization check.

• Inventory InvoicePlane deployments and identify installations within the affected pre-patch range. Compare the deployed source with the version recorded in asset inventory.
• Review ip_users.user_type changes for accounts with active sessions, especially cases where an administrator is downgraded but the account continues to generate administrative requests.
• If application audit logging is available, correlate role-downgrade events with requests to functions protected by Admin_Controller and with activity in the Users controller.
• Review requests to Users::form() that change user_type, especially when an account that was just downgraded later has database value 1 again.
• Inspect the source or configuration to determine whether administrative authorization re-reads ip_users.user_type or trusts the session's user_type value.
• During investigation, force logout or invalidate sessions for accounts whose privileges were recently reduced. The absence of matching log evidence does not prove that a stale session was not used.