GHSA-89v6-j5x6-cmj3 is a medium-severity (CVSS 6.5) SQL Injection vulnerability in yeswiki/yeswiki. O3 Security confirms whether GHSA-89v6-j5x6-cmj3 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
YesWiki: SQL injection via the `recentchanges` action `period` argument leads to arbitrary DB read
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-89v6-j5x6-cmj3 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 370,894 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
The recentchanges action (actions/recentchanges.php) accepts a period argument from two disjoint parameter spaces: the URL query string ($_GET['period']) and the action invocation {{recentchanges period="..."}}. A whitelist at line 17 validates only the URL form against ['day','week','month']. The action-argument form takes the else branch at line 33 ($dateMin = $this->GetParameter('period')) with no validation, and the value flows into PageManager::getRecentlyChanged() (includes/services/PageManager.php:196), where it is interpolated into a WHERE time >= '...' ORDER BY time DESC clause without escaping or parameterization. UNION-based injection succeeds, the leaked rows render into the response page via actions/recentchanges.php:43,58 (ComposeLinkToPage($page['tag'])), so any visitor of the trigger page sees the exfiltrated data.
The vulnerability provides arbitrary read of the YesWiki database to anyone who can save the trigger page. On a default install (default_write_acl='*'), this includes anonymous users, subject to the hashcash JS check on the page-edit form. Once the trigger page is saved, every subsequent view fires the injection as the SQLi is stored. Stored SQL injection is reachable through the page-edit flow, with arbitrary database read.
Details
Two issues compose the vulnerability.
-
actions/recentchanges.phpline 33 reads the action argument and skips the whitelist.if (isset($_GET['period']) && in_array($_GET['period'], ['day', 'week', 'month'])) { switch ($_GET['period']) { case 'day': $d = strtotime('-1 day'); $dateMin = date('Y-m-d H:i:s', $d); break; case 'week': $d = strtotime('-1 week'); $dateMin = date('Y-m-d H:i:s', $d); break; case 'month': $d = strtotime('-1 month'); $dateMin = date('Y-m-d H:i:s', $d); break; } } else { $dateMin = $this->GetParameter('period'); }Wiki::GetParameter()(includes/YesWiki.php:895) reads$this->parameter[$key], which is populated from the{{action key=value}}argument list — disjoint from$_GET. The whitelist'sifbranch only runs when$_GET['period']matches one of three exact values; in every other case theelsebranch reads the action argument with no validation, no escaping, no DateTime parse, no regex. The two parameter spaces are independent. -
In
includes/services/PageManager.php,PageManager::getRecentlyChanged()interpolates the value into SQL.
public function getRecentlyChanged($limit = 50, $minDate = ''): ?array
{
if (!empty($minDate)) {
if ($pages = $this->dbService->loadAll(
'select id, tag, time, user, owner from' . $this->dbService->prefixTable('pages')
. "where latest = 'Y' and comment_on = '' and time >= '$minDate' order by time desc"
)) {
return $pages;
}
}
}
$minDate is interpolated raw into the query and there is no $this->dbService->escape($minDate) and no parameter binding and no format check.
The default action ACL for recentchanges is * (includes/YesWiki.php:1100, GetModuleACL), so Performer::CheckModuleACL('recentchanges', 'action') returns true for everyone. The injection runs whenever a viewer reaches a page that embeds the action with a malicious period argument.
PoC
Default fresh install so default_write_acl='*'.
- place the SQLi payload on a page
{{recentchanges period="2000-01-01' UNION SELECT 9999 AS id, CONCAT('LEAK_', name, '_', SUBSTRING(password,1,32)) AS tag, NOW() AS time, name AS user, name AS owner FROM yeswiki_users WHERE name='AdminUser' -- "}}
The five UNION columns match the id, tag, time, user, owner projection that getRecentlyChanged selects. The tag column is rendered into the response as a hyperlink, exfiltrating the leaked data.
- anyone visits the page
GET /?<TriggerPage> HTTP/1.1
Host: target.example
The injected query executes server-side; the tag column is rendered into the page in actions/recentchanges.php:43,58 via ComposeLinkToPage($page['tag']).
Impact
Arbitrary read of any DB column the application's MySQL user can access.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | yeswiki/yeswiki | all versions | 4.6.6 |
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.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-89v6-j5x6-cmj3 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-89v6-j5x6-cmj3 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-89v6-j5x6-cmj3. 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-89v6-j5x6-cmj3 in your dependencies?
O3 detects GHSA-89v6-j5x6-cmj3 across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.