CVE-2026-104438 in YesWiki
Summary
by MITRE • 10/02/2026
YesWiki before 4.6.7 contains a missing authorization vulnerability in the listpagestag and includepages actions of the tags tool, which enumerate pages without applying read-ACL filtering. Unauthenticated or unprivileged attackers can embed these actions with a chosen tag or page name to disclose the names and body-derived titles of ACL-restricted pages.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in YesWiki versions prior to 4.6.7 represents a critical failure in access control mechanisms, specifically categorized under CWE-285 Improper Authorization. This flaw resides within the tags tool functionality, affecting two specific actions: listpagestag and includepages. In secure web applications, any action that retrieves or displays content from a database must strictly enforce Access Control Lists (ACLs) to ensure that users can only access resources for which they have been explicitly granted permission. However, in this instance, the application fails to apply read-ACL filtering when processing these specific actions. This architectural oversight means that the underlying logic bypasses the standard security checks that would normally restrict visibility of sensitive or private pages based on user roles and permissions.
The operational impact of this vulnerability is significant for organizations relying on YesWiki as a collaborative platform where content confidentiality is paramount. Because the authorization check is missing, unauthenticated attackers or users with minimal privileges can exploit these endpoints to enumerate page names and retrieve body-derived titles from ACL-restricted pages. This capability effectively allows an attacker to map out the structure of the wiki without needing valid credentials for restricted sections. By embedding specific tags or page names into requests directed at listpagestag or includepages, attackers can systematically discover which private documents exist within the system. While the vulnerability description notes that titles and names are disclosed, depending on implementation details, there is a risk that full content retrieval could also be facilitated if other parameters are manipulated, leading to a comprehensive information disclosure scenario.
From an offensive security perspective, this flaw aligns with ATT&CK technique T1087.2 Account Enumeration via Local Directory, as it allows for the discovery of internal resources and potentially user-associated data through indirect means. The ability to enumerate restricted pages provides attackers with valuable intelligence that can be leveraged in subsequent attack phases. For example, knowing which private documents exist might allow an attacker to tailor phishing attacks or social engineering efforts against specific users who are likely owners of those sensitive files. Furthermore, this information disclosure reduces the complexity required for further exploitation, as it removes the need for brute-force guessing regarding page structures and content availability.
To mitigate this vulnerability, administrators must upgrade YesWiki to version 4.6.7 or later immediately, as these updates include patches that enforce proper authorization checks on all data retrieval actions within the tags tool. Until an upgrade is feasible, temporary mitigations should focus on restricting access to the wiki entirely via network-level controls such as firewalls or reverse proxies if public internet exposure is not required. Additionally, implementing strict input validation and ensuring that all API endpoints explicitly verify user permissions before returning any data can help prevent similar issues in other parts of the application. Regular security audits focusing on authorization logic are recommended to detect and remediate improper access control flaws across the entire codebase, ensuring that no action bypasses established ACL policies.