YesWiki EUVD-2026-109465

Requires a reachable YesWiki instance on an affected version with at least one Bazar form present (Bazar is a core feature in typical deployments), and the attacker must know or guess a Bazar form identifier (form id 1 is used in the PoC). No authentication, cookies, or tokens are needed - exploitation is against the default public ACL of the entries search API. The attacker supplies a field name containing a backtick in the query or searchfields parameter. Limiting factors: full data-exfiltration and DoS impact is confirmed only on versions >=4.6.7 through 5.0.0-alpha3 (in 4.6.0-4.6.6 the payload returns no rows so injected data does not surface); impact is confined to arbitrary SQL SELECT reads and availability because the database driver rejects stacked queries, so direct INSERT/UPDATE/DELETE is not possible through this vector.

Multiple signals agree this is a genuine priority for any YesWiki operator, not an inflated high-CVSS issue. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes trivial exploitation: a single unauthenticated network GET request with no user interaction and no special timing, which the GHSA advisory corroborates with concrete working payloads. Impact is high on both confidentiality (VC:H - direct read of user password hashes returned in the JSON response, no blind technique needed) and availability (VA:H - SLEEP() subqueries exhaust the database connection pool); integrity is correctly VI:N because the driver rejects stacked queries, limiting the vector to SELECT-context reads. The vuln.today decision label is 'this_week' (not act_now/emergency), consistent with a serious but not CISA-confirmed-exploited flaw. No CISA KEV listing is present in the input, so there is no confirmed active exploitation; EPSS is not provided, so widespread-exploitation probability cannot be quantified from this data. A detailed public PoC (full HTTP request payloads) exists in the GHSA advisory. The one tempering signal is product footprint: YesWiki is niche software, so mass automated exploitation is less likely than for ubiquitous platforms - but because exploitation is unauthenticated and trivial, every reachable affected instance should be treated as at immediate risk.

An unauthenticated attacker reaches a YesWiki site's public Bazar entries search API (GET /api/forms/{formId}/entries/...) and submits a query field name containing a backtick, breaking out of the SQL alias and injecting a scalar subquery. In one GET request they exfiltrate username and password-hash pairs from the users table directly in the JSON response, or submit SLEEP() subqueries to block database threads and take the site offline. A detailed proof-of-concept with working HTTP payloads is published in the GHSA advisory.