CVE-2026-39374
Authorization Bypass in Plane Allows Cross-Project Issue Date Modification
Publication date: 2026-04-07
Last updated on: 2026-04-15
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| plane | plane | to 1.3.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-639 | The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-39374 is an Insecure Direct Object Reference (IDOR) vulnerability in the Plane project management software, specifically in the IssueBulkUpdateDateEndpoint API endpoint.
This endpoint allows authenticated users with ADMIN or MEMBER roles in any project within a workspace to bulk update the start_date and target_date fields of issues.
The vulnerability arises because the endpoint fetches issues solely by their IDs without filtering by workspace or project, enabling users to modify issue dates across different projects and workspaces where they are not members.
This breaks workspace isolation, a critical security boundary in multi-tenant environments, allowing unauthorized cross-project and cross-workspace modification of issue scheduling data.
How can this vulnerability impact me? :
An authenticated user with ADMIN or MEMBER role in any project can modify the start_date and target_date of issues belonging to any other project or workspace within the Plane instance.
This undermines data integrity by allowing unauthorized changes to issue scheduling information.
It also breaks workspace isolation, potentially leading to confusion, mismanagement of project timelines, and unauthorized interference with other teams' work.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows authenticated users with ADMIN or MEMBER roles in any project to modify issue dates across all projects and workspaces within the Plane instance, breaking workspace isolation and undermining data integrity.
Such unauthorized cross-boundary data modification can lead to violations of data protection principles required by common standards and regulations like GDPR and HIPAA, which mandate strict access controls and data segregation to protect sensitive information.
By enabling users to alter data outside their authorized scope, the vulnerability increases the risk of unauthorized data manipulation, potentially resulting in non-compliance with these regulations.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for unauthorized or suspicious POST requests to the IssueBulkUpdateDateEndpoint, specifically to the endpoint path: POST /api/workspaces/<slug>/projects/<project_id>/issue-dates/.
A practical detection method is to look for requests where an authenticated user with ADMIN or MEMBER role attempts to update issue dates for issues outside their own workspace or project.
A sample command to test or detect exploitation attempts is a curl command that sends a POST request with issue IDs that do not belong to the user's workspace or project, for example:
- curl -X POST https://<plane-instance>/api/workspaces/<your-slug>/projects/<your-project-id>/issue-dates/ -H 'Authorization: Bearer <token>' -H 'Content-Type: application/json' -d '{"issue_ids": ["<victim-issue-uuid>"], "start_date": "2026-01-01", "target_date": "2026-02-01"}'
If the request succeeds in modifying issues outside the user's authorized scope, it indicates the presence of the vulnerability.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade the Plane software to version 1.3.0 or later, where this vulnerability is fixed.
Until the upgrade can be performed, restrict access to the IssueBulkUpdateDateEndpoint by limiting project membership privileges, ensuring only trusted users have ADMIN or MEMBER roles.
Additionally, monitor logs for suspicious bulk update requests to the issue-dates endpoint and consider implementing network-level controls or application firewalls to block unauthorized requests.