EUVD-2026-92482Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate with retained deactivated owner account
-
ExploitRequest workspace owner-protected endpoint
-
ExecutionPermission check omits is_active gate
-
ImpactRetain owner-level workspace control
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires an attacker-controlled account that was previously assigned the workspace owner (Admin) role and was subsequently deactivated, plus the ability to authenticate with that account against a Plane instance prior to 1.4.0. The flaw is that WorkspaceOwnerPermission.has_permission() queries workspace membership by role=Admin without filtering is_active=True, so deactivated owners remain authorized. A key amplifier in affected versions: the authentication adapter (base.py save_user_data) automatically reactivated inactive accounts on login, removing a would-be barrier. Limiting factors: the attacker cannot be an arbitrary unauthenticated outsider - they must possess valid credentials for a formerly-owner account, so impact is confined to insider/offboarding-abuse scenarios rather than broad remote compromise. |
| Impact | This is a moderate, access-control defect (CWE-863) rather than a high-urgency crisis. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, base 5.4) indicates a network-reachable, low-complexity issue requiring an existing low-privilege authenticated account (PR:L) - specifically a user who was previously a workspace owner. No EPSS score, SSVC decision, KEV listing, or POC was supplied in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The practical risk is bounded by a significant precondition: the attacker must already have held a workspace owner (Admin role) account that was subsequently deactivated, and must still be able to authenticate. The source diff reveals a compounding factor worth noting - base.py's save_user_data() previously reactivated deactivated accounts on login (GHSA-rmmf-rj2q-3rrg), which materially lowered the barrier to abusing this authorization gap before 1.4.0. Net: treat as a prompt-but-not-emergency patch priority for self-hosted Plane operators who rely on account deactivation as an offboarding control; it is not a mass-exploitable internet-wide threat. |
| Exploit ScenarioDerived | An organization offboards an employee by deactivating their Plane account, but that person had been a workspace owner. Because WorkspaceOwnerPermission did not check is_active=True, the deactivated former owner can still authenticate and continue exercising owner-level control over the workspace (and, prior to the fix, logging in silently reactivated their account). No public exploit code was identified; the attack simply requires the retained credentials. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 05, 2026
Deactivated workspace owners retain owner-level administrative access in Plane project management instances prior to version 1.4.0. The WorkspaceOwnerPermission check queries workspace membership with role=Admin but omits the is_active=True filter, so a formerly-owner account that has been deactivated is still treated as an authorized owner; an attacker who holds valid credentials for such an account - an offboarding or insider-abuse scenario, not a broad unauthenticated compromise - can keep exercising administrative control. The impact is amplified because the authentication adapter (base.py save_user_data) automatically reactivated inactive accounts on login in affected versions, and the fix in 1.4.0 adds the missing is_active check and rejects deactivated logins. No public exploit code has been identified at time of analysis and this issue is not confirmed in CISA KEV; the vendor-released patch is version 1.4.0.
RemediationAI
Upgrade to Plane 1.4.0, the vendor-released patch: it adds is_active=True to the Admin membership query in both workspace permission modules and adds an explicit deactivated-account rejection (USER_ACCOUNT_DEACTIVATED) in the authentication adapter before any session or save logic runs, closing the auto-reactivation behavior. See advisory GHSA-wjgv-cq7w-258v, PR #9290, commit 6c9dbb50434d16ea00a00d1574723dfd0c3d2446, and https://github.com/makeplane/plane/releases/tag/v1.4.0. If the upgrade cannot be applied immediately, compensating controls: for departing or suspended staff, remove or demote the workspace Admin role membership itself rather than only deactivating the account, since role rows are what the vulnerable check evaluated - trade-off is that permanent role changes complicate temporary suspensions and must be reversed on reinstatement; and restrict network/identity-layer access to owner-only administrative API endpoints so former-owner credentials cannot reach the permission-checked views - trade-off is reduced administrative flexibility and dependence on network controls. Because affected authentication adapters silently reactivated inactive accounts on login, the patch or equivalent blocking of that login path is essential until the fix is in place. Note that, per CVSS PR:L, exploitation requires an authenticated account (specifically valid credentials for a formerly-owner account), and no public exploit code has been identified at time of analysis.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
This is an incorrect-authorization defect (CWE-863) in Plane, an open-source Django/Django-REST-Framework project management tool. Workspace owner authorization is implemented in a DRF permission class, WorkspaceOwnerPermission.has_permission(), which resolves the current user's workspace membership by filtering on workspace__slug and role=Admin. The original query omitted is_active=True, so a membership row whose underlying user had been deactivated still satisfied the owner check and granted access to owner-restricted views. The same flawed filter appears in two mirrored modules, apps/api/plane/app/permissions/workspace.py and apps/api/plane/utils/permissions/workspace.py. A second, compounding flaw lived in the authentication adapter apps/api/plane/authentication/adapter/base.py: save_user_data() unconditionally set user.is_active = True on login (and dispatched an activation email), meaning that even if deactivation were meant to be the barrier, signing in silently reactivated the account. Both are corrected in 1.4.0 - the permission queries now include is_active=True and complete_login_or_signup() raises AuthenticationException with USER_ACCOUNT_DEACTIVATED before any session or save logic executes. The affected product is cpe:2.3:a:makeplane:plane:*:*:*:*:*:*:*:* (all versions before 1.4.0).
Know when Plane gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Retained workspace-owner access grants full read/write control over workspace data (C:H/I:H), but requires a valid though deactivated account, so PR:L and AC:L; no availability impact.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
1DescriptionCVE.org
Plane is an open-source project management tool. Prior to 1.4.0, WorkspaceOwnerPermission does not require is_active=True when checking whether a user is a workspace owner. A deactivated user can therefore remain authorized as the workspace owner and retain owner-level access. This issue is fixed in 1.4.0.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
GitHub
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Cross-workspace authorization bypass in Plane (makeplane) prior to version 1.3.1 allows any authenticated user of one wo
Plane version 0.7.1 allows an unauthenticated attacker to view all stored server files of all users. Rated high severity
Authenticated users who can create a workspace in Plane can force the application's background worker to fetch internal-
Unauthenticated remote attackers can forge Django-signed session cookies, CSRF tokens, and password-reset tokens, and by
Workspace invitation hijacking in Plane prior to 1.4.0 lets an unauthenticated attacker take over a pending workspace in
Plane is an open-source project management tool. Rated medium severity (CVSS 5.8), this vulnerability is remotely exploi
Plane (makeplane/plane) through version 1.4.2 makes security decisions based on the client-supplied X-Forwarded-For head
Improper authorization in Plane before 1.4.0 lets an authenticated workspace Guest hijack file assets from other project
Account takeover in Plane (makeplane) versions prior to 1.4.0 allows remote unauthenticated attackers to log in as exist
Brute-forceable magic-code email login in Plane versions prior to 1.4.0 allows unauthenticated remote attackers to guess
Server-side request forgery in Plane, the open-source project management tool, allows a low-privilege user of a connecte
Authenticated cross-workspace access control bypass in Plane (makeplane/plane) before version 1.4.0 lets any user with a
Exploit-DB