/

CVE-2026-104974

Severity:

HIGH RISK

(8.1)

Improper Access Control (CWE-284) in Plane Accounts

CVE-2026-104974

Deferred

Vulnerability type

Category:

Improper Access Control

CWE:

CWE-284

Impact:

Unauthorized Account Reactivation and Access

Severity:

HIGH RISK

(8.1)

CVSS version:

3.1

Catch this CVE while code is being written

Detect vulnerable code directly in pull requests, so CVEs are fixed before merge.

Summary

Plane accounts that have been deactivated may still authenticate with existing credentials, and successful login can silently reactivate the account. This can allow a former or unauthorized user to regain access without administrator awareness when the affected authentication flow is reachable.

Plane accounts that have been deactivated may still authenticate with existing credentials, and successful login can silently reactivate the account. This can allow a former or unauthorized user to regain access without administrator awareness when the affected authentication flow is reachable.

Affected context

The issue occurs in Plane deployments using versions before 1.4.0 when an account is deactivated by setting its active status to false. If the user still possesses valid credentials and can reach the login flow, authentication may restore the account's active status without an explicit administrative approval or notification.

The issue occurs in Plane deployments using versions before 1.4.0 when an account is deactivated by setting its active status to false. If the user still possesses valid credentials and can reach the login flow, authentication may restore the account's active status without an explicit administrative approval or notification.

Exploit preconditions

  • Attack surface: Plane's user authentication endpoint
  • Required access: Valid credentials for an account that has been deactivated
  • Trigger point: Successful login using the existing credentials
  • Why exploitation is possible: Authentication does not consistently enforce the deactivated state and may change it back to active as a side effect
  • Attack surface: Plane's user authentication endpoint
  • Required access: Valid credentials for an account that has been deactivated
  • Trigger point: Successful login using the existing credentials
  • Why exploitation is possible: Authentication does not consistently enforce the deactivated state and may change it back to active as a side effect

Why this happens

The authentication workflow treats possession of valid credentials as sufficient for access without reliably enforcing the account's administrative active-status control. Its login-side state transition can overwrite a deactivation decision, which maps to CWE-284: Improper Access Control because an authorization-relevant restriction is not consistently honored.

The authentication workflow treats possession of valid credentials as sufficient for access without reliably enforcing the account's administrative active-status control. Its login-side state transition can overwrite a deactivation decision, which maps to CWE-284: Improper Access Control because an authorization-relevant restriction is not consistently honored.

Potential impact

  • A deactivated user may regain access to Plane
  • Former users may retain access after their accounts are disabled
  • Administrative account lifecycle controls could be bypassed
  • Unauthorized activity may continue without immediate administrator notification
  • Project data and management functions may be exposed according to the account's permissions
  • A deactivated user may regain access to Plane
  • Former users may retain access after their accounts are disabled
  • Administrative account lifecycle controls could be bypassed
  • Unauthorized activity may continue without immediate administrator notification
  • Project data and management functions may be exposed according to the account's permissions

General mitigation guidance

Mitigation generally focuses on making account deactivation authoritative across every authentication and session-establishment path.

Common defensive patterns include:

  • Rejecting authentication for accounts marked inactive before creating a session
  • Separating authentication success from authorization and account-state checks
  • Preventing login handlers from silently changing administrator-controlled account status
  • Requiring explicit, auditable administrative action for account reactivation
  • Invalidating existing sessions and tokens when an account is deactivated
  • Applying least privilege so deactivated or stale accounts cannot retain unnecessary access
  • Recording and alerting on authentication attempts involving inactive accounts

Mitigation generally focuses on making account deactivation authoritative across every authentication and session-establishment path.

Common defensive patterns include:

  • Rejecting authentication for accounts marked inactive before creating a session
  • Separating authentication success from authorization and account-state checks
  • Preventing login handlers from silently changing administrator-controlled account status
  • Requiring explicit, auditable administrative action for account reactivation
  • Invalidating existing sessions and tokens when an account is deactivated
  • Applying least privilege so deactivated or stale accounts cannot retain unnecessary access
  • Recording and alerting on authentication attempts involving inactive accounts

How teams detect issues like this

Organizations can identify similar weaknesses through:

  • Static analysis and code review of authentication flows for writes to authorization-related account fields
  • Tests that verify inactive accounts cannot authenticate or obtain new sessions
  • Review of session invalidation behavior after account deactivation
  • Audit-log policies that detect successful logins or status changes involving inactive accounts
  • Integration tests covering account lifecycle transitions, including deactivation, login, and reactivation
  • Automated security review tools that flag authentication paths which mutate privilege or account-state controls

Organizations can identify similar weaknesses through:

  • Static analysis and code review of authentication flows for writes to authorization-related account fields
  • Tests that verify inactive accounts cannot authenticate or obtain new sessions
  • Review of session invalidation behavior after account deactivation
  • Audit-log policies that detect successful logins or status changes involving inactive accounts
  • Integration tests covering account lifecycle transitions, including deactivation, login, and reactivation
  • Automated security review tools that flag authentication paths which mutate privilege or account-state controls

Sources

SourceLink
github.comgithub.com/makeplane/plane/commit/1e8f3630c7697129b61eb57f2453f0bf09224920
github.comgithub.com/makeplane/plane/commit/6c9dbb50434d16ea00a00d1574723dfd0c3d2446
github.comgithub.com/makeplane/plane/pull/9290
github.comgithub.com/makeplane/plane/pull/9304
github.comgithub.com/makeplane/plane/releases/tag/v1.4.0
github.comgithub.com/makeplane/plane/security/advisories/GHSA-rmmf-rj2q-3rrg

Frequently asked

questions

Yes, where the Plane authentication endpoint is network-accessible and an attacker has valid credentials for a deactivated account. The issue does not by itself provide credentials.

The key prerequisite is possession of existing, valid credentials belonging to an account that an administrator has deactivated.

Treat the inactive account state as an authoritative authorization decision, reject login before session creation, and prevent authentication from silently reactivating the account.

Test account lifecycle controls end to end, invalidate sessions during deactivation, require explicit reactivation workflows, and monitor authentication and status changes involving inactive accounts.

Yes, where the Plane authentication endpoint is network-accessible and an attacker has valid credentials for a deactivated account. The issue does not by itself provide credentials.

The key prerequisite is possession of existing, valid credentials belonging to an account that an administrator has deactivated.

Treat the inactive account state as an authoritative authorization decision, reject login before session creation, and prevent authentication from silently reactivating the account.

Test account lifecycle controls end to end, invalidate sessions during deactivation, require explicit reactivation workflows, and monitor authentication and status changes involving inactive accounts.

Find out what's already
exploitable in your codebase.