CVE-2026-92774 in Wiki.js
Summary
by MITRE • 09/16/2026
Wiki.js through 2.5.314 omits page tags from authorization checks in multiple GraphQL resolvers, allowing tag-based access restrictions to be bypassed. Attackers can query the list, tree, tags, searchTags, and links resolvers to retrieve restricted page metadata including titles, descriptions, paths, and tag information without proper authorization.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in Wiki.js versions through 2.5.314 represents a critical failure in access control mechanisms within the GraphQL API layer of the application. This flaw specifically affects how the system handles authorization for page tags, which are often used to enforce granular permissions and restrict visibility of sensitive documentation or internal knowledge base entries. In a properly secured implementation, any request that retrieves metadata about pages should verify whether the authenticated user has permission to view those specific items based on their assigned tag-based restrictions. However, in this vulnerable version, multiple GraphQL resolvers fail to perform these necessary authorization checks when processing requests related to tags. This oversight allows an attacker who possesses valid credentials for a low-privilege account or even potentially unauthenticated users depending on the broader configuration to bypass intended security boundaries and access restricted information.
The technical root cause lies in the implementation of several specific GraphQL resolvers, including list, tree, tags, searchTags, and links. These endpoints are designed to provide structured data about wiki pages for navigation, searching, and linking purposes. When a client queries these endpoints, the backend logic retrieves page metadata such as titles, descriptions, file paths, and associated tag information. The security defect occurs because the authorization middleware or permission checking logic is either skipped entirely or incorrectly implemented for these specific resolvers when filtering by tags. Consequently, the system returns comprehensive details about pages that should be hidden from the requesting user based on their role or group membership. This constitutes a classic Broken Access Control vulnerability, aligning with CWE-284 (Improper Access Control) and specifically reflecting patterns found in ATT&CK technique T1078 (Valid Accounts), where an attacker leverages legitimate credentials to access resources they are not authorized to see.
The operational impact of this vulnerability is significant for organizations relying on Wiki.js for secure knowledge management, internal documentation, or sensitive project tracking. By exploiting the bypassed authorization checks, attackers can enumerate restricted pages and extract their metadata without triggering alerts typically associated with direct content retrieval attempts. This reconnaissance phase enables further attacks by revealing the structure of hidden documents, identifying potentially critical files through path names, and understanding how information is categorized via tags. While the vulnerability primarily exposes metadata rather than full page content in all cases, the disclosure of titles, descriptions, and paths can be sufficient for social engineering campaigns or to guide more targeted exploitation attempts against other components of the infrastructure. In scenarios where tag-based restrictions are used to isolate confidential HR documents, legal contracts, or proprietary code documentation, this flaw effectively nullifies those security controls.
Mitigation strategies must prioritize immediate patching as well as compensating controls if updates cannot be applied instantly. The primary remediation is to upgrade Wiki.js to version 2.5.315 or later, where the developers have addressed these authorization gaps in the affected GraphQL resolvers. For environments requiring extended support for older versions, administrators should implement strict network-level access control lists that restrict direct API endpoint exposure to only trusted internal subnets and authenticated service accounts with minimal privileges. Additionally, enabling comprehensive audit logging on the Wiki.js instance can help detect anomalous query patterns indicative of enumeration attacks using these resolvers. Security teams should also review their tag-based permission models to ensure they are not solely relied upon for protecting highly sensitive data without additional layers of encryption or physical isolation in storage systems. Regular penetration testing focusing on GraphQL endpoints is recommended to identify similar logic flaws before they can be exploited by malicious actors seeking unauthorized access to organizational knowledge bases.