YesWiki, an open-source PHP-based wiki platform popular among small organizations and French-speaking communities, suffers from a persistent blind XSS vulnerability. Attackers can inject JavaScript code without authentication through the BazaR module’s form title field. The payload stores in the database and executes in any visitor’s browser when they access /?BazaR&vue=consulter. This affects self-hosted instances running vulnerable versions of the yeswiki/yeswiki codebase.
The flaw resides in inadequate sanitization of the form title input. YesWiki’s BazaR extension handles dynamic forms and databases, letting users create records like diary entries. An attacker visits the form page at /?BazaR&vue=formulaire, adds a record, and slips in payloads such as <script>alert(1)</script> or "><img src=x onerror=alert(1)> into the “Name of the event” or “Description” fields. Saving triggers backend storage without escaping, and viewing the consulter page later fires the script.
Vulnerability Breakdown
This qualifies as stored XSS because the malicious input persists in the database across sessions. It’s blind since the attacker doesn’t see immediate feedback on the injection page, but persistence ensures execution on target visits. No login required makes it low-barrier: public wikis expose themselves fully.
YesWiki traces roots to WakkaWiki, evolving into a flexible tool for intranets, event management, and collaborative databases. BazaR specifically powers no-code form builders, mimicking lightweight CRMs. Over 1,000 public instances exist, per Shodan scans, many on shared hosting with default configs. CVEs haven’t tagged this yet, but the advisory from yeswiki/yeswiki GitHub flags it as high severity.
Exploitation chain: 1) Attacker crafts payload. 2) Submits via public form. 3) Payload embeds in listing views. 4) Victim—admin, editor, or guest—loads the page, running JS in their context. Common payloads steal cookies, session tokens, or keystrokes, enabling account takeovers or data exfiltration.
Proof of Concept
Replicate on a test instance:
# Navigate to form page
https://target-yeswiki.net/?BazaR&vue=formulaire
# Click '+' to add Diary form record
# In 'Name of the event': <script>alert(document.cookie)</script>
# Or in 'Description': "><svg onload=alert(1)>
# Click 'To validate'
# Visit trigger page
https://target-yeswiki.net/?BazaR&vue=consulter
# Or specific record: /?wiki=BazaR&vue=consulter&action=recherche&q=&id=2&facette=
The alert pops on load, confirming execution. Persistence holds until admins delete the tainted record.
Why It Matters and What to Do
XSS tops OWASP risks for a reason: one injection compromises all users. On YesWiki sites handling memberships, events, or finances, attackers phish credentials or pivot to server-side via CSRF. Public exposure amplifies reach—think community wikis with hundreds of visitors.
Skeptically, not every install runs BazaR enabled, and some harden with Content-Security-Policy (CSP). But defaults don’t, and small orgs rarely audit extensions. YesWiki’s last major release predates widespread CSP adoption, leaving gaps.
Patch immediately: Update to the latest yeswiki/yeswiki commit post-advisory, or disable BazaR forms publicly. Sanitize outputs manually if stuck—use htmlspecialchars on titles. Scan databases for payloads like <script. Enable CSP headers blocking inline scripts. Run grep -r "alert\|onerror\|onload" /path/to/yeswiki/data/ to hunt injections.
Operators, audit all extensions; BazaR’s convenience trades security. This underscores wiki platforms’ pitfalls: user-generated content demands ironclad escaping. Ignore at your peril—persistent XSS lurks until purged.
