SiYuan is self-hosted

CVE-2025-21609 is an arbitrary file deletion bug in SiYuan Note 3.1.18. A crafted POST to /api/history/getDocHistoryContent can pass a chosen historyPath; the vulnerable code path would try to parse the target as document history and, on parse failure, call os.RemoveAll on that path. The vendor fix in commit d9887ae adds a workspace-bound path check and removes the delete-on-parse-error behavior, with the fix shipped in 3.1.19.

The vendor's 9.1 CRITICAL score is technically understandable for a trivially reachable destructive action, but it overstates enterprise urgency in the real world. This is a single-version, self-hosted, relatively niche product; official API docs frame the service on 127.0.0.1:6806, while server-style Docker deployments are what turn it into a remotely reachable problem. So the real story is high-risk when exposed, not universally critical by default.

Why this verdict

• Baseline down from vendor CRITICAL: the vendor/NVD score treats this like a generic exposed web app, but SiYuan is a niche self-hosted PKM platform rather than a broadly deployed enterprise edge product.
• Exact-version narrowing: the affected range is only 3.1.18, which sharply reduces fleet-wide exposure versus a multi-version defect.
• Exposure is usually operator-created: official docs place the API on 127.0.0.1:6806, while official Docker docs separately show how to publish 6806; that means many instances are local-only or intentionally gated.
• Impact is destructive, not executable: the bug deletes files and can break service or data, but there is no demonstrated RCE, privilege escalation, or direct data exfiltration primitive in this CVE alone.
• Threat intel stays cold: no KEV entry and a low EPSS value reduce urgency versus bugs already under live attacker pressure.

Why not higher?

I am not keeping this at CRITICAL because the CVSS headline ignores the biggest real-world friction: not every SiYuan instance is an Internet-facing server. It also hits one exact version and delivers deletion, not code execution. Those are meaningful downward pressures for a defender prioritizing thousands of assets.

Why not lower?

I am not dropping this to MEDIUM because, once a vulnerable instance is reachable, exploitation is simple and low-noise. A single crafted request can delete arbitrary writable files, and that is enough to cause material data loss or operational disruption on an exposed host.

1. Remove public reachability to 6806 — If any SiYuan 3.1.18 instance is Internet-reachable, put it behind VPN, allowlists, or a reverse proxy that is not publicly open. For a HIGH verdict, deploy this containment within 30 days, sooner for any system already exposed externally.
2. Enforce front-door authentication — Set and verify --accessAuthCode or the equivalent environment variable, and require upstream auth if you reverse-proxy SiYuan. This does not prove the vulnerable endpoint is fully protected in every deployment, but it materially reduces opportunistic abuse; deploy within 30 days.
3. Constrain filesystem blast radius — Run the service with the least-privileged account possible and keep host mounts minimal so os.RemoveAll can only damage the workspace you intended. That limits worst-case file deletion impact; harden within 30 days.
4. Add detection on the history endpoint — Alert on POSTs to /api/history/getDocHistoryContent, especially from automation, unusual source IPs, or with suspicious absolute paths. Logging and detections should be in place within 30 days so you can spot abuse before the patch rollout finishes.
5. Protect restore points — Because this is a deletion bug, offline or immutable backups are your real safety net if somebody hits it before you patch. Validate that workspace snapshots and mounted-volume backups are restorable within 30 days.

Run this from a host that can reach the SiYuan service, ideally the target host itself or an auditor workstation on the same network. Invoke it as SIYUAN_TOKEN='your-token-if-needed' ./check-siyuan-cve-2025-21609.sh http://127.0.0.1:6806; it needs only network access to the API endpoint and no elevated privileges.

#!/usr/bin/env bash
# check-siyuan-cve-2025-21609.sh
# Purpose: determine whether a SiYuan instance is vulnerable to CVE-2025-21609
# Logic: query /api/system/version and compare against the known affected version 3.1.18
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

BASE_URL="${1:-http://127.0.0.1:6806}"
TOKEN="${SIYUAN_TOKEN:-}"
ENDPOINT="${BASE_URL%/}/api/system/version"
TMP_BODY="$(mktemp 2>/dev/null || echo /tmp/siyuan-cve-2025-21609.$$)"
trap 'rm -f "$TMP_BODY" >/dev/null 2>&1 || true' EXIT

if ! command -v curl >/dev/null 2>&1; then
  echo "UNKNOWN - curl not found"
  exit 2
fi

HDRS=(-H "Content-Type: application/json")
if [ -n "$TOKEN" ]; then
  HDRS+=(-H "Authorization: Token $TOKEN")
fi

HTTP_CODE="$(curl -sS -m 10 -o "$TMP_BODY" -w "%{http_code}" -X POST "${HDRS[@]}" "$ENDPOINT" -d '{}' 2>/dev/null || true)"

if [ -z "$HTTP_CODE" ] || [ "$HTTP_CODE" = "000" ]; then
  echo "UNKNOWN - unable to reach $ENDPOINT"
  exit 2
fi

BODY="$(cat "$TMP_BODY" 2>/dev/null || true)"
VERSION="$(printf '%s' "$BODY" | sed -n 's/.*"data"[[:space:]]*:[[:space:]]*"\([^"]\+\)".*/\1/p' | head -n1)"
CODE_FIELD="$(printf '%s' "$BODY" | sed -n 's/.*"code"[[:space:]]*:[[:space:]]*\([0-9-]\+\).*/\1/p' | head -n1)"

if [ -z "$VERSION" ]; then
  echo "UNKNOWN - could not parse version from response (HTTP $HTTP_CODE)"
  exit 2
fi

case "$VERSION" in
  3.1.18)
    echo "VULNERABLE - SiYuan version $VERSION matches the affected release for CVE-2025-21609"
    exit 1
    ;;
  3.1.19|3.1.20|3.1.*|3.2.*|3.3.*|3.4.*|3.5.*|3.6.*|4.*)
    echo "PATCHED - SiYuan version $VERSION is not the affected release"
    exit 0
    ;;
  *)
    if [ "$CODE_FIELD" != "0" ] && [ -n "$CODE_FIELD" ]; then
      echo "UNKNOWN - API returned code=$CODE_FIELD and version=$VERSION"
      exit 2
    fi
    echo "UNKNOWN - unrecognized version format: $VERSION"
    exit 2
    ;;
 esac

Sources

1. NVD CVE-2025-21609
2. GitHub Security Advisory GHSA-8fx8-pffw-w498
3. Fix commit d9887ae
4. Official SiYuan API documentation
5. Official SiYuan repository / Docker deployment docs
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS
8. SUSE CVE page