Summary
PraisonAI Platform permits any workspace member to permanently delete resources created by the workspace owner or other members because its deletion endpoints check membership but not ownership or role permissions. A malicious or compromised member account could therefore erase projects, agents, issues, labels, dependencies, and issue-label attachments across the workspace.
PraisonAI Platform permits any workspace member to permanently delete resources created by the workspace owner or other members because its deletion endpoints check membership but not ownership or role permissions. A malicious or compromised member account could therefore erase projects, agents, issues, labels, dependencies, and issue-label attachments across the workspace.
Affected context
The issue affects PraisonAI Platform deployments in the affected version range
where workspace members can access resource deletion endpoints. The endpoints
verify that the requester belongs to the workspace, but do not consistently
verify resource ownership or require a role with deletion authority. As a
result, member-level access may extend to content created by other members or
by the workspace owner.
The issue affects PraisonAI Platform deployments in the affected version range
where workspace members can access resource deletion endpoints. The endpoints
verify that the requester belongs to the workspace, but do not consistently
verify resource ownership or require a role with deletion authority. As a
result, member-level access may extend to content created by other members or
by the workspace owner.
Exploit preconditions
- Attack surface: Authenticated workspace resource deletion endpoints
- Required access: A valid account with membership in the target workspace
- Trigger point: A DELETE request targeting a project, agent, issue, label,
issue dependency, or issue-label attachment
- Why exploitation is possible: Authorization is limited to workspace
membership and does not enforce ownership, role, or resource-specific
deletion permissions
- Attack surface: Authenticated workspace resource deletion endpoints
- Required access: A valid account with membership in the target workspace
- Trigger point: A DELETE request targeting a project, agent, issue, label,
issue dependency, or issue-label attachment
- Why exploitation is possible: Authorization is limited to workspace
membership and does not enforce ownership, role, or resource-specific
deletion permissions
Why this happens
The underlying bug is an authorization design failure. The application treats
workspace membership as sufficient permission to perform destructive actions,
without applying an object-level ownership or role check to the targeted
resource. This behavior maps to CWE-285: Improper Authorization, because
authenticated users can perform actions outside the authority granted by their
role or relationship to the resource.
The underlying bug is an authorization design failure. The application treats
workspace membership as sufficient permission to perform destructive actions,
without applying an object-level ownership or role check to the targeted
resource. This behavior maps to CWE-285: Improper Authorization, because
authenticated users can perform actions outside the authority granted by their
role or relationship to the resource.
Potential impact
- A malicious or compromised member account could permanently delete workspace
content
- Projects, agents, issues, labels, and related associations could be wiped
- Teams could lose operational data and work-tracking history
- Deletion activity could disrupt collaboration and downstream workflows
- Recovery may be limited if backups or audit-based restoration are unavailable
- A malicious or compromised member account could permanently delete workspace
content
- Projects, agents, issues, labels, and related associations could be wiped
- Teams could lose operational data and work-tracking history
- Deletion activity could disrupt collaboration and downstream workflows
- Recovery may be limited if backups or audit-based restoration are unavailable
General mitigation guidance
Mitigation generally focuses on enforcing authorization at every destructive
resource operation rather than relying on workspace membership alone.
Common defensive patterns include:
- Apply server-side ownership, role, and resource-level permission checks
before processing every DELETE operation
- Separate read, update, and destructive-delete privileges
- Use secure-by-default roles that do not grant deletion authority to ordinary
members
- Require stronger authorization or confirmation controls for bulk or
irreversible actions
- Reduce trust in client-supplied identifiers and resolve authorization from
trusted server-side relationships
- Preserve backups, soft-delete records, or provide controlled restoration
paths where business requirements permit
- Record and monitor destructive actions with actor, target, and authorization
context
Mitigation generally focuses on enforcing authorization at every destructive
resource operation rather than relying on workspace membership alone.
Common defensive patterns include:
- Apply server-side ownership, role, and resource-level permission checks
before processing every DELETE operation
- Separate read, update, and destructive-delete privileges
- Use secure-by-default roles that do not grant deletion authority to ordinary
members
- Require stronger authorization or confirmation controls for bulk or
irreversible actions
- Reduce trust in client-supplied identifiers and resolve authorization from
trusted server-side relationships
- Preserve backups, soft-delete records, or provide controlled restoration
paths where business requirements permit
- Record and monitor destructive actions with actor, target, and authorization
context
How teams detect issues like this
Detection can combine code review, automated analysis, and runtime monitoring.
Useful approaches include:
- Review every DELETE handler for explicit ownership, role, and object-level
authorization checks
- Use static analysis to identify endpoints that check authentication or
membership without checking permissions on the target object
- Test each resource type with users holding different workspace roles and
ownership relationships
- Add policy checks that require authorization middleware on destructive routes
- Monitor audit logs for unusual deletion volume, cross-owner deletion, or
repeated deletion attempts by ordinary members
- Use automated security testing and access-control regression suites to verify
deny-by-default behavior
Detection can combine code review, automated analysis, and runtime monitoring.
Useful approaches include:
- Review every DELETE handler for explicit ownership, role, and object-level
authorization checks
- Use static analysis to identify endpoints that check authentication or
membership without checking permissions on the target object
- Test each resource type with users holding different workspace roles and
ownership relationships
- Add policy checks that require authorization middleware on destructive routes
- Monitor audit logs for unusual deletion volume, cross-owner deletion, or
repeated deletion attempts by ordinary members
- Use automated security testing and access-control regression suites to verify
deny-by-default behavior
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
