Summary
YesWiki contains an authorization bypass in ApiService::isAuthorized() that may allow unauthenticated users to access administrator-only API routes when public API mode is enabled. Successful exploitation could let attackers overwrite configuration or list, download, and delete backup archives.
Affected context
The vulnerability occurs in YesWiki deployments where public API mode is enabled and authorization checks for administrative API routes do not correctly distinguish unauthenticated requests. Affected functionality includes configuration update and archive-management endpoints, such as api/ci/update_config and api/archives. The practical risk depends on which routes are exposed and what permissions the application process has.
Exploit preconditions
- Attack surface: HTTP-accessible YesWiki API routes
- Required access: No authenticated account may be required when public API mode is enabled
- Trigger point: Requests to administrative API endpoints handled by
ApiService::isAuthorized() - Why exploitation is possible: The authorization decision can incorrectly permit unauthenticated access to routes intended for administrators
Why this happens
The underlying bug is an authorization enforcement failure mapped to CWE-862: Missing Authorization. The affected authorization logic does not reliably require an appropriate authenticated identity and privilege level before allowing administrative API operations. This creates an insecure pattern in which route exposure is treated as sufficient authorization, allowing public requests to reach privileged functionality.
Potential impact
- Attackers may overwrite application configuration
- Sensitive backup archives could be listed or downloaded
- Existing backup archives may be deleted
- Application availability or behavior could be disrupted
- Configuration changes could enable follow-on compromise depending on deployment settings
General mitigation guidance
Mitigation generally focuses on enforcing authorization independently for every administrative operation and reducing the trust placed in public API exposure.
Defensive patterns include:
- Require authenticated, explicitly privileged identities for configuration and archive-management routes
- Apply deny-by-default authorization policies to administrative API endpoints
- Keep public API functionality limited to narrowly scoped, non-administrative operations
- Validate both authentication state and required role or capability at the service boundary
- Restrict access to backup storage and avoid exposing archives through broadly reachable application routes
- Run the application with only the filesystem and service privileges it needs
- Record and review authorization failures and sensitive administrative actions
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and code review checks for authorization helpers that return success without a verified identity or privilege
- Review of route definitions to identify administrative endpoints reachable through public API modes
- Tests that exercise sensitive routes as anonymous, ordinary-user, and administrator identities
- Monitoring for unauthenticated requests to configuration and archive-management endpoints
- Policy enforcement requiring explicit authorization annotations or middleware on privileged routes
- Automated security testing that checks for missing function-level access controls
