CVE-2026-104472 in YesWiki
Summary
by MITRE • 10/02/2026
YesWiki before 4.6.7 contains a missing authorization vulnerability in the attachment download handler that allows unauthenticated attackers to bypass page read ACLs. Attackers can request the download handler with a known page tag and file parameter to retrieve confidential attachments from read-restricted pages.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The identified security flaw resides within YesWiki versions prior to 4.6.7, specifically affecting the attachment download handling mechanism. This vulnerability is classified as a missing authorization issue where the application fails to enforce access control checks on sensitive resources. In typical web applications, attachments associated with wiki pages are subject to the same Access Control Lists that govern page visibility. However, in this specific implementation, the endpoint responsible for serving file downloads operates independently of these restrictions. An attacker who possesses knowledge of a valid page tag and the corresponding filename can directly request the download handler without being authenticated or authorized to view the parent page itself. This architectural oversight effectively decouples resource access from content access controls, creating a significant security gap that undermines the intended confidentiality model of the wiki platform.
From a technical perspective, the vulnerability stems from insufficient validation within the server-side logic processing attachment requests. When a user initiates a download by providing specific parameters such as page identifiers and file names, the system retrieves and streams the requested binary data without verifying whether the requesting entity has read permissions for that particular page. This lack of intermediate authorization checks allows unauthenticated actors to bypass standard security boundaries. The exploitability is relatively straightforward given that wiki pages often use predictable or discoverable tags, making it feasible for an attacker to enumerate valid targets and subsequently extract restricted documents such as internal reports, configuration files, or sensitive correspondence stored within the attachment directory structure.
The operational impact of this vulnerability is substantial, particularly in environments where YesWiki is used for collaborative work involving confidential information. Successful exploitation leads directly to unauthorized data disclosure, compromising the integrity and confidentiality of organizational assets. Attackers can exfiltrate proprietary documents, personal identifiable information, or other restricted materials that were intended to be visible only to specific groups or individuals within a wiki community. This breach not only violates privacy expectations but may also lead to regulatory non-compliance depending on the nature of the exposed data. Furthermore, access to internal documentation could facilitate further attacks by revealing system configurations, network diagrams, or administrative procedures that aid in more sophisticated intrusion attempts.
This vulnerability aligns with CWE-284 Improper Access Control and CWE-798 Use of Hard-coded Credentials if specific default paths are exploited, though primarily it represents a failure to enforce proper authorization checks on sensitive resources. In the context of the MITRE ATT&CK framework, this behavior corresponds to T1005 Data from Local System as attackers retrieve data directly from local storage without authentication. To mitigate this risk, administrators must upgrade YesWiki to version 4.6.7 or later where these access control checks have been properly implemented in the download handler. Additionally, until an update is applied, it is advisable to restrict direct web server access to attachment directories using firewall rules or web application firewall policies that require authentication for file retrieval endpoints. Regular audits of wiki permissions and minimizing the storage of highly sensitive data as attachments can also reduce the potential blast radius if such vulnerabilities are present in other versions or similar software components.