CVE-2025-46550: Yeswiki XSS Vulnerability

CVE-2025-46550 Overview

CVE-2025-46550 is a reflected cross-site scripting (XSS) vulnerability in YesWiki, an open-source wiki system written in PHP. The flaw affects versions prior to 4.5.4 and resides in the /?BazaR endpoint, specifically in how the idformulaire parameter is processed. An unauthenticated attacker can craft a malicious link that, when clicked by an authenticated user, executes arbitrary JavaScript in the victim's browser context. Successful exploitation enables session cookie theft, session takeover, website defacement, and injection of malicious content. The issue is tracked under CWE-79 and has been patched in YesWiki 4.5.4.

Critical Impact
Reflected XSS enables attackers to hijack authenticated YesWiki sessions and deface content by tricking users into clicking crafted URLs.

Affected Products

YesWiki versions prior to 4.5.4
YesWiki /?BazaR endpoint using the idformulaire parameter
The tools/bazar/templates/forms/forms_confirm.twig template

Discovery Timeline

2025-04-29 - CVE-2025-46550 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-46550

Vulnerability Analysis

The vulnerability stems from unsanitized reflection of the idformulaire HTTP GET parameter into a Twig template response. YesWiki's BazaR module renders confirmation forms that echo the user-supplied idformulaire value back into the rendered HTML without enforcing a strict type or output encoding. When an attacker supplies JavaScript payloads in place of the expected numeric identifier, the payload is reflected into the DOM and executed by the victim's browser. Because the reflection occurs within an authenticated form flow, stolen session cookies grant the attacker full access to the victim's YesWiki account, including any administrative rights held by the user.

Root Cause

The idformulaire parameter, which should represent a numeric form identifier, was passed through Twig templates without type coercion or HTML escaping. The templates rendered the raw value into both URL parameters and translated message strings, creating a reflected XSS sink. This is a classic input validation failure classified as CWE-79: Improper Neutralization of Input During Web Page Generation.

Attack Vector

Exploitation requires an attacker to deliver a crafted URL to an authenticated YesWiki user through phishing, chat, or embedded links. When the victim visits the URL, the payload injected via idformulaire executes in their browser and can exfiltrate session cookies to an attacker-controlled endpoint. No prior authentication or privileges are required from the attacker, though user interaction is necessary.

php

// Patch excerpt: includes/services/TemplateEngine.php
// Adds a Twig helper that forces integer casting on inputs
            return '';
        });
+        $this->addTwigHelper('int', function ($content) {
+            return (int)$content;
+        });
        $this->addTwigHelper('_t', function ($key, $params = []) {
            return html_entity_decode(_t($key, $params));
        });

Source: YesWiki commit 4e9e51d

twig

{# Patch excerpt: tools/bazar/templates/forms/forms_confirm.twig #}
<form action="{{ url({params:{
            vue: 'formulaire',
            action: type,
-            idformulaire: request.get.idformulaire ?? 'error'
+            idformulaire: int(request.get.idformulaire ?? 'error')
        }}) }}"
        method="post">
        {{ include("@templates/alert-message.twig",{
            type: "warning",
            message:
-                _t(type == 'delete' ? 'BAZ_FORM_DELETE' : 'BAZ_FORM_EMPTY',{'formId':request.get.idformulaire}) ~ '<br/>' ~
+                _t(type == 'delete' ? 'BAZ_FORM_DELETE' : 'BAZ_FORM_EMPTY',{'formId': int(request.get.idformulaire)}) ~ '<br/>' ~
            '<b>' ~ _t(type == 'delete' ? 'BAZ_CONFIRM_SUPPRIMER_FORMULAIRE' : 'BAZ_CONFIRM_VIDER_FORMULAIRE') ~ ' ?</b><br/>'
        }) }}

The patch wraps request.get.idformulaire with the new int() Twig helper, coercing the parameter to an integer before it reaches any rendering sink. Source: YesWiki commit 4e9e51d.

Detection Methods for CVE-2025-46550

Indicators of Compromise

HTTP GET requests to /?BazaR containing idformulaire values with non-numeric characters such as <, >, script, or URL-encoded equivalents.
Web server access logs showing referrers or URLs with JavaScript event handlers or javascript: schemes in the idformulaire parameter.
Unexpected outbound requests from user browsers to unknown domains shortly after visiting a BazaR confirmation page.

Detection Strategies

Deploy web application firewall (WAF) rules that inspect the idformulaire parameter and block any value that fails a strict integer regex match.
Correlate authentication events with anomalous session reuse from new IP addresses or user agents that follow BazaR endpoint access.
Review YesWiki application logs for repeated requests to /?BazaR from unauthenticated sources targeting authenticated user workflows.

Monitoring Recommendations

Enable verbose HTTP request logging on the YesWiki web server and forward logs to a centralized SIEM for query-based detection.
Alert on any occurrence of <script, onerror=, or onload= substrings within URL parameters directed at YesWiki hosts.
Monitor for session cookie usage from geolocations or devices that deviate from established user baselines.

How to Mitigate CVE-2025-46550

Immediate Actions Required

Upgrade all YesWiki instances to version 4.5.4 or later without delay.
Invalidate existing user sessions after upgrading to force reauthentication and revoke any cookies that may have been captured.
Audit administrator accounts for unauthorized configuration changes, new users, or modified wiki content.

Patch Information

YesWiki 4.5.4 addresses the vulnerability by introducing an int() Twig helper and applying it to the idformulaire parameter in tools/bazar/templates/forms/forms_confirm.twig. The fix is available in YesWiki commit 4e9e51d and documented in GitHub Security Advisory GHSA-ggqx-43h2-55jp.

Workarounds

If immediate upgrade is not possible, deploy a WAF rule that rejects requests to /?BazaR where idformulaire is not strictly numeric.
Restrict access to the BazaR endpoint to authenticated administrators via reverse-proxy access controls until the patch is applied.
Enforce HttpOnly and Secure flags on session cookies and add a strict Content Security Policy (CSP) to limit inline script execution.

bash

# Example nginx configuration to block non-numeric idformulaire values
location ~* /\?BazaR {
    if ($arg_idformulaire !~ "^[0-9]+$") {
        return 403;
    }
}

# Example Content Security Policy header to reduce XSS impact
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'none';" always;