SiYuan CVE-2026-87808

Three concrete conditions must all be satisfied: (1) the attacker must hold a valid SiYuan administrator account - standard user accounts are insufficient; (2) the target workspace must be running with the --readonly=true flag active, as this is the protection mechanism being bypassed (workspaces not using this flag are not affected by this specific bypass); and (3) the attacker must be able to reach the SiYuan API endpoint over the network. The bypass is isolated to the SQL mode (method=2) of /api/search/fullTextSearchBlock; other search methods in the same endpoint are not affected. The administrator credential requirement is the primary limiting factor: this is not exploitable by unauthenticated or low-privilege users, and it presupposes a trust boundary violation scenario where an admin should not have SQL-level query access in read-only mode.

The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H, score 8.7) contains two significant discrepancies with the described behavior: PR:L overstates accessibility since the description explicitly requires an administrator account, and VI:H/VA:H are not supported by the described impact of read-only SQL access to the blocks database. The realistic impact is limited to confidentiality. Even a mid-sized municipal IT team in rybnik should treat this as a meaningful but bounded risk - the read-only mode is a deliberate security boundary, and its bypass exposes the entirety of a user's note content to an admin operating under the assumption that the mode is enforced. Because exploitation requires an administrator credential, automated or mass exploitation is implausible; the attacker population is narrow. No KEV listing or EPSS data is present in the input; active exploitation is not confirmed. The practical risk is primarily relevant to multi-user SiYuan deployments where read-only mode enforces a trust separation between administrator accounts and the underlying data store.

An administrator authenticates to a SiYuan workspace running with --readonly=true and sends a POST request to /api/search/fullTextSearchBlock with method=2 and an arbitrary SQL SELECT statement targeting the blocks table. Because the endpoint does not call model.CheckReadonly, the query executes and returns raw database contents - note bodies, metadata, and any other data in the blocks database - despite the read-only mode that was intended to prevent this access. No public exploit code has been identified at time of analysis.