Project guests can modify workflow states (rename, change group)

[avisprince]

Project guests can modify workflow states (rename, change group)

What we observed

Workflow states in a project control the issue lifecycle (Backlog → Todo → In Progress → Done → Cancelled). Creating, deleting, and marking a state as default all require the ADMIN role. However, updating an existing state (renaming, changing its color, or reassigning its group) is open to ADMIN, MEMBER, and GUEST roles.

1. Guest renames a state

We added a user to a project with the GUEST role (role level 5). The guest sent a PATCH request to change the name of the "Backlog" state to "GUEST-MODIFIED-STATE." The request succeeded with 200 and the state name was updated. We verified at the database level that the name had been overwritten.

2. Guest changes a state's group

The same guest sent a PATCH request changing the state's group field from backlog to completed. This succeeded, effectively reclassifying a backlog state as a completion state. Any issues in that state would now be counted as "completed" in cycle and project analytics.

Impact

• A guest user can rename workflow states, causing confusion across the project for all members
• A guest can reclassify state groups (e.g., move a "backlog" state to "completed"), corrupting cycle progress metrics and analytics dashboards
• State modification is a project-level configuration change that should require admin privileges, consistent with create/delete/mark-as-default which already enforce admin-only access

Steps to reproduce

Environment:

• makeplane/plane-backend:stable
• PostgreSQL 15.7, Valkey 7.2.11, RabbitMQ 3.13.6, MinIO
• ENABLE_EMAIL_PASSWORD=1, ENABLE_SIGNUP=1

Setup:

1. Complete instance admin sign-up (User A — admin)
2. Sign up a second user (User B — will be the guest)
3. Create a workspace with User A
4. Add User B to the workspace as a MEMBER (role 15)
5. Create a project — this auto-creates default states: Backlog (default), Todo, In Progress, Done, Cancelled, Triage
6. Add User B to the project as GUEST (role 5) via the project members API

Authenticate as User B (session cookie from sign-up).

Control — guest lists states (read access works):

GET /api/workspaces/{slug}/projects/{project_id}/states/
Cookie: sessionid={guest_session}

Returns 200 with the list of states. Guests have read access — this confirms the user is properly authenticated and has project membership.

Control — guest tries to create a state (correctly rejected):

POST /api/workspaces/{slug}/projects/{project_id}/states/
Cookie: sessionid={guest_session}
Content-Type: application/json

{"name": "New State", "color": "#FF0000", "group": "backlog"}

Returns 403 — state creation requires ADMIN. This confirms the role-based access control is active for create operations.

Bug — guest modifies the state name:

PATCH /api/workspaces/{slug}/projects/{project_id}/states/{state_id}/
Cookie: sessionid={guest_session}
Content-Type: application/json

{"name": "GUEST-MODIFIED-STATE"}

Returns 200. The state has been renamed.

Bug — guest changes the state group:

PATCH /api/workspaces/{slug}/projects/{project_id}/states/{state_id}/
Cookie: sessionid={guest_session}
Content-Type: application/json

{"group": "completed"}

Returns 200. The state group has been changed from "backlog" to "completed."

Database verification:

SELECT name, "group" FROM states WHERE id = '{state_id}';

Returns name = 'GUEST-MODIFIED-STATE' and group = 'completed', confirming both mutations persisted.

Reproducing with Dokkimi

Dokkimi is an open-source testing tool that stands up isolated Docker environments from declarative YAML definitions — services, databases, seed data, test steps, and assertions all in one file. The definition for this bug is in dokkimi/dokkimi-in-the-wild/.dokkimi/plane — dokkimi run reproduces it from scratch.