SiYuan kernel versions before 3.7.4 contain an improper restriction of excessive authentication attempts…

CVE-2026-73056 affects SiYuan kernel versions before 3.7.4. The CheckAuth() middleware validates the API token (Conf.Api.Token) via Authorization header or ?token= query parameter, but neither path integrates with the built-in CAPTCHA or lockout mechanisms (NeedCaptcha / WrongAuthCount). An unauthenticated remote attacker can make unlimited guesses against the token, and if successful, gains RoleAdministrator access — enabling arbitrary file operations and SQL queries against the workspace database. A companion issue (CVE-2026-73046) affects the HTTP Basic Auth branch similarly.

The vendor's CVSS 9.8 CRITICAL rating assumes an internet-reachable instance with a weak, guessable token. That score dramatically overstates the risk for enterprise environments. SiYuan is a *personal* open-source note-taking and knowledge management app with ~45k GitHub stars — it is not enterprise infrastructure. The vast majority of its ~45,000 active installations run as local desktop apps bound to localhost, completely unreachable from the network. Only the self-hosted Docker/VPS subset is remotely exploitable, and even then, brute-forcing a sufficiently entropic token is computationally infeasible. For an enterprise fleet of 10,000 hosts, SiYuan presence is likely single-digit at best, installed ad-hoc by individual developers — not centrally managed, not on a critical path, and not holding regulated data.

Why this verdict

• Exposure population near zero: SiYuan is a personal knowledge management desktop app. Default installations bind the kernel to 127.0.0.1:6806. Only the Docker/VPS self-hosted minority are remotely reachable, and enterprise adoption is negligible — most 10,000-host fleets have zero SiYuan instances in their CMDB.
• Token entropy kills the chain: The brute-force is only viable against short PINs or dictionary-word tokens. Any token of 12+ random alphanumeric characters (~71 bits) is computationally infeasible to guess at network speeds. The vulnerability is real but practical exploitation requires a weak token.
• Blast radius is personal-workspace-scoped: Even full exploitation yields access to notes, documents, and workspace SQL — not OS-level access, not domain credentials, not lateral movement. There is no privilege escalation to the host OS without chaining a separate RCE vulnerability.
• Role multiplier: SiYuan occupies *no* high-value infrastructure role. It is not a domain controller, identity provider, hypervisor, CI/CD server, backup system, or network edge appliance. It is a personal productivity tool. The worst plausible role is a team knowledge base on a single VPS, where compromise affects document integrity for that team — a bounded, tenant-scoped impact. No high-value-role floor applies.
• No active exploitation or KEV listing: No evidence of in-the-wild use, no campaigns, no KEV entry. The CVE was disclosed yesterday (2026-08-16) with a fix already available.

Why not higher?

To warrant HIGH, the affected component would need to occupy a high-value infrastructure role or have demonstrated active exploitation. SiYuan is a personal note-taking tool with near-zero enterprise footprint, localhost-default binding, and token-entropy-dependent exploitation. The blast radius is limited to workspace documents with no lateral movement — there is no plausible path to domain compromise, fleet impact, or regulated data exposure through this vulnerability alone.

Why not lower?

The vulnerability mechanism is real and technically sound — CheckAuth() genuinely lacks rate limiting. If an organization does run an internet-exposed SiYuan instance with a weak token (e.g., a developer's personal VPS syncing work notes), the compromise is complete within that workspace. The unauthenticated-remote attack vector with no user interaction keeps this above LOW for the narrow population that is exposed.

1. Audit for SiYuan instances on your network — Run an asset discovery scan for port 6806 and SiYuan kernel HTTP fingerprints. Most enterprises will find zero instances. If found, determine whether they are internet-exposed. No mitigation SLA applies at MEDIUM — go straight to the 365-day remediation window.
2. Block external access to port 6806 — If any SiYuan instances are found exposed to the internet, immediately restrict access via firewall rules or reverse-proxy ACLs to trusted source IPs only. This eliminates the remote attack vector entirely.
3. Enforce strong API tokens — If SiYuan must remain accessible, ensure the Conf.Api.Token is at least 20 random alphanumeric characters. This makes brute-force computationally infeasible regardless of the missing rate limiting.
4. Upgrade to SiYuan v3.7.4 — The fixed version integrates CAPTCHA/lockout into the CheckAuth() path. Apply within the 365-day noisgate remediation SLA for MEDIUM findings.

Run this on any host with network access to the SiYuan instance. Invoke with: bash check_siyuan_cve2026_73056.sh <hostname:port>. No special privileges required — it makes a single unauthenticated HTTP request to check the version.

#!/usr/bin/env bash
# check_siyuan_cve2026_73056.sh — Check SiYuan kernel version for CVE-2026-73056
# Usage: bash check_siyuan_cve2026_73056.sh <host:port>
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN

set -euo pipefail

if [ $# -lt 1 ]; then
  echo "Usage: $0 <host:port>" >&2
  echo "Example: $0 siyuan.internal:6806" >&2
  exit 2
fi

TARGET="$1"
URL="https://${TARGET}/api/system/version"

# Attempt HTTPS first, fall back to HTTP
RESPONSE=$(curl -sk --connect-timeout 5 --max-time 10 "$URL" 2>/dev/null)
if [ -z "$RESPONSE" ]; then
  URL="http://${TARGET}/api/system/version"
  RESPONSE=$(curl -s --connect-timeout 5 --max-time 10 "$URL" 2>/dev/null)
fi

if [ -z "$RESPONSE" ]; then
  echo "UNKNOWN — Could not reach SiYuan kernel at ${TARGET}"
  exit 2
fi

# Extract version from JSON response
VERSION=$(echo "$RESPONSE" | grep -oP '"data"\s*:\s*"\K[0-9]+\.[0-9]+\.[0-9]+' 2>/dev/null || true)

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — Could not parse version from response: ${RESPONSE}"
  exit 2
fi

echo "Detected SiYuan kernel version: ${VERSION}"

# Compare version — vulnerable if < 3.7.4
IFS='.' read -r MAJOR MINOR PATCH <<< "$VERSION"

if [ "$MAJOR" -lt 3 ] || \
   { [ "$MAJOR" -eq 3 ] && [ "$MINOR" -lt 7 ]; } || \
   { [ "$MAJOR" -eq 3 ] && [ "$MINOR" -eq 7 ] && [ "$PATCH" -lt 4 ]; }; then
  echo "VULNERABLE — SiYuan ${VERSION} is affected by CVE-2026-73056 (fixed in 3.7.4)"
  exit 0
else
  echo "PATCHED — SiYuan ${VERSION} includes the fix for CVE-2026-73056"
  exit 1
fi

Sources

1. TheHackerWire — SiYuan Kernel API Token Brute-Force (CVE-2026-73056)
2. GitHub — siyuan-note/siyuan repository
3. GitHub Security Advisories — SiYuan
4. THREATINT — CVE-2026-73046 (companion Basic Auth brute-force)
5. RedPacket Security — SiYuan CVE Alerts
6. LiuYun — SiYuan Security Flaw Exposed
7. FIRST — Exploit Prediction Scoring System (EPSS)