CVE-2026-52766: YesWiki Unauthenticated Arbitrary Page Deletion
Any anonymous visitor of a default YesWiki install can permanently delete any wiki page, including the front page, by abusing the unguarded spam-cleanup action.
The problem
The {{erasespamedcomments}} wiki action (actions/EraseSpamedCommentsAction.php) reads a suppr[] array from $_POST and passes each entry straight to PageController::delete(). There is no authentication check, no ownership check, and no CSRF token validation anywhere in the action.
On a fresh install, YesWiki defaults to default_write_acl='*', meaning everyone, including anonymous users, can create a page and embed the action. Because no permissions map gates erasespamedcomments to admins, CheckModuleACL() returns true for unauthenticated callers.
The downstream PageManager::deleteOrphaned() method issues unconditional DELETE queries across the pages, links, acls, triples, referrers, and tags tables for whatever tag is supplied. There is no orphan check, no existence check, and no authorization check.
Proof of concept
A working proof-of-concept for CVE-2026-52766 in yeswiki/yeswiki, with the exact payload below.
# Step 1: create a trigger page (anonymous) embedding the action
POST /?wiki=SpamCleanup/edit HTTP/1.1
Host: target.example
Content-Type: application/x-www-form-urlencoded
body=%7B%7Berasespamedcomments%7D%7D&submit=1
# Step 2: trigger arbitrary page deletion (anonymous)
POST /?wiki=SpamCleanup HTTP/1.1
Host: target.example
Content-Type: application/x-www-form-urlencoded
clean=yes&suppr%5B0%5D=PagePrincipale&suppr%5B1%5D=AnotherTargetPageStep 1 works because aclService->hasAccess('write', 'SpamCleanup') resolves against default_write_acl='*', so any visitor can create the page and plant the action. Step 2 works because EraseSpamedCommentsAction::run() enters the $_POST['clean'] branch with zero guard: no UserIsAdmin(), no per-page HasAccess('write', $page), no CSRF token.
Each value in suppr[] is forwarded directly to PageController::delete(), which calls PageManager::deleteOrphaned() unconditionally.
The patch commit ed5b548 adds an admin authorization check at the top of the action's run() method, so non-admin callers are rejected before any POST body is processed. CWE-862 (Missing Authorization) is the primary root cause; CWE-276 (Incorrect Default Permissions) is the enabling condition.
The fix
Upgrade to YesWiki 4.6.6. The patch (commit ed5b548a705c8091ba0282aaaba73ddda976abef) adds an admin guard at the entry point of EraseSpamedCommentsAction::run(), blocking non-admin callers before any POST data is read. If you cannot upgrade immediately, remove or restrict the erasespamedcomments action by adding it to your site's permissions config map and setting its ACL to % (admins only).
Related research
- high · 8.2CVE-2026-52767CVE-2026-52767: YesWiki ActivityPub Signature-Verification Bypass
- high · 8.3CVE-2026-52769CVE-2026-52769: YesWiki Unauthenticated SSRF via ActivityPub Signature keyId
- high · 7.5CVE-2026-52770CVE-2026-52770: YesWiki Bazar API Unauthenticated Boolean-Based SQL Injection
- high · 8.3CVE-2026-52771CVE-2026-52771: YesWiki Second-Order SQL Injection in Page Delete API