YesWiki CVE-2026-104456

Requires a YesWiki instance (before 4.6.7) that permits account self-registration, and the attacker must be able to create an account whose username contains a double-quote SQL payload - the username is stored and later concatenated unescaped into the read-ACL LIKE clause built by AclService::updateRequestWithACL. Exploitation is then triggered by loading a non-admin, ACL-filtered listing that invokes that code path. Limiting factors: a (low-privilege) authenticated account is required per PR:L, so instances with self-registration disabled or restricted username validation substantially raise the bar; no user interaction by a victim is needed, and impact is confined to reading database contents/bypassing read ACLs rather than full write or RCE.

This is a genuine but moderate-priority issue, not an emergency. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H) scores 7.2 and indicates a network-reachable, low-complexity attack requiring only low privileges - satisfied by a self-registered account, which on a public YesWiki instance is a trivially low bar. The primary impact is confidentiality (VC:H: reading arbitrary database contents and bypassing read ACLs), with only low integrity/availability impact (VI:L/VA:L) and no scope change (SC:N). No EPSS score was provided, this CVE is NOT in CISA KEV, and no public POC is indicated - so there is no public exploit identified at time of analysis and no evidence of active exploitation. The reporting by VulnCheck and the existence of a GitHub Security Advisory (GHSA-6rw5-62xf-q5xp) confirm the technical validity, but the real-world threat is tempered by low product prevalence and the authentication requirement. Net: a real, patchable data-disclosure flaw worth remediating promptly on internet-facing instances that allow self-registration, but not a drop-everything event absent exploitation signals.

An attacker self-registers an ordinary YesWiki account using a username containing a crafted double-quote SQL payload, which is stored verbatim. They then browse a non-admin, ACL-filtered listing page, causing AclService::updateRequestWithACL to concatenate their stored username unescaped into a read-ACL LIKE clause, executing the injected SQL. No public POC is identified at time of analysis, but the technique is well-understood and low-complexity.