CVE-2026-88003 InvoicePlane Session Flaw

An authenticated user’s privileges could remain active after an administrator downgraded their account. The issue was caused by the application trusting the user_type stored in an existing session instead of revalidating the user’s current role against the database on each request.
The vulnerability was fixed in InvoicePlane 1.7.2.

---

What Is CVE-2026-88003?​

CVE-2026-88003 is a session privilege escalation vulnerability affecting InvoicePlane.
The problem is related to how the application handled administrator sessions after a user’s role was changed.
When an administrator downgraded another administrator to a lower-privileged account, the database was updated correctly. However, the existing session was not invalidated or refreshed.

This created a mismatch:

• The database showed the user as a Guest.
• The active session still contained the previous Admin privilege.
• Subsequent requests continued to use the stale session data.
• The downgraded account could therefore retain administrative access.

🔐 In other words, changing the account role did not immediately remove the privileges already stored in the user’s active session.

---

How the Vulnerability Works​

The issue comes from trusting session data that was created during login.
A simplified flow looks like this:

1. An administrator logs in.
2. The application stores the user’s role in the session.
3. The administrator receives Admin privileges.
4. Another administrator downgrades that account to Guest.
5. The database is updated successfully.
6. The existing session is not invalidated or refreshed.
7. The application continues trusting the old session value.
8. The user can continue accessing functionality that requires administrator privileges.

The important security issue is the gap between the current authorization state in the database and the stale authorization state stored in the session.

---

Why Session Invalidation Matters​

Session data should not be treated as permanently valid authorization information when an account’s privileges can change.
For example, imagine the database contains:

user_type = Guest

But the active session still contains:

user_type = Admin

If authorization checks rely on the session value, the application may make the wrong security decision.

A safer design should ensure that sensitive privilege changes trigger appropriate session handling, such as:

• Invalidating existing sessions.
• Refreshing authorization information.
• Rechecking the user’s current privileges.
• Preventing stale sessions from retaining elevated permissions.

This is especially important for administrative accounts because a role downgrade should take effect immediately.

---

Impact of CVE-2026-88003​

The core impact is continued administrative access after an administrator account has been downgraded.
The vulnerability does not simply involve outdated profile information. The stale session can preserve authorization privileges that the account should no longer have.
That makes session management part of the application's authorization boundary.
⚠️ If an application allows administrators to change roles dynamically, authorization state should not remain trusted indefinitely inside an old session.

---

Fixed in InvoicePlane 1.7.2​

The vulnerability was fixed in InvoicePlane 1.7.2.
If you are running an affected version, upgrading to the patched release is the recommended way to address the issue.
Administrators should also consider reviewing existing sessions after upgrading, especially when deploying a security fix related to authentication or authorization.

---

Security Lesson for Developers​

This vulnerability highlights an important rule in web application security:
Authentication and authorization are not the same thing.
A session can prove that a user has authenticated, but authorization decisions should remain consistent with the user’s current privileges.
If an application allows roles to change while users are logged in, developers should carefully consider what happens to existing sessions.

A robust implementation should define what happens when:

• An administrator account is downgraded.
• A user's permissions are revoked.
• A user is removed from an administrative group.
• An account is disabled.
• Sensitive permissions are changed.

🔎 These changes should not leave an older session with privileges that the database no longer grants.

---

CVE and Advisory References​

You can find the official vulnerability information in the following resources:
🔗 CVE Record: https://www.cve.org/CVERecord?id=CVE-2026-88003
🔗 GitHub Security Advisory: https://github.com/InvoicePlane/InvoicePlane/security/advisories/GHSA-25xj-pj36-wpp8

---

Conclusion​

CVE-2026-88003 is a good example of how seemingly simple session-management decisions can become authorization vulnerabilities.
The database correctly changed the user's role, but the existing session continued to carry the old administrative privileges.
The fix is available in InvoicePlane 1.7.2, and developers working on role-based access control should always consider how privilege changes affect already-authenticated sessions.
🛡️ A role change should take effect everywhere-not just in the database.

---

Frequently Asked Questions​

----------------

What is CVE-2026-88003?​

CVE-2026-88003 is a session privilege escalation vulnerability in InvoicePlane caused by stale authorization information remaining in an active session after a user's role was downgraded.

What causes the vulnerability?​

The application relied on the user_type stored in the existing session without properly invalidating or refreshing that session after the user's role changed.

What happens when an administrator is downgraded?​

The database role changes to a lower privilege level, but the existing session may continue to contain the previous Admin role and retain administrative access.

Which version fixes CVE-2026-88003?​

The vulnerability was fixed in InvoicePlane 1.7.2.

How can developers prevent similar vulnerabilities?​

Applications should properly invalidate or refresh active sessions when privileges change and should avoid blindly trusting stale session authorization data for sensitive access-control decisions.