CVE-2026-52771 in YesWiki
Summary
by MITRE • 09/05/2026
YesWiki is a wiki system written in PHP. From version 4.2.0 to before version 4.6.6, ApiController::deletePage() interpolates a page tag retrieved from the database into a DELETE FROM …_links WHERE to_tag = '$tag' query without escaping. The page tag is attacker-controlled — the POST /api/pages/{tag} API accepts arbitrary URL-encoded values, including single quotes, and stores them. A low-privilege authenticated user can therefore create a page whose tag is a SQL fragment, make the page non-orphaned via the standard {{include page="…"}} link mechanism, and then invoke the delete endpoint to execute arbitrary SQL inside the wiki database - including time-based blind data exfiltration from any table. This issue has been patched in version 4.6.6.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/05/2026
YesWiki is a collaborative wiki system implemented in PHP that allows users to create and manage content through various API endpoints. A critical security vulnerability exists within the ApiController::deletePage() method, affecting versions from 4.2.0 up to but not including version 4.6.6. This flaw constitutes an SQL injection vulnerability resulting from improper neutralization of special elements used in SQL commands. The specific technical failure occurs when the delete endpoint processes a page tag retrieved directly from the database and interpolates it into a DELETE statement without applying any escaping or parameterization mechanisms. The affected query structure is formatted as DELETE FROM …_links WHERE to_tag = '$tag', where the variable $tag is populated with user-supplied data that has been stored in the system previously.
The attack vector relies on the ability of an authenticated, low-privilege user to manipulate page tags and leverage existing wiki linking mechanisms. An attacker can create a new page using the POST /api/pages/{tag} endpoint, supplying arbitrary URL-encoded values for the tag parameter. Because this input is stored in the database without sanitization against SQL syntax, it becomes possible to inject malicious SQL fragments into the tag field. To trigger the injection, the attacker must ensure that the crafted page is not an orphan by using the standard wiki include mechanism, specifically {{include page="…"}}, which establishes a link reference to the target page. Once this linkage is established, invoking the delete endpoint for any other page causes the system to query and process the malicious tag stored in the database, thereby executing the injected SQL code within the context of the application's database connection.
The operational impact of this vulnerability is severe, as it allows an authenticated user with minimal privileges to execute arbitrary SQL commands against the underlying wiki database. This capability extends beyond simple data deletion or modification; it enables time-based blind data exfiltration from any table accessible by the database user account running the application. Through careful construction of boolean and timing conditions within the injected payload, an attacker can systematically extract sensitive information such as administrative credentials, session tokens, or other confidential wiki content without triggering immediate error messages that might alert administrators to the breach. This represents a significant compromise of data integrity and confidentiality, violating fundamental security principles regarding input validation and query safety.
This vulnerability aligns with Common Weakness Enumeration (CWE) identifiers including CWE-89 for Improper Neutralization of Special Elements used in an SQL Command and CWE-79 for Cross-site Scripting if the output is reflected improperly, though here it primarily impacts backend data security. In terms of the MITRE ATT&CK framework, this exploitation technique corresponds to T1059.004 for Command Line Interface scripting via PHP and potentially T1005 for Data from Local System depending on what information is exfiltrated. The root cause lies in the failure to use prepared statements or parameterized queries when constructing SQL commands with dynamic data derived from user-controlled sources, even if that source appears indirect through database retrieval rather than direct HTTP input at the moment of execution.
Mitigation strategies must prioritize upgrading the YesWiki installation to version 4.6.6 or later, where this issue has been patched by implementing proper escaping and parameterization techniques for all SQL queries involving user-supplied data. For environments that cannot immediately upgrade, administrators should enforce strict validation on page tag inputs at creation time to prevent storage of malicious payloads, although this is a less robust defense than fixing the query construction logic itself. Additionally, applying the principle of least privilege to the database account used by the web application can limit the scope of damage if an injection occurs, restricting access to only those tables and operations necessary for core functionality. Regular security audits focusing on SQL query generation patterns across all API endpoints are recommended to identify similar vulnerabilities in other parts of the system.