critical · 9.1CVE-2026-52766Jul 9, 2026

CVE-2026-52766: YesWiki Unauthenticated Arbitrary Page Deletion

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

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.

Packageyeswiki/yeswiki
Ecosystemcomposer
Affected< 4.6.6
Fixed in4.6.6

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.

http
# 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=AnotherTargetPage

Step 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).

Reporter not attributed.

References: [1][2][3]

Related research