YesWiki, a PHP-based open-source wiki engine popular for collaborative intranets and community sites, contains multiple reflected cross-site scripting (XSS) vulnerabilities. These flaws affect both authenticated and unauthenticated users in the latest version tested via Docker. Security researchers disclosed them publicly, urging an upgrade to version 4.6.0, which patches the issues.
Reflected XSS occurs when user input from URLs or parameters reflects back into the page without sanitization, allowing attackers to inject malicious JavaScript. In YesWiki, this hits core features like page deletion, BazaR (a form and database tool), theme management, and page listing. Unauthenticated access to some endpoints amplifies the risk—anyone can craft a phishing link to trigger the payload in a victim’s browser.
Proofs of Concept
Researchers tested on a local Docker instance of the latest YesWiki. Here are the authenticated reflected XSS vectors:
http://localhost:8085/?ElizabethJFeinler/deletepage&incomingurl=%22%3E%3Cscript%3Ealert(1)%3C%2fscript%3Ehttp://localhost:8085/?BazaR&vue=saisir&action=saisir_fiche&id=%3Cscript%3Ealert(1)%3C%2fscript%3Ehttp://localhost:8085/?GererThemes/upload&file=%3Cscript%3Ealert(1)%3C/script%3EFor unauthenticated attacks, these work without login:
http://localhost:8085/?PagePrincipale/listpages&tags=%22%3E%3Cscript%3Ealert(1)%3C/script%3EMultiple parameters in the BazaR iframe endpoint also accept payloads, such as lat and lon in map views:
http://localhost:8085/?BazaR/bazariframe&id=2&template=&width=100%25&height=600px&lat=46.22763&lon=2.213749&markersize=big&provider=MapBox&zoom=5&groups=&titles=&groupsexpanded=falseThese PoCs pop an alert box, but real attacks replace it with code to steal cookies, session tokens, or keystrokes.
Real-World Risks
XSS alone rarely makes headlines, but these flaws matter because YesWiki powers public-facing wikis for NGOs, education, and small businesses—often with lax update cycles. An unauthenticated reflected XSS lets attackers phish admins via email or social links. Once JavaScript runs in an authenticated context, it accesses the full session.
Chaining amplifies damage. YesWiki’s extensions like BazaR handle file uploads and dynamic content, pairing poorly with weak input validation elsewhere. Researchers note these XSS vectors serve as “launch points” for other bugs, such as insecure endpoints or flawed authentication. For instance, injected JS could automate requests to upload malicious files or trigger admin actions, potentially leading to remote code execution (RCE).
Consider the numbers: YesWiki traces roots to WakkaWiki from 2002, with thousands of installations per Shodan scans. Similar wiki platforms (MediaWiki, DokuWiki) face constant XSS reports, yet many run unpatched versions. A 2023 vulnerability database check shows YesWiki’s past issues, including SQLi and CSRF, underscoring a pattern of delayed fixes.
Attackers prioritize reflected XSS for its low barrier—no persistence needed, just a tricked click. In finance or crypto contexts Njalla monitors, wiki sites often store credentials or API keys. A breach here leaks sessions, enabling account takeovers or data exfiltration.
Why skeptical? PoCs are basic and local-only, no CVSS score provided, and YesWiki’s niche limits mass exploitation. Still, fair assessment: unpatched instances remain sitting ducks, especially with unauth vectors. Public disclosure without embargo pressures upgrades.
Mitigate now: Update to YesWiki 4.6.0, released post-disclosure. Verify via official GitHub (yeswiki/yeswiki). Audit extensions like BazaR for custom code. Enable Content Security Policy (CSP) to block inline scripts, and scan inputs with tools like OWASP ZAP. Operators should rotate sessions post-upgrade and monitor logs for alert(1) probes.
This advisory highlights a core truth in open-source security: wiki software lags on validation. If your site runs YesWiki, check version today—don’t wait for exploitation reports to spike.
