CVE-2026-52763: YesWiki SQL Injection Vulnerability

CVE-2026-52763 Overview

CVE-2026-52763 is a stored SQL injection vulnerability in YesWiki, a PHP-based wiki system. The flaw exists in the recentchanges action (actions/recentchanges.php) prior to version 4.6.6. The action accepts a period argument from two disjoint parameter spaces, but only the URL form is validated against a whitelist of ['day','week','month']. The action-argument form bypasses validation entirely and flows unescaped into a SQL WHERE clause. Any user able to save a wiki page can plant a persistent UNION-based injection payload. On default installs where default_write_acl='*', anonymous users can trigger the flaw, subject only to a client-side hashcash check [CWE-89].

Critical Impact
Attackers achieve arbitrary read access to the YesWiki database, with results rendered directly on the trigger page for every subsequent visitor.

Affected Products

YesWiki versions prior to 4.6.6
Default installations with default_write_acl='*' (anonymous write access)
Any deployment exposing the page-edit flow to untrusted users

Discovery Timeline

2026-09-05 - CVE-2026-52763 published to NVD
2026-09-08 - Last updated in NVD database

Technical Details for CVE-2026-52763

Vulnerability Analysis

The recentchanges action in YesWiki processes a period parameter that can arrive through two distinct paths. When supplied via the URL query string, the value is validated against a strict allowlist containing day, week, and month. When supplied through the action-argument form embedded in wiki markup, the code falls through to an else branch that performs no validation.

The unvalidated value then reaches PageManager::getRecentlyChanged(), where it is interpolated directly into a SQL statement of the form WHERE time >= '...' ORDER BY time DESC. No escaping or parameterization is applied. UNION-based injection succeeds, and leaked rows are rendered into the response page as part of the recent-changes listing.

Because the payload lives inside a saved wiki page, the injection is stored. Every subsequent view of the trigger page re-executes the malicious query and exposes exfiltrated data to any visitor.

Root Cause

The root cause is inconsistent input validation across two parameter entry points combined with unsafe SQL string interpolation. The whitelist logic protects only one code path, leaving the action-argument form as an unguarded sink for attacker-controlled data.

Attack Vector

An attacker with write access to any page, including anonymous users on default installations, edits a page and embeds a recentchanges action with a crafted period argument containing a UNION SELECT payload. After saving the page (satisfying the client-side hashcash proof-of-work), the injection becomes persistent. Every user who loads the page triggers the query and receives the exfiltrated database contents rendered inline.

Vulnerability mechanism (prose description):

1. Attacker edits a wiki page and inserts an action tag invoking
   the recentchanges action with a malicious period argument.
2. YesWiki saves the page after the hashcash JS check.
3. On render, actions/recentchanges.php parses the action argument,
   skips whitelist validation, and passes the value to
   PageManager::getRecentlyChanged().
4. The value is concatenated into a WHERE clause without escaping.
5. A UNION SELECT statement executes and results are displayed
   inline to every visitor of the trigger page.

See the GitHub Security Advisory for authoritative technical details.

Detection Methods for CVE-2026-52763

Indicators of Compromise

Wiki pages containing recentchanges action tags with unusual period argument values that do not match day, week, or month.
Database query logs showing UNION SELECT statements originating from the getRecentlyChanged code path.
Rendered wiki pages displaying database column data (usernames, password hashes, configuration values) inside the recent-changes listing.
Unexpected page edits from anonymous or low-privilege accounts targeting pages that embed action tags.

Detection Strategies

Audit stored wiki page content for action invocations of recentchanges and inspect any non-whitelisted period values.
Enable MySQL or MariaDB general query logging and alert on UNION keywords in queries containing time >=.
Compare rendered page output against expected recent-changes output to identify anomalous columns or row counts.

Monitoring Recommendations

Monitor web access logs for POST requests to the page-edit endpoint from anonymous sources followed by GET requests spiking on the same page.
Track outbound response sizes for pages containing recentchanges actions to identify data leakage bursts.
Alert on new or modified pages that embed action arguments referencing SQL keywords such as SELECT, UNION, or --.

How to Mitigate CVE-2026-52763

Immediate Actions Required

Upgrade YesWiki to version 4.6.6 or later without delay. See the GitHub Release v4.6.6.
Review the GitHub Security Advisory GHSA-89v6-j5x6-cmj3 for authoritative remediation guidance.
Audit all existing wiki pages for embedded recentchanges action tags containing suspicious period arguments and remove or sanitize them.
Rotate database credentials and any secrets that may have been exposed through the wiki's database.

Patch Information

The vulnerability is patched in YesWiki version 4.6.6. The fix corrects the validation gap so that the period argument is subject to the same allowlist regardless of whether it arrives via URL parameter or action-argument form. Administrators should apply the upgrade through the standard YesWiki update process and verify version reporting after deployment.

Workarounds

Restrict page-edit permissions by changing default_write_acl from * to an authenticated role, blocking anonymous edits.
Place the wiki behind an authenticating reverse proxy until the patch can be applied.
Deploy a web application firewall rule that inspects wiki page content submissions for recentchanges action tags with non-whitelisted period values.

bash

# Example: restrict anonymous write access in wakka.config.php
# Change the default write ACL from wildcard to authenticated users only
'default_write_acl' => '@admins',

# Verify installed YesWiki version after patching
grep -R "YESWIKI_VERSION" includes/constants.php