CVE-2026-52773 in YesWiki
Summary
by MITRE • 09/05/2026
YesWiki is a wiki system written in PHP. From version 4.1.0 to before version 4.6.6, YesWiki's archived-revision view reflects the time GET parameter into a hidden HTML input in handlers/page/show.php without escaping. Because MySQL coerces malformed DATETIME strings, an attacker can append HTML or JavaScript to a valid archived revision timestamp, still load that archived revision, and execute arbitrary JavaScript in the victim's browser. The vulnerable form is only rendered when the victim can both read and edit the target page. In restricted deployments this requires a victim with read and write access to that page. On a default doryphore 4.6.5 install, public pages such as PagePrincipale were editable anonymously during validation, so the issue can also affect unauthenticated visitors in that configuration. This issue has been patched in version 4.6.6.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/05/2026
YesWiki is a wiki system implemented in PHP that allows users to create and edit collaborative web pages. A significant security vulnerability was identified within versions ranging from 4.1.0 up to, but not including, version 4.6.6. This flaw resides specifically in the archived-revision view functionality located within the handlers/page/show.php module of the application codebase. The core technical issue stems from improper neutralization of special elements used in an output context, which is a classic manifestation of Cross-Site Scripting or reflected input handling errors. Specifically, when rendering an archived revision, the system takes the time parameter provided via HTTP GET requests and injects it directly into a hidden HTML input field without performing any form of escaping or sanitization. This lack of validation allows malicious actors to manipulate the expected data structure by appending arbitrary script content to what should be a valid timestamp value.
The exploitability of this vulnerability is heavily dependent on how MySQL handles malformed date strings, which plays a crucial role in the success of the attack vector. In many database configurations, particularly those using standard MySQL settings, the system exhibits lenient type coercion behavior when processing DATETIME fields. When an attacker appends HTML or JavaScript code to a valid archived revision timestamp, the database engine often ignores the malformed portion and successfully retrieves the record based on the initial valid date segment. Consequently, the application proceeds to render the page content while simultaneously injecting the malicious script payload into the hidden input field within the DOM structure of the response. This mechanism effectively bypasses standard server-side checks that might otherwise reject invalid data formats, allowing the attack to succeed even when strict database constraints are theoretically in place for date fields.
The operational impact of this vulnerability is primarily focused on Cross-Site Scripting attacks against users who have specific permissions within the wiki environment. Because the vulnerable form element is only rendered when a user has both read and edit access to the target page, the attack requires a certain level of pre-existing trust or privilege escalation. In restricted deployments where strict authentication and authorization policies are enforced, an attacker would need to compromise or trick a victim who possesses write privileges for the specific wiki page into viewing its archived revisions with the malicious timestamp parameter in their browser URL. Upon loading this manipulated link, the victim's browser executes the injected JavaScript code within the context of the YesWiki application domain. This can lead to session hijacking, credential theft via keyloggers or cookie stealers, defacement of the wiki interface through DOM manipulation, or redirection to phishing sites designed to harvest sensitive information from authenticated users.
However, the scope of impact expands significantly in default configurations found on certain installations, such as the doryphore 4.6.5 setup mentioned in security advisories. In these environments, public pages like PagePrincipale are often configured to be editable by anonymous visitors during specific validation periods or due to loose permission defaults. This configuration flaw means that unauthenticated attackers can not only view but also modify page content and trigger the vulnerable code path without needing valid credentials. Consequently, any visitor accessing a manipulated link pointing to an archived revision of such a publicly editable page becomes susceptible to script execution. This transforms what might otherwise be a privilege-dependent vulnerability into one accessible to anyone on the internet who discovers or is tricked into clicking the malicious URL, thereby increasing the attack surface considerably and allowing for widespread phishing campaigns targeting unauthenticated users.
To mitigate this risk, organizations running YesWiki must immediately upgrade their installations to version 4.6.6 or later, where the vulnerability has been patched by implementing proper output encoding for all user-supplied data rendered in HTML contexts. Beyond upgrading software, administrators should review and harden permission settings to ensure that anonymous users do not have write access to critical pages unless absolutely necessary. Implementing a Content Security Policy header can also provide an additional layer of defense by restricting the sources from which scripts are allowed to execute, thereby neutralizing many cross-site scripting payloads even if they manage to be injected into the DOM. Furthermore, developers should adopt strict input validation practices that reject malformed data at the application level rather than relying on database-level coercion behaviors, ensuring that only strictly formatted datetime strings are accepted for revision queries.
From a classification perspective, this vulnerability aligns with CWE-79 Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. The attack vector leverages reflected input manipulation to execute arbitrary code in the victim's browser context. In terms of tactical mapping within the MITRE ATT&CK framework, this activity corresponds to T1059 Command and Control Application Layer Protocol if used for exfiltration or T1189 Drive-by Compromise when leveraging social engineering to deliver the malicious link. The reliance on database leniency highlights a broader category of issues related to CWE-20 Improper Input Validation where system components fail to adequately verify that input data meets expected format requirements before processing, leading to unintended side effects such as code injection through type coercion anomalies.