SiYuan CVE-2026-72811: backlinks create a path to SQL injection

CVE-2026-72811, a critical SQL injection vulnerability in SiYuan, was published on 14 August 2026. The issue affects releases through 3.7.2, while the vendor identifies 3.7.4 as the fixed version. It sits in backlink and mention search, a feature intended to help users discover relationships between notes. In practice, block metadata and a client-supplied keyword can reach a manually assembled SQL statement.

The project advisory scores the vulnerability 10.0 under CVSS 3.1 and 9.9 under CVSS 4.0. The effect is not limited to reading one note. Queries run against the primary siyuan.db database, and the selected driver variant supports multiple statements. Possible consequences include cross-notebook disclosure, record modification, deletion and persistent database damage.

How the vulnerable flow works

The root cause appears in backlink-related code, including kernel/model/backlink.go. The application constructs a full-text search condition from several inputs: block title, name, alias, anchor text and a client keyword. Some characters are transformed, but a single quote is not safely parameterised. That lets a value escape its text context and alter SQL syntax.

The first route is conventional first-order SQL injection. A search parameter supplied in the current request is concatenated into a query and sent to the database engine. The attacker receives the effect through the same workflow. According to the advisory, affected operations include getBacklink, getBacklink2, getBacklinkDoc and getBackmentionDoc.

The second route is more subtle because it is second-order SQL injection. Malicious text can initially be stored as ordinary metadata through a correctly parameterised INSERT. Nothing necessarily fails at that stage. A later backlink operation reads the stored title, alias or anchor and pastes it into a new statement. Safe storage therefore does not guarantee safe reuse.

This is an important code-review lesson. A value is not trusted merely because it came from the application’s own database. That database may hold content previously controlled by a user, import, synchronisation job or integration. Every transition into a SQL interpreter must apply parameterisation appropriate to the current context.

Who can trigger the flaw

Risk is highest where SiYuan exposes publishing or sharing features to a broad audience. The advisory describes paths reachable by an anonymous user or an account with a reader role. This is especially serious because an organisation may treat a reader as a principal with no ability to modify data.

With second-order injection, one person can prepare a block containing malicious metadata and another user can trigger the vulnerable lookup later. Application logs may show two events separated by time, identity and function. Monitoring that evaluates only a single request may never connect cause and effect.

Exposed assets include team knowledge bases, published documentation instances, private servers placed behind reverse proxies and environments synchronising notebooks across devices. Their databases may hold technical notes, configuration fragments, internal addresses, incident procedures and personal data. Even when the application stores no formal secret, its context can materially accelerate lateral movement.

Why impact goes beyond disclosure

SQL injection is often associated with stolen records, but the possible effect here is broader. Multi-statement execution can enable additions, changes and deletion. An attacker may alter note content, metadata and relationships between blocks. For a knowledge base, that creates an integrity problem: users can no longer know whether an operating instruction, configuration or incident record remains authentic.

Integrity is particularly important for security documentation. A discreet change to a recovery command, repository address, firewall rule or deployment step may survive longer than obvious deletion. A backup can restore a file, but without a timeline and independent logs it can be difficult to establish which records should be trusted.

Access to the primary database can also cross logical notebook boundaries. Application controls may limit what the interface presents to a reader, while a manipulated statement executes below that layer where the same rules may not apply. Impact analysis should therefore not stop at permissions visible in the user interface.

What defenders should do now

The priority action is upgrading to SiYuan 3.7.4 or a later release containing the fix. Before deployment, back up the database and configuration, test restoration and record checksums. An upgrade removes the vulnerable behaviour going forward, but cannot reverse modifications that may already have occurred.

Until the upgrade is complete, restrict publishing and backlink functionality. A reverse proxy should require strong authentication, and the application should not be directly reachable from the Internet. Where public notes are necessary, consider a static export without dynamic kernel endpoints. Run the process under a minimally privileged account and store backups outside directories the application can modify.

After upgrading, perform an integrity review. Compare current notes and records with the latest trusted backup. Investigate unusual changes to titles, aliases and anchors, bulk edits, deletions and events close to calls to backlink endpoints. If notes contained secrets or tokens, treat database read access as a reason to rotate them.

Detecting attempted exploitation

In reverse-proxy logs, review requests to backlink and mention functions containing unusual quotes, SQL comment forms, character encoding or exceptionally long parameters. Do not base detection on a single signature. Content can be encoded, split or stored earlier in metadata, so the absence of a recognisable string in the triggering request does not exclude exploitation.

At the database layer, look for syntax errors, unexpected write statements and abrupt changes in row counts. Send security logs away from the application host. If an attacker can modify the database, local artefacts alone are not a reliable source of truth.

Second-order injection requires correlation. Preserve who created a block or changed metadata and when, then connect that history with later backlink use. A useful alert identifies both the request that caused execution and the object that supplied the reused value.

Engineering out the broader bug class

The correct defence is consistent use of driver-bound parameters. Manually adding quotes, replacing selected characters or allowing a few fragments is not equivalent protection. If full-text search has a special query language, keep its structure separate from data and use a library designed for that grammar.

Tests should follow values through storage. They should first save metadata containing quotes and boundary sequences, then invoke every function that consumes the stored value. Data-flow analysis should continue marking user-controlled fields as untrusted whether their immediate source is HTTP, an import file or a database row.

Impact containment matters as well. Separating public reads from the working database, maintaining immutable backups, versioning content and using a least-privileged database account all reduce blast radius. A WAF may stop selected first-order attempts, but it cannot replace the code fix, especially for a second-order path.

Facts, Breachroad conclusions and the next step

The advisory establishes that versions through 3.7.2 are vulnerable, that both first- and second-order SQL injection paths exist, that severity is critical and that 3.7.4 contains the fix. It also establishes that the primary database is involved and that operations can extend beyond reads. The publication alone does not demonstrate widespread exploitation in the wild.

Breachroad’s conclusion is that an organisational knowledge base should be handled as a high-value system. It contains context linking people, infrastructure and procedures, so compromise can speed later attack stages. Upgrading is the first action; integrity verification, secret rotation and surface reduction are what close the response.

If you need to verify whether knowledge applications, management panels and APIs enforce their intended trust boundaries, see our web application and API penetration testing. Teams building or operating these systems can complement that work with cybersecurity training for organisations focused on real data flows and defensive decisions.