YesWiki Unauthenticated Arbitrary Page Deletion via Missing Authorization in EraseSpamedCommentsAction

Vulnerability Description

The EraseSpamedCommentsAction.php component in YesWiki fails to perform any authorization validation before processing POST parameters that trigger page deletion. The vulnerability chains three design flaws: (1) missing authorization checks in the action handler, (2) permissive default ACL configuration (default_write_acl='*'), and (3) the underlying PageManager::deleteOrphaned() method performing unconditional deletions across multiple database tables without validating deletion prerequisites. This results in an arbitrary deletion vulnerability classified as authorization bypass leading to data destruction.

PoC Significance

The disclosed PoC demonstrates exploitation requires minimal preconditions—only default write access (granted to all users in standard installations). The attack is highly reliable because it directly invokes the vulnerable POST handler without complex authentication bypasses. The PoC confirms that page deletion operations cascade across linked tables (pages, links, acls, triples, referrers, tags), meaning deletion is complete and unrecoverable without database backups. This is particularly dangerous for wiki front pages, administrative pages, and content owned by other users.

Detection Guidance

Web Application Firewall Signatures:

• Monitor POST requests to /actions/EraseSpamedCommentsAction.php or routes containing action=erasespamedcomments with parameters clean and suppr[]
• Flag requests from unprivileged users containing the suppr[] array parameter

Log Indicators:

• Suspicious DELETE operations in application logs preceded by action=erasespamedcomments requests
• Bulk page deletions within short timeframes from single source IP
• POST requests with suppr[] arrays containing page names from non-administrative sessions

Database Monitoring:

• Multi-table deletions across pages, acls, triples tables in single transaction
• Deletion patterns initiated from web application user context rather than administrative tools

Mitigation Steps

1. Immediate: Apply vendor patches when released; check YesWiki security advisories
2. Temporary Workaround: Disable or restrict access to actions/EraseSpamedCommentsAction.php via web server configuration until patched
3. Configuration Hardening: Change default_write_acl from '*' to specific authorized groups; implement least-privilege access
4. Code-Level Fix (when available): Ensure EraseSpamedCommentsAction.php validates user permissions before processing $_POST['suppr'][]; add authorization checks before invoking PageController::delete()
5. Backup Strategy: Maintain regular, tested database backups separate from production to enable rapid recovery from deletion attacks

Risk Assessment

Likelihood of Exploitation: High in the wild—the vulnerability requires only default configuration and is trivial to exploit via simple HTTP POST requests. Automated scanning tools can identify vulnerable YesWiki instances. Threat Actor Interest: Very high—wiki defacement and data destruction are common attack objectives. Competitors, disgruntled insiders, and opportunistic attackers will exploit this immediately upon disclosure. Business Impact: Critical—permanent loss of wiki content, reputation damage, compliance violations (data retention failures), and operational disruption. Default installations are immediately vulnerable with zero complexity barriers to exploitation.