Description

YesWiki is a wiki system written in PHP. Prior to version 4.6.6, the recentchanges action (actions/recentchanges.php) accepts a period argument from two disjoint parameter spaces. A whitelist validates only the URL form against ['day','week','month']. The action-argument form takes the else branch with no validation, and the value flows into PageManager::getRecentlyChanged(), where it is interpolated into a WHERE time >= '...' ORDER BY time DESC clause without escaping or parameterization. UNION-based injection succeeds, the leaked rows render into the response page, so any visitor of the trigger page sees the exfiltrated data. The vulnerability provides arbitrary read of the YesWiki database to anyone who can save the trigger page. On a default install (default_write_acl='*'), this includes anonymous users, subject to the hashcash JS check on the page-edit form. Once the trigger page is saved, every subsequent view fires the injection as the SQLi is stored. Stored SQL injection is reachable through the page-edit flow, with arbitrary database read. This issue has been patched in version 4.6.6.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-05T00:17:19.257Z",
  "pubdate": "2026-09-05T00:17:19.257Z",
  "executiveSummary": "YesWiki prior to version 4.6.6 is susceptible to a Stored SQL Injection vulnerability residing within the 'recentchanges' action.\nThe flaw stems from improper input validation of the 'period' argument in 'actions/recentchanges.php', which allows malicious SQL payloads to bypass existing whitelists via the action-argument parameter space.\nImpact includes unauthorized, arbitrary read access to the underlying database, as injected payloads are stored and executed upon page retrieval.\nThe vulnerability is reachable by anonymous users in default installations, provided they can successfully bypass the hashcash proof-of-work mechanism required to edit pages.\nSuccessful exploitation results in the exfiltration of sensitive database records to the rendered response page, visible to any user accessing the trigger page.\nGiven the stored nature of the injection, this represents a significant risk to data confidentiality, as the malicious payload persists across subsequent viewings of the compromised page.",
  "technicalDetails": "The vulnerability is located in the 'recentchanges' action handled by 'actions/recentchanges.php'. The application accepts a 'period' argument from two distinct parameter sources: a URL-based parameter and an action-argument parameter.\nWhile the URL-based parameter is constrained by a whitelist containing ['day', 'week', 'month'], the action-argument parameter bypasses this check entirely by falling into an 'else' branch that lacks validation logic.\nThe unvalidated input is passed directly to the 'PageManager::getRecentlyChanged()' function. Within this function, the input is interpolated directly into a SQL query string: 'WHERE time >= '...' ORDER BY time DESC'.\nThe absence of parameterization or input sanitization allows for UNION-based SQL injection. An attacker can craft a payload designed to terminate the intended query and append a UNION SELECT statement to extract data from other tables within the database.\nThe exploitation flow begins with an attacker saving a page containing the malicious payload via the standard page-edit interface. Because the 'recentchanges' action is triggered when the page is rendered or processed, the stored injection is executed persistently.\nIn a default YesWiki deployment, the 'default_write_acl' is set to allow anonymous users to edit pages, contingent upon passing a client-side hashcash JavaScript challenge. Once the hashcash is solved, the attacker can submit the malicious SQL string.\nUpon subsequent page loads, the 'PageManager::getRecentlyChanged()' function executes the malicious SQL query. The results of the injected query are then fetched and rendered into the HTML response of the page, effectively leaking database contents to the requester.\nThis vulnerability allows an attacker to perform unauthorized database reconnaissance and exfiltration. Since the output is rendered directly into the page content, the attacker can view the stolen data in their browser, and potentially expose it to other users if the trigger page is public or shared.\nThis issue affects all versions of YesWiki prior to 4.6.6."
}