CVE-2026-85291 in InvoicePlane
Summary
by MITRE • 09/25/2026
InvoicePlane is a self-hosted open source application for managing invoices, clients, and payments. Prior to 1.7.2, InvoicePlane's Users::change_password() method accepts a user_id from the URL and updates that account's password without an object-level authorization check. An authenticated secondary administrator can target the primary administrator account and replace its password without knowing the current password. The attacker can then take over the primary account and access its data and privileges. This issue is fixed in version 1.7.2.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/25/2026
InvoicePlane serves as a self-hosted open-source solution for managing invoices, clients, and payments, relying heavily on role-based access control to maintain security boundaries between different user tiers. Within this architecture, the distinction between primary administrators who hold full system privileges and secondary administrators with limited scopes is critical for maintaining operational integrity. Prior to version 1.7.2, a significant flaw existed in the application's authentication module that undermined these fundamental security assumptions by allowing privilege escalation through improper object-level authorization checks.
The core technical vulnerability resides within the Users::change_password() method of the InvoicePlane backend. This endpoint is designed to facilitate password resets or changes for user accounts but fails to validate whether the authenticated requester has the authority to modify the specific account identified in the request parameters. Specifically, the function accepts a user_id directly from the URL input and proceeds to update the corresponding account's credentials without verifying that the current session holder possesses administrative rights over that particular target identity. This lack of object-level authorization allows any authenticated secondary administrator to bypass intended restrictions by simply supplying the identifier for the primary administrator in their request payload.
The operational impact of this flaw is severe, as it enables an attacker with lower-privileged access to perform a complete account takeover of the highest-privilege user on the system. By targeting the primary administrator's account and replacing its password without knowledge of the existing credentials, the secondary administrator can log in using the new password. Once authenticated as the primary admin, the attacker gains unrestricted access to all sensitive data stored within the application, including financial records, client information, and payment details. This effectively nullifies the principle of least privilege that underpins secure multi-user systems, allowing a compromised or malicious low-level user to escalate their privileges arbitrarily and exfiltrate critical business intelligence.
This vulnerability is classified as CWE-284 Improper Access Control because it involves an authorization bypass where access control mechanisms fail to restrict actions based on the identity of the actor relative to the target resource. In terms of offensive security frameworks, this behavior aligns with MITRE ATT&CK technique T1078 Valid Accounts, specifically describing how attackers leverage legitimate credentials obtained through privilege escalation or improper configuration to gain unauthorized access. The flaw represents a classic case of broken object-level authorization where the system trusts client-supplied identifiers without validating them against the permissions associated with the active session token.
To mitigate this risk and prevent similar vulnerabilities in future development cycles, it is essential that all state-changing endpoints implement strict server-side validation of user roles relative to target resources. Developers must ensure that any operation modifying a specific entity's data checks not only for general authentication but also for explicit authorization permissions tied to the resource identifier provided in the request. Upgrading to version 1.7.2 or later is required immediately, as this release includes patches that enforce proper object-level access controls within the password change functionality. Additionally, implementing comprehensive logging and monitoring for administrative actions can help detect anomalous behavior patterns indicative of such exploitation attempts before significant damage occurs.