CVE-2026-104460: YesWiki Blind SQL Injection Vulnerability

CVE-2026-104460 Overview

CVE-2026-104460 is an unauthenticated blind SQL injection vulnerability in YesWiki versions before 4.6.7. The flaw resides in the {{newtextsearch}} action, where Bazar list option identifiers are concatenated directly into SQL REGEXP and LIKE clauses in actions/newtextsearch.php without escaping. Anonymous attackers can plant a malicious option id in any anonymously editable Bazar list, then issue search requests that behave as a boolean oracle. This allows attackers to extract arbitrary data from the backend database, including administrator password hashes stored in the yeswiki_users table.

Critical Impact
Unauthenticated remote attackers can exfiltrate database contents, including administrator credential hashes, enabling full site takeover after offline hash cracking.

Affected Products

YesWiki versions prior to 4.6.7
Deployments exposing the {{newtextsearch}} action with anonymously editable Bazar lists
Any YesWiki instance using actions/newtextsearch.php without the upstream patch

Discovery Timeline

2026-10-02 - CVE-2026-104460 published to NVD
2026-10-02 - Last updated in NVD database

Technical Details for CVE-2026-104460

Vulnerability Analysis

The vulnerability is a classification [CWE-89] SQL injection flaw that affects the full-text search workflow in YesWiki. The {{newtextsearch}} action retrieves option identifiers associated with Bazar lists and interpolates them into SQL filter clauses that use REGEXP and LIKE operators. Because these identifiers originate from a Bazar list configuration that unauthenticated users can edit when the list is marked anonymously editable, attackers control the content ultimately placed into the SQL statement.

The search endpoint returns different response states based on query results. Attackers exploit this difference as a boolean oracle, extracting one bit of information per request through conditional payloads. Repeating this process reveals arbitrary rows and columns, including entries in the yeswiki_users table where administrator password hashes reside.

Root Cause

The root cause is missing input sanitization and the absence of parameterized queries in actions/newtextsearch.php. Option identifiers sourced from Bazar lists are treated as trusted strings and inserted directly into dynamic SQL. YesWiki does not apply escaping, type validation, or allowlisting before concatenation, so attacker-controlled characters alter the query structure.

Attack Vector

An anonymous attacker first identifies a YesWiki instance running a vulnerable version with at least one anonymously editable Bazar list. The attacker edits the list to insert a crafted option id containing SQL metacharacters and conditional expressions. Subsequent requests to the {{newtextsearch}} action trigger the injection, and the boolean response differences allow iterative extraction of database contents. No authentication, no user interaction, and no local access are required.

For technical reproduction details, consult the GitHub Security Advisory GHSA-4333-x9p4-8xj7 and the VulnCheck Advisory for YesWiki blind SQL injection.

Detection Methods for CVE-2026-104460

Indicators of Compromise

Unusual edits to Bazar list configurations containing SQL metacharacters such as single quotes, parentheses, SELECT, UNION, SLEEP, BENCHMARK, or IF( within option identifiers.
High-volume requests to pages invoking the {{newtextsearch}} action from a single IP within short time windows, consistent with boolean-oracle extraction.
Web server access logs showing search requests referencing option ids that do not match any legitimate Bazar entry.
Database query logs showing malformed or unusually long REGEXP/LIKE clauses sourced from the search action.

Detection Strategies

Enable MySQL or MariaDB general query logging on YesWiki backends and alert on REGEXP or LIKE clauses containing boolean injection patterns.
Deploy a Web Application Firewall (WAF) rule to flag search requests to YesWiki endpoints containing SQL keywords in parameters.
Audit all Bazar list definitions for option identifiers containing non-alphanumeric characters outside the expected character set.

Monitoring Recommendations

Forward YesWiki web server, PHP error, and database logs to a centralized SIEM for correlation across edit and search events.
Alert on password hash reads from the yeswiki_users table that do not originate from the authentication subsystem.
Monitor administrative accounts for unexpected login attempts following suspected extraction activity.

How to Mitigate CVE-2026-104460

Immediate Actions Required

Upgrade YesWiki to version 4.6.7 or later immediately on all production and staging instances.
Audit every Bazar list for the anonymously editable setting and revoke anonymous edit rights where not strictly required.
Review the yeswiki_users table and force password resets for administrators if extraction activity is suspected.
Rotate any secrets or API tokens stored in the YesWiki database.

Patch Information

The YesWiki maintainers addressed this vulnerability in release 4.6.7. The fix adds proper escaping of Bazar list option identifiers before they are concatenated into REGEXP and LIKE SQL clauses within actions/newtextsearch.php. Operators should apply the upstream release and verify the patched file is present. Refer to the GitHub Security Advisory GHSA-4333-x9p4-8xj7 for authoritative patch details.

Workarounds

Disable anonymous edit permissions on all Bazar lists until the upgrade is deployed.
Restrict access to pages invoking the {{newtextsearch}} action to authenticated users via web server access controls.
Deploy a WAF signature blocking SQL metacharacters in requests targeting YesWiki search endpoints.
Place the YesWiki instance behind an authenticating reverse proxy if public anonymous access is not required.

bash

# Example nginx snippet to restrict the newtextsearch action to authenticated sessions
location ~* /\?.*newtextsearch {
    auth_basic "YesWiki restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
}