CVE-2026-52771: YesWiki · Second-Order SQL Injection in Page Delete API via Unescaped Page Tag (`ApiController::deletePage`)
Affects yeswiki/yeswikiSource GCVE Database
Not known to be exploited · CVSS 8.3 High : upgrade to 4.6.6 soon.
Data as of 30 Oct 2026, 06:59 UTC
- EPSS
- 0.5% chance of exploitation in 30 days – higher than 43% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 4.6.6
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:LExploitation evidence
Disclosed: evidence found.
CVE published 9 Jul 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.
What to do
Upgrade yeswiki/yeswiki to 4.6.6.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| Packagistyeswiki/yeswiki | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
If you cannot patch yet, restrict access to the API delete endpoint to trusted users only, or disable the API if possible. Avoid creating pages with untrusted tags and monitor for suspicious activity. Review and update the code to properly escape or parameterize SQL queries that use user-controlled data retrieved from the database. Do not rely solely on escaping at insert time; ensure all SQL query inputs are safely handled at every usage point.
Description
YesWiki versions 4.2.0 through 4.6.5 contain a second-order SQL injection vulnerability in the ApiController::deletePage() method. An authenticated low-privilege user can create a page with a malicious tag containing SQL code, which is stored safely but later used unescaped in a DELETE SQL query. This allows execution of arbitrary SQL commands in the wiki database, including time-based blind data exfiltration. The vulnerability arises because the page tag is read back from the database and interpolated into a SQL query without proper escaping. Exploitation requires three steps: planting the malicious tag, making the page non-orphaned via an include directive, and invoking the delete API endpoint.