CVE-2025-46349: Reflected Cross-Site Scripting in YesWiki File Upload

YesWiki is an open-source wiki system written in PHP. Versions of the software prior to 4.5.4 contain multiple Reflected Cross-Site Scripting (XSS) vulnerabilities mapped to CVE-2025-46349. The primary vulnerability exists within the file upload form functionality, specifically isolated to the tools/attach/libs/attach.lib.php script.

The vulnerability allows unauthenticated attackers to inject arbitrary JavaScript payloads into the web application's HTTP response. This occurs because user-supplied input passed through the file GET parameter is directly echoed into the HTML document structure without adequate sanitization or output encoding. The secondary vector resides in the application's group management module.

The Common Vulnerability Scoring System (CVSS v3.1) evaluates this flaw at 7.6, denoting a high severity level. The impact primarily targets application integrity, as successful exploitation facilitates the unauthorized execution of scripts within the security context of the victim's active session.

The root cause of CVE-2025-46349 is the improper neutralization of input during web page generation, classified under CWE-79. The YesWiki application implements a file attachment module that utilizes a showUploadForm() method to render the upload interface for end users. The application relies on this method to dynamically generate form elements based on request parameters.

Within the showUploadForm() method, the application retrieves the file parameter directly from the $_GET superglobal array. The retrieved value is immediately assigned to a class property called $this->file. The application then uses this property to construct HTML responses via direct string concatenation.

The property is specifically embedded within an <h3> header tag and a hidden HTML <form> input field. Because the PHP script lacks output encoding functions such as htmlspecialchars() or htmlentities(), any HTML or JavaScript characters contained in the parameter are interpreted literally by the victim's web browser rendering engine.

A secondary vulnerability vector exists within the group management functionality located in actions/EditGroupsAction.php. In this specific component, exception messages containing user-controlled group names or member names are directly echoed into HTML alert boxes. This presents an additional XSS surface that bypasses typical input validation routines.

An examination of the tools/attach/libs/attach.lib.php file in vulnerable versions reveals the direct assignment and reflection of the unsanitized parameter. The vulnerable implementation reads the GET parameter and echoes it directly into the HTML markup.

public function showUploadForm()
{
    $this->file = $_GET['file']; // Unsafe direct assignment
    echo '<h3>' . _t('ATTACH_UPLOAD_FORM_FOR_FILE') . ' ' . $this->file . "</h3>\n";
    echo '<form ...>'
        . "\t<input type=\"hidden\" name=\"file\" value=\"$this->file\" />\n";
}

The patch introduced in commit 0dac9e2fb2a5e69f13a3c9f761ecae6ed9676206 implements a robust defense-in-depth approach. The remediation modifies the parameter retrieval process to utilize PHP's built-in filter_input function coupled with the FILTER_SANITIZE_FULL_SPECIAL_CHARS flag. This ensures that HTML special characters are properly neutralized at the point of ingestion.

Furthermore, the developers implemented a strict path validation check by wrapping the sanitized input in the realpath() function. Because a JavaScript payload does not correspond to a valid physical file path on the host server, realpath() resolves to a boolean false.

public function showUploadForm()
{
    // Sanitize and validate path
    $this->file = realpath(filter_input(INPUT_GET, 'file', FILTER_SANITIZE_FULL_SPECIAL_CHARS));
    if (!empty($this->file)) {
        echo '<h3>' . _t('ATTACH_UPLOAD_FORM_FOR_FILE') . ' ' . $this->file . "</h3>\n";
        // Secure form rendering logic
    } else {
        echo '<div class="alert alert-danger">No valid filename</div>';
    }
}

Exploiting CVE-2025-46349 requires an attacker to construct a specialized Uniform Resource Locator (URL) targeting the vulnerable application endpoint. The payload must reside within the file query parameter attached to the /?PagePrincipale/upload path mapping. The payload requires no authentication to process.

A standard proof-of-concept payload utilizes the <script> tag to execute arbitrary code. The attacker constructs the following URL to demonstrate code execution within the browser context: /?PagePrincipale/upload&file=<script>alert(document.domain)</script>. The attacker must then distribute this URL to an administrative user or standard user via social engineering.

Upon processing the malicious link, the victim's browser receives the HTTP response containing the injected script tags. The browser parses the document, encounters the script tags within the <h3> and <input> elements, and executes the JavaScript logic within the context of the YesWiki domain. The script execution completes the attack chain.

The successful execution of arbitrary JavaScript within a victim's session presents multiple critical security risks. The injected script operates with the exact permissions and domain context as the authenticated user interacting with the YesWiki application. This context equivalence is the primary danger of cross-site scripting vulnerabilities.

An attacker can leverage this execution context to access sensitive data stored within the Document Object Model (DOM), including active session identifiers, Cross-Site Request Forgery (CSRF) tokens, or authentication cookies. Exfiltration of session tokens permits the attacker to hijack the authenticated session entirely and persist their access.

Beyond session hijacking, the attacker can force the victim's browser to perform unauthorized actions on the wiki. This includes creating new administrative accounts, modifying existing wiki content, or altering system configurations without the victim's explicit knowledge. The application records these actions as originating from the legitimate user.

The CVSS v3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:H/A:L accurately reflects this specific threat model. The high integrity impact rating accounts for the attacker's ability to mutate application state through the compromised user session, while the user interaction requirement indicates the need for the victim to click the crafted payload link.

The definitive remediation for CVE-2025-46349 and the associated GHSA-5724-X3RH-5QQQ advisory is to upgrade the YesWiki installation to version 4.5.4 or later. This specific release comprehensively addresses both the primary file upload vector and the secondary group management vulnerability via appropriate sanitization functions.

Administrators must verify the successful deployment of commits 0dac9e2fb2a5e69f13a3c9f761ecae6ed9676206 and 6894234bbde6ab168bf4253f9a581bd24bf53766 within their local environments. Analyzing the local server files to confirm the presence of realpath() and filter_input() within the attachment libraries provides assurance that the patch is active.

In environments where immediate patching is technically prohibited, administrators should implement defensive controls at the network perimeter. Deploying a Web Application Firewall (WAF) configured to detect and block common cross-site scripting payloads within GET parameters provides a temporary mitigation layer against active exploitation attempts.

Furthermore, security engineering teams should consider deploying strict Content Security Policy (CSP) headers across the web application. A properly configured CSP limits the execution of inline scripts and restricts the domains from which external scripts can be loaded. This architectural control significantly reduces the efficacy of reflected XSS attacks even if the underlying code remains vulnerable.