Description

YesWiki before 4.6.7 contains a stored cross-site scripting vulnerability in the Bazar FileField, which validates only the upload's file extension and never calls HtmlPurifierService::cleanFile, so SVG files are stored verbatim and served inline as image/svg+xml. Authenticated users can submit entries via POST /api/entries/{formId} with SVG files containing script that executes in the wiki origin when the file is opened, enabling administrator session or account compromise.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-10-02T12:17:18.303Z",
  "pubdate": "2026-10-02T12:17:18.303Z",
  "executiveSummary": "YesWiki versions prior to 4.6.7 are susceptible to a stored Cross-Site Scripting (XSS) vulnerability located within the Bazar FileField component.\nThe vulnerability originates from improper input validation during file uploads, specifically concerning the handling of Scalable Vector Graphics (SVG) files.\nBy failing to invoke the HtmlPurifierService::cleanFile function, the application allows the storage and subsequent inline rendering of malicious SVG content.\nAn authenticated attacker can leverage this flaw to inject arbitrary JavaScript, which executes within the context of the wiki's origin when the file is accessed.\nThe primary impact includes potential session hijacking, unauthorized administrative actions, and full account compromise, posing a significant risk to the integrity and confidentiality of the YesWiki installation.\nExploitation requires the attacker to have an authenticated session to interact with the API endpoints.",
  "technicalDetails": "The vulnerability resides in the Bazar FileField implementation within YesWiki, which acts as a file upload handler for entry submissions. The application's security mechanism for file uploads is restricted solely to a rudimentary file extension validation check, which fails to inspect the underlying content or structure of the uploaded files.\nThe core issue stems from the omission of the HtmlPurifierService::cleanFile function in the file upload processing pipeline. In modern web environments, SVG files are XML-based documents that can contain embedded scripts via <script> tags or event handlers within elements. Because the system fails to sanitize these files, malicious SVG payloads are saved to the server and served with the image/svg+xml MIME type.\nThe attack vector involves a POST request directed to /api/entries/{formId}. An authenticated attacker can upload a crafted SVG file containing embedded malicious JavaScript. When an administrator or another user views the uploaded file, the browser interprets the content as an SVG document and executes the embedded script in the security context of the wiki's origin.\nBecause the execution occurs within the wiki's origin, the script gains access to sensitive data, including session cookies, local storage, and the ability to perform actions on behalf of the victim. If an administrator views the file, the attacker may be able to escalate privileges or modify site configuration, leading to full site compromise.\nThe vulnerability is persistent, meaning the malicious payload remains on the server until manually removed, and it can be triggered repeatedly by any user who navigates to the URL associated with the uploaded file. This mechanism effectively bypasses standard web application security controls that rely on simple extension filtering."
}