On October 25, 2026, NVD published CVE-2026-116207, an unauthenticated SQL injection in YesWiki, an open source wiki popular with nonprofits, community groups and local authorities, especially in French-speaking countries.
The flaw sits in the public search API for Bazar entries, YesWiki's built-in database module. It lets an anonymous caller read the database, user password hashes included, or tie up the database server. And it comes down to an escaping detail that a lot of PHP developers assume is safe.
The vulnerability
| Field | Value |
|---|---|
| CVE | CVE-2026-116207 |
| CVSS 3.1 (VulnCheck) | 9.1 (CRITICAL) — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H |
| CVSS 4.0 (VulnCheck) | 8.8 (HIGH) |
| Weakness | SQL injection (CWE-89) |
| Authentication | None |
| Component | SearchManager::prepareSearchRequest(), Bazar search API |
| NVD published | 2026-10-25 |
| NVD status | Deferred (no NIST analysis) |
Scores come from VulnCheck as CNA. NVD has marked the entry Deferred and attached no CPE configuration. The CVE is not in the CISA KEV catalog at the time of writing.
The 3.1 vector reads plainly: remote, no account, no user interaction, high confidentiality impact (reading the database) and high availability impact (exhausting connections), but no integrity impact (I:N).
How it works: mysqli_real_escape_string inside backticks
The Bazar search API takes two parameters, query and searchfields, that carry field names. Those names go into the SQL statement as backtick-quoted aliases (`field_name`), and the only protection applied is mysqli_real_escape_string.
The catch: that function is built for values inside quotes. It escapes single and double quotes, backslashes, newlines and so on, but not the backtick. Drop a backtick into a field name and you close the alias, then write the rest of the query yourself.
Per the NVD description, that gives an attacker:
- injected subqueries to read data such as account password hashes;
- database thread exhaustion through
SLEEP()calls, taking the wiki offline.
The lesson travels well beyond YesWiki: an SQL identifier (column, table, alias) is not escaped the way a value is. The right fix is an allowlist of permitted names, never escaping.
Why leaked hashes matter
A hash is not a password. But on a community wiki, admin accounts often have short passwords or ones reused elsewhere, and once the hashes are out, offline cracking is a matter of time. That is our inference, not something NVD states. If your instance was exposed, treat the passwords as compromised.
Affected versions
| Branch | Affected | First version outside the range (NVD description) |
|---|---|---|
| 4.x | 4.6.0 up to, not including, 4.7.0 | 4.7.0 |
| 5.0 (pre-releases) | 5.0.0-alpha1 to alpha3 | 5.0.0-alpha4 |
These bounds come from the NVD description, not from a CPE configuration. Check the recommended version in YesWiki's GitHub security advisories (two are referenced: GHSA-ccp2-6q93-hggh and GHSA-hgxv-w4r8-8877) before you call an instance fixed.
Detection
- Version: YesWiki shows its version on the update page of the admin interface.
- Web server logs: requests to the Bazar search API where
queryorsearchfieldscontain backticks (encoded%60), SQL keywords (SELECT,UNION) orSLEEP. - Database: spikes in connections or long-running queries, MySQL/MariaDB threads stuck in
SLEEP. - Accounts: unusual admin logins after a suspicious window.
Mitigation
- Upgrade to 4.7.0 or later (or past 5.0.0-alpha4 if you run the 5.x pre-releases).
- Until then, block requests to the Bazar API carrying a backtick in
queryorsearchfieldsat the web server or WAF. - Restrict the MySQL account YesWiki uses to its own database.
- If the instance was exposed, reset account passwords, admins first.
Why continuous monitoring of self-hosted apps matters
YesWiki is exactly the kind of tool a volunteer or a communications team installs outside the IT inventory, which is also why its flaws stay open for a long time.
With cveo.tech, track your self-hosted web applications too, and get an alert as soon as a CVE affects them, even before NVD has analyzed it.