Skip to main content
Vulnerability Database/CVE-2026-104456

CVE-2026-104456: YesWiki Second-Order SQL Injection Flaw

CVE-2026-104456 is a second-order SQL injection vulnerability in YesWiki before version 4.6.7 that allows attackers to exploit stored usernames to access database contents and bypass ACL protections. This article covers technical details, affected versions, security impact, and mitigation strategies.

Published:

CVE-2026-104456 Overview

CVE-2026-104456 is a second-order SQL injection vulnerability in YesWiki versions before 4.6.7. The flaw resides in the AclService::updateRequestWithACL method, where a stored username is concatenated unescaped into a read-ACL LIKE clause. An attacker self-registers an account whose name contains a double-quote payload. When any ACL-filtered listing is subsequently loaded, the stored payload executes against the database. The result is read-ACL bypass and unauthorized disclosure of database contents.

Critical Impact

Authenticated attackers with a self-registered account can bypass read access controls and exfiltrate database contents from vulnerable YesWiki instances.

Affected Products

  • YesWiki versions prior to 4.6.7
  • Deployments permitting self-registration of accounts
  • Web applications using the AclService component for ACL enforcement

Discovery Timeline

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

Technical Details for CVE-2026-104456

Vulnerability Analysis

The vulnerability is a second-order SQL injection classified under [CWE-89]. Unlike first-order injection, the malicious payload is persisted during one request (account registration) and executed later during a different request (ACL evaluation).

YesWiki stores the attacker-chosen username verbatim. When a user browses an entry list protected by read ACLs, AclService::updateRequestWithACL builds a SQL LIKE clause that references the viewer's username. Because the stored value is concatenated directly into the query string without escaping or parameterization, the embedded double-quote terminates the string literal and introduces attacker-controlled SQL.

Exploitation requires only a low-privilege, self-registered account. The attack vector is network-based and does not require user interaction. The resulting information disclosure impacts the confidentiality of the backing database and defeats read ACLs intended to restrict content visibility.

Root Cause

The root cause is unsafe string concatenation of a persisted, user-controlled identifier into a dynamic SQL LIKE expression. The AclService component trusts the stored username value and omits escaping or prepared-statement binding when assembling the ACL filter query.

Attack Vector

The attacker registers a YesWiki account whose username contains a double-quote followed by SQL fragments. The payload stays dormant until the application performs a non-admin, ACL-filtered listing operation. At that point, AclService::updateRequestWithACL reads the stored username, concatenates it into the LIKE clause, and executes the resulting injected query. The attacker can then read tables that the ACL would normally hide. See the GitHub Security Advisory GHSA-6rw5-62xf-q5xp and the VulnCheck Advisory on SQL Injection for additional technical detail.

Detection Methods for CVE-2026-104456

Indicators of Compromise

  • Newly registered accounts whose usernames contain double-quote characters, backslashes, SQL keywords such as UNION, SELECT, or inline comment sequences.
  • Database error entries or anomalous query durations correlated with page views of ACL-filtered listings.
  • Unexpected result sets or row counts returned from listing endpoints that normally enforce read ACLs.

Detection Strategies

  • Audit the users table for stored usernames containing characters outside an expected alphanumeric and punctuation set.
  • Enable database query logging and search for LIKE clauses in ACL-related queries that contain unbalanced quotes or injected SQL syntax.
  • Review web server logs for registration requests immediately followed by requests to listing or search endpoints by the same account.

Monitoring Recommendations

  • Monitor YesWiki authentication and registration events for abnormal account-creation patterns, especially from unauthenticated sources.
  • Alert on database errors emitted during execution of ACL filter queries.
  • Baseline normal response sizes for ACL-filtered endpoints and alert on significant deviations that may indicate ACL bypass.

How to Mitigate CVE-2026-104456

Immediate Actions Required

  • Upgrade all YesWiki instances to version 4.6.7 or later without delay.
  • Review the users table and remove or rename any accounts containing suspicious characters in the username field.
  • Audit database contents and application logs to determine whether read ACLs were bypassed prior to patching.

Patch Information

YesWiki 4.6.7 remediates the issue by properly escaping or parameterizing the username value used within AclService::updateRequestWithACL. Refer to the GitHub Security Advisory GHSA-6rw5-62xf-q5xp for the official upstream fix and release notes.

Workarounds

  • Disable public self-registration until the instance is upgraded, forcing administrator-controlled account provisioning.
  • Enforce strict server-side validation of usernames to allow only an alphanumeric character set.
  • Place the application behind a web application firewall configured to block registration payloads containing SQL metacharacters.
bash
# Configuration example
# See the vendor advisory for official remediation guidance:
# https://github.com/YesWiki/yeswiki/security/advisories/GHSA-6rw5-62xf-q5xp

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.