CVE-2026-32767

What it actually does

SiYuan versions 3.6.0 and earlier expose an authorization bypass and SQL injection flaw in the `/api/search/fullTextSearchBlock` endpoint. When the `method` parameter is set to `2`, attacker-controlled input is passed to the underlying SQLite database as raw SQL without enforcing the authorization and read-only checks used by the intended SQL query endpoint. As a result, a low-privileged authenticated user, including a Reader-role user, can execute arbitrary SQL statements such as `SELECT`, `UPDATE`, `DELETE`, and `DROP TABLE`, causing full compromise of database confidentiality, integrity, and availability.

Why it matters to the business

A user with minimal access to a vulnerable SiYuan instance could read private knowledge-base content, alter or delete notes and metadata, corrupt the application database, or disrupt access to the workspace. Although the current EPSS score is low and the vulnerability is not listed in CISA KEV, the CVSS severity is critical because exploitation is simple once an attacker has access to the application. Organizations using SiYuan for operational notes, research, credentials, runbooks, or sensitive documentation should treat this as a high-priority data exposure and data-loss risk.

How an attack unfolds

An attacker first obtains access to a vulnerable SiYuan instance, either through a legitimate low-privileged account, a compromised account, or any deployment configuration that permits access to the affected API. The attacker sends a crafted request to `/api/search/fullTextSearchBlock` with `method` set to `2`. Instead of treating the supplied search text as a safe full-text search query, the vulnerable code passes it directly to SQLite as executable SQL. The attacker can then enumerate tables, extract note content and metadata, modify records, delete content, or run destructive statements that make the knowledge base unusable. This bypasses the product’s intended security model because equivalent raw SQL execution through `/api/query/sql` is supposed to require administrator privileges and read-only enforcement.

How to fix it

Upgrade SiYuan to version 3.6.1 or later, where the authorization bypass in `/api/search/fullTextSearchBlock` has been fixed. If immediate upgrade is not possible, restrict access to SiYuan to trusted users and networks, remove or disable Reader accounts that do not require access, and block requests to `/api/search/fullTextSearchBlock` where `method` is set to `2` at a reverse proxy or web application firewall if feasible. Ensure regular backups of the SiYuan workspace and SQLite database are available and tested, because exploitation can include destructive SQL operations. Review application permissions and avoid exposing SiYuan directly to untrusted networks.

How to confirm the fix worked

Confirm the installed SiYuan version is 3.6.1 or later. If version inventory is not reliable, perform a controlled test in a non-production or safely backed-up environment by sending a request to `/api/search/fullTextSearchBlock` with `method=2` using benign SQL syntax; patched systems should not execute arbitrary SQL through this endpoint and should enforce the intended authorization/read-only behavior. Validate that low-privileged or Reader-role users cannot execute SQL through search functionality. Review reverse proxy, API gateway, and application logs to ensure access to the affected endpoint is restricted or blocked as intended.

Typical attack path

1. Identify a SiYuan instance running version 3.6.0 or earlier.
2. Authenticate to the application or use an exposed deployment path that permits access to the API.
3. Send a request to `/api/search/fullTextSearchBlock` with `method=2`.
4. Place arbitrary SQLite SQL syntax in the user-controlled search input handled by the endpoint.
5. Run reconnaissance queries to identify database structure and sensitive content.
6. Execute SQL statements to read, alter, delete, or drop application data.
7. Optionally cover tracks by deleting or modifying records that show suspicious activity.

How to detect it

To determine whether exploitation already occurred, review application logs, reverse proxy logs, API gateway logs, and web server access logs for requests to `/api/search/fullTextSearchBlock` where `method` is `2`. Pay special attention to requests from Reader or low-privileged users, unusual request volumes, failed or malformed search requests, and request bodies or query parameters containing SQL syntax such as `SELECT`, `UNION`, `UPDATE`, `DELETE`, `DROP`, `sqlite_master`, comments, or semicolon-delimited statements. If request bodies were not logged, correlate endpoint access with unexpected database changes, application errors, workspace corruption, missing notes, or SQLite errors. Review filesystem timestamps and backups for unexpected changes to SiYuan SQLite database files around suspicious requests. Look for evidence of data enumeration followed by destructive statements. Because no public exploit indicators or named threat actors are provided, detection should focus on endpoint-specific access patterns and SQL-like payloads rather than fixed malware or infrastructure indicators.

• /api/search/fullTextSearchBlock
• method=2
• "method":2
• "method":"2"
• /api/search/fullTextSearchBlock?method=2
• sqlite_master
• UNION SELECT
• SELECT * FROM
• DROP TABLE
• DELETE FROM
• UPDATE
• INSERT INTO
• ALTER TABLE
• PRAGMA table_info
• --
• /*
• */
• ; DROP
• ; DELETE
• /api/query/sql

What your security team should do

• Upgrade all SiYuan installations to version 3.6.1 or later as the primary remediation.
• Prioritize internet-accessible or multi-user SiYuan deployments, especially where Reader-role or other low-privileged accounts exist.
• Take and verify backups before remediation if there is any suspicion of exploitation or database corruption.
• Search historical logs for suspicious use of `/api/search/fullTextSearchBlock` with `method=2`, especially requests containing SQL keywords or schema-enumeration patterns.
• Review SiYuan database integrity and recent content changes for unauthorized deletion, modification, or unexpected missing notes.
• Restrict SiYuan access to trusted networks or authenticated access paths; avoid direct public exposure.
• Rotate credentials or secrets stored in SiYuan if logs or database review suggests unauthorized data access.
• Create detection rules for requests to the affected endpoint containing SQL control words, comment syntax, or destructive statements.