Summary
YesWiki before 4.6.7 contains an authorization scope bypass in the triples delete API. An authenticated user can submit an empty filter to delete or forge semantic triples, potentially removing administrator group membership and causing a site-wide authorization lockout.
Affected context
The issue occurs in YesWiki deployments that expose the semantic triples deletion functionality and rely on request filters to limit which triples an authenticated user may modify. The risk is present when an empty filter is accepted without enforcing ownership or an equivalent authorization scope, allowing security-sensitive group-membership triples to be affected.
Exploit preconditions
- Attack surface: The authenticated triples deletion API - Required access: A valid YesWiki user account capable of reaching the endpoint - Trigger point: Submission of a deletion request containing an empty filter - Why exploitation is possible: The endpoint fails to apply an effective
authorization scope when the filter is empty, so ownership restrictions may
not constrain the requested operation
Why this happens
The underlying bug is an authorization decision based on an optional filter without safely handling the empty-filter case. When no meaningful selection criteria are supplied, the API can interpret the request too broadly instead of denying it or restricting it to the caller's authorized records. This behavior maps to CWE-863, Incorrect Authorization, because authenticated access is not correctly limited to permitted semantic triples or ownership scope.
Potential impact
- An attacker may delete semantic triples belonging to other users
- An attacker could forge or alter authorization-relevant triples
- Administrator group membership may be removed
- The site could experience a broad authorization lockout
- Stored semantic data and application integrity may be compromised
General mitigation guidance
Mitigation generally centers on deny-by-default authorization and explicit handling of empty or missing filters. APIs should require a non-empty, validated selection scope, enforce ownership and resource-level permission checks independently of client-supplied filters, and protect authorization-relevant triples with stronger administrative controls. Configuration and data mutation paths should minimize trust in authenticated user input, and service accounts should operate with only the privileges required for their functions. Security monitoring and recovery procedures should also cover unexpected changes to group-membership data.
How teams detect issues like this
Detection can include static analysis and code review for deletion logic that treats empty collections or filters as unrestricted queries, as well as checks that authorization is performed independently from record selection. Runtime monitoring can flag empty-filter deletion requests, bulk changes to semantic triples, and modifications involving administrator membership. API policy enforcement can reject unscoped mutation requests, while automated review tools may help identify missing ownership checks and fail-open authorization paths.
