Description

YesWiki is a wiki system written in PHP. Prior to version 4.6.6, the {{erasespamedcomments}} wiki action (actions/EraseSpamedCommentsAction.php) accepts a suppr[] array from POST and deletes every wiki page whose tag appears in that array, with no authorization check anywhere in the action body or in the page-deletion path it invokes. Combined with YesWiki's allow-by-default action ACL model, any user who has page write access, which is the default for everyone (default_write_acl='*') on a fresh install can permanently delete arbitrary wiki pages, including the front page, admin pages, and pages owned by other users. This issue has been patched in version 4.6.6.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-09-05T00:17:19.393Z",
  "pubdate": "2026-09-05T00:17:19.393Z",
  "executiveSummary": "The YesWiki wiki system is susceptible to an unauthorized arbitrary page deletion vulnerability existing in the 'erasespamedcomments' wiki action.\nThis vulnerability is classified as an improper access control issue, allowing any authenticated or unauthenticated user with default write access to delete critical system pages, including administrative content and front-page data.\nThe root cause lies in the total absence of authorization checks within the 'actions/EraseSpamedCommentsAction.php' file and the subsequent page-deletion logic it triggers.\nGiven that YesWiki utilizes an 'allow-by-default' access control list (ACL) model (default_write_acl='*'), the attack surface is significantly broad, as most default installations grant sufficient write permissions to anonymous or low-privileged users.\nSuccessful exploitation results in permanent data loss and potential site-wide denial-of-service through the deletion of core navigation or structural wiki pages.\nThis issue affects all versions of YesWiki prior to 4.6.6.",
  "technicalDetails": "The vulnerability is located in the 'actions/EraseSpamedCommentsAction.php' file, which implements a administrative-style cleanup function that lacks necessary authorization enforcement.\nThe component processes a POST request containing an array parameter identified as 'suppr[]'. This array is intended to hold the names or tags of wiki pages slated for deletion.\nUpon receiving the 'suppr[]' array, the action iterates through the provided values and executes an internal page-deletion routine for each referenced page tag. The flaw is rooted in the lack of an intermediate security verification layer, such as checking for administrative privileges or ownership validation, prior to invoking the deletion routine.\nUnder the default YesWiki configuration, the ACL is set to 'default_write_acl=*', which implicitly grants any user with basic write access the ability to invoke wiki actions. Because the 'erasespamedcomments' action fails to validate the user's privilege level, the application treats any request containing the 'suppr[]' parameter as a legitimate command to purge site content.\nAn attacker can exploit this by crafting a malicious HTTP POST request containing the 'suppr[]' array populated with the identifiers of target wiki pages. By enumerating or guessing page names—or targeting known pages like 'admin', 'FrontPage', or specific content pages—an attacker can induce the backend to delete these objects permanently.\nSince the deletion path performs a hard removal of these pages without restriction, the exploitation process is straightforward and does not require elevated administrative tokens, provided the attacker has the baseline write permissions common in default YesWiki environments.\nThe impact of this vulnerability is severe, as it facilitates unauthorized destruction of data and potentially breaks the wiki's functional integrity. Since pages are permanently removed, recovery requires backups, and the exploitation can be automated to target a wide range of pages in a single request, leading to rapid degradation or complete removal of the wiki site content."
}