CVE-2026-104450 in YesWiki
Summary
by MITRE • 10/02/2026
YesWiki before 4.6.7 contains a missing authorization flaw in the pointimage action (tools/attach/actions/pointimage.php), which saves content to an attacker-chosen page with write ACL checks bypassed. Unauthenticated attackers can POST pagetag, title, and description fields to any page rendering {{pointimage}} to append raw HTML or JavaScript to any wiki page, including pages whose write ACL restricts editing, causing stored cross-site scripting in viewers' and administrators' browsers.
Once again VulDB remains the best source for vulnerability data.
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 within the pointimage action module located at tools/attach/actions/pointimage.php. This flaw stems from an insufficient authorization check that allows unauthenticated users to interact with functionality intended for authorized editors or administrators. Specifically, the application fails to verify whether the requesting user possesses write permissions on the target page before processing a POST request containing pagetag, title, and description fields. Consequently, attackers can bypass standard access control lists (ACLs) designed to restrict editing capabilities, effectively treating protected pages as if they were publicly editable. This architectural oversight enables the injection of arbitrary content into wiki pages that are otherwise secured against unauthorized modifications, undermining the fundamental integrity controls implemented by system administrators.
From a technical perspective, the exploitation vector involves crafting specific HTTP POST requests directed at the vulnerable endpoint. By supplying malicious payloads within the pagetag, title, or description parameters, an attacker can inject raw HTML and JavaScript code into the page content. Since YesWiki renders these fields for display to users viewing the wiki pages, the injected scripts are executed in the context of the victim's browser session. This mechanism facilitates stored cross-site scripting (XSS), a severe web application vulnerability where malicious scripts persist on the target server and are served to multiple victims over time. The persistence of this code means that every user who views the compromised page becomes a potential target, regardless of their role or authentication status within the wiki environment.
The operational impact of this vulnerability is significant due to its ability to compromise both regular users and privileged administrators alike. For standard viewers, successful exploitation can lead to session hijacking through cookie theft, allowing attackers to impersonate legitimate users and access sensitive information stored in browser sessions. If an administrator views a page compromised by such an attack, the consequences are far more severe. Attackers can leverage administrative privileges obtained via XSS to modify system configurations, install malicious plugins or themes, exfiltrate database contents, or create backdoors for persistent unauthorized access. This effectively results in full compromise of the underlying web application and potentially the server infrastructure hosting it, depending on the capabilities granted by the compromised admin session.
This vulnerability aligns with CWE-284, which describes Improper Access Control, as the core issue is the failure to enforce proper authorization checks before allowing state-changing operations. Furthermore, in terms of offensive security frameworks such as MITRE ATT&CK for Enterprise, this flaw facilitates techniques related to Initial Access via Exploit Public-Facing Application and Persistence through Web Shell or Stored XSS. The ability to inject scripts into stored content also maps to the Execution technique involving Browser Scripting, allowing attackers to run arbitrary commands within the victim's browser environment. These classifications highlight the severity of bypassing access controls combined with code injection capabilities in web applications.
Mitigation strategies must prioritize immediate patching and defensive configuration changes. The most effective remediation is upgrading YesWiki to version 4.6.7 or later, where this authorization flaw has been addressed by developers implementing stricter ACL verification prior to processing pointimage actions. For environments unable to upgrade immediately, administrators should consider restricting access to the tools/attach/actions directory via web server configuration rules if possible, although application-level fixes are preferred. Additionally, deploying a Web Application Firewall (WAF) with rules tuned to detect and block common XSS payloads in POST parameters can provide an additional layer of defense against exploitation attempts. Regular security audits focusing on input validation and authorization checks across all action modules are recommended to prevent similar access control bypasses in the future.