CVE-2026-104969

In Plane prior to 1.4.0, multiple issue-listing endpoints, including unauthenticated public deploy boards, pass the user-controlled order_by parameter to Django's order_by without allowlist validation. An attacker can use double-underscore relationship traversal to reference arbitrary related model fields, revealing database schema details through errors and potentially disclosing field values through differential ordering. Fixed in version 1.4.0.

A vulnerability in Plane before version 1.4.0 involves failure to sanitize unsafe URL schemes in comments (comment_html). A project member can store a crafted link in a comment, and attacker-controlled script executes in the browser of another user who clicks the link. The issue is fixed in version 1.4.0.

In self-hosted Plane deployments prior to 1.4.0, unauthenticated GET requests to api/workspaces/{slug}/invitations/{pk}/join/ through WorkspaceJoinEndpoint expose the secret invitation token directly and through get_invite_link. An external attacker can retrieve a token intended for another user and submit it to the invitation acceptance flow, joining the workspace without receiving the invitation and gaining the role assigned to the invite. Fixed in version 1.4.0.

In Plane prior to 1.4.0, the aPITokenLogMiddleware logs API keys in plaintext. This allows someone with low privileges to steal user API keys and further escalate their privileges.

Plane prior to 1.4.0, the deployments/aio/community/ and deployments/cli/community/ manifests provide fixed, publicly known SECRET_KEY and LIVE_SERVER_SECRET_KEY defaults that remain active when operators do not override them. Knowledge of SECRET_KEY enables attackers to forge Django-signed values and compromise accounts or sessions. Knowledge of LIVE_SERVER_SECRET_KEY bypasses live-service authentication on unchanged community deployments.

Plane prior to 1.4.0 trusts email addresses returned by Gitea OAuth and by self-managed GitLab OAuth deployments where email confirmation is disabled, without verifying that the provider authenticated ownership of the address. An attacker can set an OAuth identity's unverified provider email to a victim's address, which Plane matches directly to the victim's existing local account. The attacker can then log in to the victim's Plane account without knowing the victim's password. GitHub, GitLab.com, and Google are not affected because those providers return verified email addresses.

Plane prior to 1.4.0, the signup flow creates a logged-in User row for any submitted email without an out-of-band ownership check, while User.email is unique=True. The authenticated user can call GET /api/users/me/workspaces/invitations/, which returns each WorkspaceMemberInvite whose email matches request.user.email. WorkSpaceMemberInviteSerializer uses fields = "all", exposing the token that protects the invitation join endpoint. An unauthenticated attacker who knows a target's email can register an account using that address, enumerate pending invitations, and accept an invitation as the target, joining a workspace at the invited role.

Plane prior to 1.4.0, the magic-code email login uses a six-digit numeric OTP with approximately 20 bits of entropy. The verifier has no per-code failed-attempt counter, and an incorrect code does not increment a counter, invalidate the Redis entry, or lock the email address. The verifier extends django.views.View rather than DRF's APIView, so the configured AnonRateThrottle limit does not apply. The middleware stack also contains no Django-level rate limiter such as django-ratelimit, django-axes, or an IP-throttling middleware.

Prior to version 1.4.0 of Plane, the ProjectBulkAssetEndpoint.post endpoint did not constrain asset queries to the project from the URL. A workspace Guest could provide asset UUIDs from another project in the same workspace and reassign them to an attacker-controlled entity, allowing file hijacking.

Prior to version 1.4.0 of Plane, the webhook delivery task did not set allow_redirects=False and did not validate redirect targets. A user with workspace creation rights could register a webhook pointing to an attacker-controlled public endpoint that returns a 302 redirect to an internal address, allowing access to internal resources including cloud metadata.