Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-10-02T12:17:16.483Z",
  "pubdate": "2026-10-02T12:17:16.483Z",
  "executiveSummary": "YesWiki versions prior to 4.6.7 are susceptible to a critical missing authorization vulnerability located within the pointimage action. This flaw enables unauthenticated remote attackers to bypass established write access control lists (ACLs) and inject arbitrary content into wiki pages.\nThe vulnerability manifests in the tools/attach/actions/pointimage.php component, where improper authorization checks allow the submission of malicious POST requests. By manipulating the pagetag, title, and description fields, attackers can append raw HTML or JavaScript payloads to any page that utilizes the {{pointimage}} directive.\nThe primary risk implication is Stored Cross-Site Scripting (XSS). An attacker can successfully execute malicious scripts within the browsers of unsuspecting users, including administrative accounts with elevated privileges. This capability facilitates session hijacking, unauthorized content modification, and potential account compromise. Exploitation does not require prior authentication, making this an accessible target for remote actors. Organizations utilizing affected versions are at high risk of credential theft and malicious site redirection if this vulnerability remains unpatched.",
  "technicalDetails": "The root cause of this vulnerability is a missing authorization validation check in the pointimage action handler, specifically defined in the file tools/attach/actions/pointimage.php. While the application is designed to enforce write ACLs to restrict which users can modify specific content, the implementation within the pointimage action fails to verify the requester's identity or their permission level before executing write operations to the page storage backend.\nThe attack flow begins when an unauthenticated attacker identifies a target YesWiki instance containing at least one page that renders the {{pointimage}} plugin. The attacker sends a crafted HTTP POST request to the server, targeting the vulnerable pointimage action endpoint. The request includes the 'pagetag' parameter to specify the target page, alongside 'title' and 'description' parameters containing the malicious payload.\nBecause the underlying logic in pointimage.php lacks sufficient input sanitization and authorization logic, the application processes these inputs and appends the payload directly to the wiki page's data store. By bypassing the application's native access control mechanisms, the attacker forces the system to treat the malicious input as legitimate content. When an administrator or a legitimate user subsequently views the affected page, the server renders the injected content, causing the victim's browser to execute the attacker's JavaScript payload.\nThis behavior represents a Stored XSS attack vector where the payload persists within the wiki environment. The impact is significant because the script executes within the context of the victim's session, effectively granting the attacker the same permissions as the victim. This enables an attacker to perform actions on behalf of the user, such as modifying other pages, changing site configurations, or extracting sensitive cookies and session tokens. Since the vulnerability resides in a core action script and permits arbitrary content insertion, it bypasses security boundaries established by the wiki's configuration. The lack of authentication requirements allows any actor with network access to the wiki to perform this injection, significantly increasing the attack surface. Furthermore, because the injection is stored, the attack remains effective indefinitely until the malicious content is manually identified and removed from the server's backend database or page storage files."
}