fix: IDOR in IssueBulkUpdateDateEndpoint (GHSA-4q54-h4x9-m329) - #8834
Conversation
The bulk update date endpoint fetched issues by ID without filtering by workspace or project, allowing any authenticated project member to modify start_date and target_date of issues in any workspace/project across the entire instance (IDOR - CWE-639). Scoped the query to include workspace__slug and project_id filters, consistent with other issue endpoints in the codebase. Ref: GHSA-4q54-h4x9-m329 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
📝 WalkthroughWalkthroughThe bulk issue date update endpoint now applies additional filtering constraints ( Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
Fixes an insecure direct object reference (IDOR) in the API endpoint that bulk-updates issue start_date / target_date by ensuring the issue lookup is scoped to the current workspace and project.
Changes:
- Scope
IssueBulkUpdateDateEndpointbulk issue fetch toworkspace__slugandproject_idto prevent cross-workspace/project updates.
| # Fetch all relevant issues in a single query | ||
| issues = list(Issue.objects.filter(id__in=issue_ids)) | ||
| issues = list(Issue.objects.filter(id__in=issue_ids, workspace__slug=slug, project_id=project_id)) | ||
| issues_dict = {str(issue.id): issue for issue in issues} |
There was a problem hiding this comment.
This endpoint fetches issues via the default Issue.objects manager. Unlike Issue.issue_objects, this will include triage/archived/draft issues (see IssueManager.get_queryset()), which is inconsistent with other issue endpoints in this file that operate on Issue.issue_objects. If bulk date updates should only apply to “active” issues, consider switching this query to Issue.issue_objects.filter(...) (and keep the same workspace/project scoping). If the broader scope is intentional, it’d help to document why here to avoid future authorization/behavior inconsistencies.
…makeplane#8834) The bulk update date endpoint fetched issues by ID without filtering by workspace or project, allowing any authenticated project member to modify start_date and target_date of issues in any workspace/project across the entire instance (IDOR - CWE-639). Scoped the query to include workspace__slug and project_id filters, consistent with other issue endpoints in the codebase. Ref: GHSA-4q54-h4x9-m329 (cherry picked from commit a01b51f)
…makeplane#8834) The bulk update date endpoint fetched issues by ID without filtering by workspace or project, allowing any authenticated project member to modify start_date and target_date of issues in any workspace/project across the entire instance (IDOR - CWE-639). Scoped the query to include workspace__slug and project_id filters, consistent with other issue endpoints in the codebase. Ref: GHSA-4q54-h4x9-m329
Summary
IssueBulkUpdateDateEndpointwhere the issue query was not scoped to the current workspace and projectstart_dateandtarget_dateof issues in any other workspace/project across the entire instanceIssue.objects.filter()query to includeworkspace__slugandproject_id, consistent with all other issue endpointsSecurity Details
apps/api/plane/app/views/issue/base.pyRoot Cause
The query at line 1121 used
Issue.objects.filter(id__in=issue_ids)without constraining byworkspace__slug=slugandproject_id=project_id. This allowed cross-workspace/cross-project issue date modification.Fix
Test plan
Summary by CodeRabbit