Summary
iFlytek SkillHub contains a missing authorization check in the skill deletion API, allowing an authenticated user to delete skills owned by other users. Because deletion can remove versions, files, reviews, ratings, and metadata, successful abuse may cause permanent data loss and service disruption.
iFlytek SkillHub contains a missing authorization check in the skill deletion API, allowing an authenticated user to delete skills owned by other users. Because deletion can remove versions, files, reviews, ratings, and metadata, successful abuse may cause permanent data loss and service disruption.
Affected context
The issue affects SkillHub deployments where authenticated users can reach the skill deletion endpoint and the application does not verify ownership or an equivalent permission before processing the request. Target discovery may be possible through an anonymously accessible search function, increasing the exposure of skill identifiers even when deletion itself requires authentication.
The issue affects SkillHub deployments where authenticated users can reach the skill deletion endpoint and the application does not verify ownership or an equivalent permission before processing the request. Target discovery may be possible through an anonymously accessible search function, increasing the exposure of skill identifiers even when deletion itself requires authentication.
Exploit preconditions
- Attack surface: The HTTP skill-management API, specifically the skill deletion route
- Required access: A valid authenticated user account with access to the API
- Target discovery: Skill namespaces and slugs may be identified through the anonymous search endpoint
- Trigger point: A deletion request for another user's skill
- Why exploitation is possible: The deletion operation lacks an effective ownership or permission check before removing associated skill data
- Attack surface: The HTTP skill-management API, specifically the skill deletion route
- Required access: A valid authenticated user account with access to the API
- Target discovery: Skill namespaces and slugs may be identified through the anonymous search endpoint
- Trigger point: A deletion request for another user's skill
- Why exploitation is possible: The deletion operation lacks an effective ownership or permission check before removing associated skill data
Why this happens
The vulnerability results from failing to enforce authorization at the point where a destructive operation is performed. The endpoint appears to authenticate the requester but does not adequately compare the requested resource with the user's ownership or granted privileges, allowing a valid account to act on another user's skill. This behavior maps to CWE-862: Missing Authorization, where access control checks are absent or insufficient for a protected function.
The vulnerability results from failing to enforce authorization at the point where a destructive operation is performed. The endpoint appears to authenticate the requester but does not adequately compare the requested resource with the user's ownership or granted privileges, allowing a valid account to act on another user's skill. This behavior maps to CWE-862: Missing Authorization, where access control checks are absent or insufficient for a protected function.
Potential impact
- An attacker may permanently delete skills belonging to other users
- Multiple skill versions and associated files could be removed
- Reviews, ratings, and metadata may be lost
- Skill availability and dependent workflows could be disrupted
- Organizations could face data integrity, recovery, and reputational impacts
- An attacker may permanently delete skills belonging to other users
- Multiple skill versions and associated files could be removed
- Reviews, ratings, and metadata may be lost
- Skill availability and dependent workflows could be disrupted
- Organizations could face data integrity, recovery, and reputational impacts
General mitigation guidance
Mitigation generally focuses on enforcing authorization for every destructive resource operation and reducing the trust placed in client-supplied identifiers.
Common defensive patterns include:
- Require an ownership, role, or explicit capability check before deletion
- Apply authorization consistently at the service layer rather than relying only on route-level controls
- Use deny-by-default permissions for destructive actions
- Scope resource lookups to the authenticated user's permitted namespace
- Protect anonymous search results from exposing unnecessary sensitive identifiers
- Add confirmation, soft-delete, retention, and recovery mechanisms where appropriate
- Run destructive operations with the minimum service privileges needed
Mitigation generally focuses on enforcing authorization for every destructive resource operation and reducing the trust placed in client-supplied identifiers.
Common defensive patterns include:
- Require an ownership, role, or explicit capability check before deletion
- Apply authorization consistently at the service layer rather than relying only on route-level controls
- Use deny-by-default permissions for destructive actions
- Scope resource lookups to the authenticated user's permitted namespace
- Protect anonymous search results from exposing unnecessary sensitive identifiers
- Add confirmation, soft-delete, retention, and recovery mechanisms where appropriate
- Run destructive operations with the minimum service privileges needed
How teams detect issues like this
Organizations can identify similar weaknesses through:
- Static analysis and authorization-focused rules for destructive API handlers
- Code review checks confirming ownership or capability validation before delete, purge, and update operations
- Integration tests that attempt cross-user access to every resource-management endpoint
- Policy enforcement requiring authorization tests for authenticated APIs
- Monitoring for unusual deletion volume, cross-namespace activity, and repeated resource enumeration
- Automated application security testing that evaluates horizontal privilege boundaries
Organizations can identify similar weaknesses through:
- Static analysis and authorization-focused rules for destructive API handlers
- Code review checks confirming ownership or capability validation before delete, purge, and update operations
- Integration tests that attempt cross-user access to every resource-management endpoint
- Policy enforcement requiring authorization tests for authenticated APIs
- Monitoring for unusual deletion volume, cross-namespace activity, and repeated resource enumeration
- Automated application security testing that evaluates horizontal privilege boundaries
