Attack Chain

1. Initial Compromise: A low-privilege authenticated user gains access to a YesWiki instance.
2. Malicious Page Creation: The attacker sends a POST request to /api/pages/{tag} with a URL-encoded malicious tag (e.g., SleepTag%27%20OR%20SLEEP(2)--%20) containing SQL metacharacters. This tag is stored unescaped in the yeswiki_pages database table.
3. Linker Page Creation: The attacker creates a second, benign page, for example, LinkPoc, via POST /api/pages/LinkPoc.
4. Establish Link: The attacker updates the LinkPoc page (e.g., via the LinkPoc/edit web editor handler) to include a reference to the malicious page using {{include page="<evil tag>"}}. This action causes the application to insert a row into the yeswiki_links table, establishing a link to the malicious page and storing its raw, unescaped tag as to_tag.
5. Vulnerability Trigger: The attacker sends a DELETE request to /api/pages/{evil-tag} for the malicious page. The DELETE request targets the same URL-encoded malicious tag as created in step 2.
6. SQL Injection Execution: During the deletion process, the YesWiki application retrieves the stored malicious tag from the database and uses it unescaped in an SQL query like DELETE FROM yeswiki_links WHERE to_tag = '$tag'. The injected SQL (e.g., OR SLEEP(2)-- ) is then executed within the database.
7. Data Exfiltration: By varying the injected SQL payload, such as using conditional SLEEP() statements, the attacker can perform time-based blind data exfiltration of sensitive information from any accessible database table.

Impact

Successful exploitation of this vulnerability can lead to time-based blind exfiltration of sensitive data from the YesWiki database. This includes highly sensitive information such as user password hashes (_users.password), email addresses, Access Control List (ACL) configurations (_acls.list), private page bodies (_pages.body), and database session data. Given the "acl:+" access control, any authenticated user, regardless of their privilege level, can initiate this attack. The impact can range from unauthorized disclosure of user data to full compromise of the wiki's content and user base.

Recommendation

1. Immediately patch YesWiki installations to the latest version to address GHSA-8f2v-2qhj-gfwg.
2. Deploy the Detect YesWiki SQLi Attempt via URL-encoded Single Quote Sigma rule to your SIEM and tune it for your environment.
3. Enable comprehensive webserver logging (e.g., access logs) for the webserver category to activate the provided Sigma rule.