CVE-2026-104461: YesWiki Stored XSS Vulnerability

CVE-2026-104461 Overview

CVE-2026-104461 is a stored cross-site scripting (XSS) vulnerability in YesWiki versions before 4.6.7. The flaw resides in the Bazar FileField component, which validates only the upload file extension and never invokes HtmlPurifierService::cleanFile. SVG files are stored verbatim and served inline as image/svg+xml, allowing embedded JavaScript to execute in the wiki origin. Authenticated users can submit entries via POST /api/entries/{formId} with malicious SVG payloads. When an administrator opens the file, the script runs in their session context.

Critical Impact
Authenticated attackers can achieve administrator session or account compromise through a stored SVG payload executing in the wiki origin.

Affected Products

YesWiki versions prior to 4.6.7
YesWiki Bazar FileField upload component
Deployments permitting authenticated entry submissions via /api/entries/{formId}

Discovery Timeline

2026-10-02 - CVE-2026-104461 published to the National Vulnerability Database (NVD)
2026-10-06 - Last updated in NVD database

Technical Details for CVE-2026-104461

Vulnerability Analysis

The vulnerability is a stored cross-site scripting flaw [CWE-79] in the Bazar FileField component of YesWiki. YesWiki is an open-source collaborative wiki platform written in PHP. The Bazar extension provides form-based data entry, including file attachments through the FileField type.

The FileField upload handler enforces an allowlist based solely on file extensions. SVG files pass this check because .svg is treated as an image format. However, SVG is an XML-based vector format that supports embedded <script> elements and JavaScript event handlers. The server stores the file without content sanitization and later serves it with the image/svg+xml MIME type inline, which causes browsers to render and execute embedded scripts in the wiki's origin.

An authenticated attacker can abuse this flaw to steal administrator session cookies, perform actions in the administrator context, or escalate privileges within the wiki.

Root Cause

The root cause is missing content sanitization in the file upload pipeline. The FileField validator checks the extension but never calls HtmlPurifierService::cleanFile, the service responsible for stripping active content from SVG uploads. Trusting the extension alone treats SVG as inert imagery when it is in fact executable XML markup.

Attack Vector

Exploitation requires an authenticated account with permission to submit Bazar entries. The attacker crafts an SVG document containing a <script> tag or an event handler such as onload. The attacker then issues POST /api/entries/{formId} with the SVG attached to a FileField. The server accepts and stores the file. When any user, typically an administrator, opens the file link, the browser renders the SVG inline and executes the embedded JavaScript under the wiki origin, exposing session cookies and privileged actions to the attacker.

No verified public proof-of-concept code is available. Refer to the GitHub Security Advisory GHSA-67v5-7pfv-pp9m for upstream technical details.

Detection Methods for CVE-2026-104461

Indicators of Compromise

SVG files in Bazar upload directories containing <script>, onload=, or javascript: strings
Unexpected POST /api/entries/{formId} requests from low-privilege accounts carrying .svg attachments
Administrator sessions originating from new IP addresses shortly after SVG files are opened
Outbound requests from the wiki origin to attacker-controlled domains during SVG rendering

Detection Strategies

Scan Bazar file storage directories for SVG files containing script tags, event handlers, or external entity references
Review web server logs for POST /api/entries/{formId} requests with SVG payloads submitted by non-administrator accounts
Monitor response Content-Type headers for image/svg+xml served inline rather than as attachments
Correlate SVG file access events with administrator account changes or privilege modifications

Monitoring Recommendations

Alert on new SVG uploads to YesWiki instances until patched
Track YesWiki version strings in HTTP responses to identify unpatched hosts
Log and review administrator-level account modifications following any SVG file access

How to Mitigate CVE-2026-104461

Immediate Actions Required

Upgrade YesWiki to version 4.6.7 or later, which adds HtmlPurifierService::cleanFile to the FileField upload path
Audit existing Bazar uploads for malicious SVG content and remove any suspicious files
Rotate administrator session cookies and credentials if exploitation is suspected
Restrict Bazar entry submission permissions to trusted users while patching is planned

Patch Information

The fix is included in YesWiki 4.6.7. The patched release ensures the FileField component invokes HtmlPurifierService::cleanFile on uploads, stripping active content from SVG files before storage. See the GitHub Security Advisory GHSA-67v5-7pfv-pp9m and the VulnCheck Advisory for YesWiki XSS for release references.

Workarounds

Block .svg uploads at the web server or reverse proxy layer until the patch is applied
Force SVG responses to use Content-Disposition: attachment so browsers download rather than render them
Serve user-uploaded files from a separate, cookieless origin to isolate script execution from the wiki session
Apply a Content Security Policy that disallows inline scripts on pages that render user-uploaded content

bash

# Example nginx configuration to force SVG downloads
location ~* \.svg$ {
    add_header Content-Disposition "attachment";
    add_header X-Content-Type-Options "nosniff";
}