CVE-2026-52766: YesWiki Authentication Bypass Vulnerability

CVE-2026-52766 Overview

YesWiki is an open-source wiki platform written in PHP. Versions prior to 4.6.6 expose a missing authorization flaw in the erasespamedcomments wiki action. The actions/EraseSpamedCommentsAction.php handler accepts a suppr[] array from a POST request and deletes every wiki page whose tag appears in that array. No authorization check exists in the action body or in the page-deletion path it invokes.

Combined with YesWiki's allow-by-default action Access Control List (ACL) model, any user with page write access can trigger the destructive action. Since fresh installs set default_write_acl='*', unauthenticated visitors can permanently delete arbitrary wiki pages, including the front page, admin pages, and pages owned by other users.

Critical Impact
Any user with write access, including unauthenticated visitors on default installations, can permanently delete arbitrary wiki pages across the site.

Affected Products

YesWiki versions prior to 4.6.6
YesWiki installations using the default write ACL (default_write_acl='*')
All wiki pages including administrative and front pages on affected instances

Discovery Timeline

2026-09-05 - CVE-2026-52766 published to the National Vulnerability Database (NVD)
2026-09-09 - Last updated in NVD database

Technical Details for CVE-2026-52766

Vulnerability Analysis

The flaw is classified as [CWE-276] Incorrect Default Permissions. The erasespamedcomments wiki action is intended for administrators cleaning spam comments. However, the handler never verifies that the requester holds administrative rights before executing page deletions.

An attacker submits a POST request containing a suppr[] parameter populated with target page tags. The action iterates the array and deletes each matching wiki page. Because YesWiki's ACL model allows any authenticated action by default, and fresh installations set the write ACL to *, the destructive endpoint is reachable by anyone able to reach the wiki.

Root Cause

The root cause is the absence of an authorization gate in actions/EraseSpamedCommentsAction.php. The action assumed contextual protection from the surrounding ACL system, but the default write='*' policy grants write access to all users. Neither the action nor the underlying page-deletion helper enforces an administrator check, allowing the deletion logic to run for any caller.

Attack Vector

Exploitation requires only network access to the YesWiki instance. An attacker crafts a POST request to the wiki page that renders {{erasespamedcomments}}, supplying an array of page tags to delete. The server processes the array and removes each page from the database, resulting in permanent data loss for the front page, admin pages, and any user-owned content.

php

// Patch applied in v4.6.6 - authorization check added at the start of run()
public function run()
{
    $wiki = &$this->wiki;

    if (!$wiki->UserIsAdmin()) {
        return $this->render('@templates/alert-message.twig', [
            'type' => 'danger',
            'message' => get_class($this) . ' : ' . _t('BAZ_NEED_ADMIN_RIGHTS'),
        ]);
    }

    ob_start();
    echo "\n<!-- == Action erasespamedcomments v 0.7 ============================= -->\n";
}

Source: YesWiki commit ed5b548a. The patch introduces a UserIsAdmin() check that aborts execution and renders an error template when the caller is not an administrator.

Detection Methods for CVE-2026-52766

Indicators of Compromise

POST requests to any YesWiki page containing a suppr[] parameter, especially from unauthenticated sessions
Sudden disappearance of wiki pages, including the front page or administrative pages, without a corresponding admin action in application logs
Web server access logs showing repeated requests referencing the erasespamedcomments action from a single source

Detection Strategies

Inspect HTTP request bodies at the reverse proxy or Web Application Firewall (WAF) for suppr[] array parameters targeting YesWiki endpoints
Correlate wiki page deletion events with the authenticated user identity and verify that the account holds administrator privileges
Alert on any invocation of the erasespamedcomments action originating from non-admin sessions

Monitoring Recommendations

Enable verbose logging of YesWiki action execution and capture the source IP, session identity, and parameters for each request
Track database row counts for the pages table and alert on bulk deletion events outside expected maintenance windows
Forward web and application logs to a centralized analytics platform to enable cross-source correlation and historical review

How to Mitigate CVE-2026-52766

Immediate Actions Required

Upgrade all YesWiki instances to version 4.6.6 or later without delay
Audit wiki content for missing pages and restore from backup where deletions are detected
Review the default_write_acl configuration and restrict write access to authenticated users where feasible

Patch Information

The fix ships in YesWiki v4.6.6 via commit ed5b548a. Additional context is available in GitHub Security Advisory GHSA-6x7x-gcmf-7r8x. The patch adds an administrator check at the top of the run() method in actions/EraseSpamedCommentsAction.php.

Workarounds

Block POST requests containing the suppr[] parameter at a WAF or reverse proxy until the upgrade is applied
Remove or comment out any wiki pages that render the {{erasespamedcomments}} action so the endpoint cannot be reached
Restrict write ACLs to authenticated administrators by changing default_write_acl from * to a role-limited value

bash

# Example WAF rule to block exploitation attempts against YesWiki
# ModSecurity rule blocking POST requests carrying the suppr[] parameter
SecRule REQUEST_METHOD "@streq POST" \
    "chain,phase:2,deny,status:403,id:1026527660,msg:'Block CVE-2026-52766 YesWiki suppr[] deletion attempt'"
    SecRule ARGS_NAMES "@rx ^suppr\[\]$" "t:none"