CVE-2026-73056

SiYuan note-taking software contains a critical authentication bypass in its API token validation middleware. The CheckAuth() function, which validates tokens passed via theAuthorization: token X header, performs no rate limiting, CAPTCHA challenge, or account lockout on repeated failures. An unauthenticated attacker can brute force API tokens with no enumeration resistance. Combined with the Conf.Api.Token configuration — which allows administrators to set human-memorable tokens of arbitrary weakness — this enables trivial credential stuffing attacks that succeed in seconds against any deployment using weak tokens. What makes this noteworthy is not the missing rate limit itself, but what its existence reveals about the codebase. SiYuan already implements NeedCaptcha and WrongAuthCount for its primary login flow. These mechanisms exist. The developers knew how to prevent brute force attacks. What they failed to do was audit every authentication entry point for uniform protection application. CheckAuth() was written under the assumption that API tokens are machine-generated 32-byte random values with sufficient entropy to make enumeration impractical — an assumption that Conf.Api.Token directly contradicts by allowing short, human-chosen strings. This is the ergonomic trap in API-first authentication: tokens feel like cryptographic keys, not passwords, so developers skip the friction of rate limiting. But when a product explicitly supports configurable, shareable tokens for administrative access — tokens that grant RoleAdministrator and enable arbitrary file and SQL operations — the mismatch between assumed token strength and actual token weakness creates a catastrophic attack path. The distance from unauthenticated network access to kernel-level compromise collapses to a single step: guess weak token, get admin, own the system. The fix is adding rate limiting to CheckAuth(). But the deeper lesson is about threat model inheritance: new authentication vectors do not automatically inherit security controls from existing paths. Organizations should treat any new auth mechanism as requiring explicit verification that it passes through the same protection layers as established paths — not as inheriting security by default because it uses a different header format. Additionally, the security assumptions embedded in middleware code can become invalid as product features evolve (such as adding Conf.Api.Token), and there should be a process to surface when those assumptions no longer match current usage patterns.

Reviewed through automated stages and approved by a human before publication.