Description

SiYuan versions <= 3.8.1 (fixed in v3.8.2) contain an incomplete blocklist in the IsForbiddenAbsPath() function (kernel/util/path_guard.go), which only blocks conf/conf.json by exact match and does not restrict the TLS private key (conf/key.pem) or CA private key (conf/ca.key) stored in the same conf/ directory. Because the getFile handler skips the blocklist for RoleAdministrator and all authenticated users receive RoleAdministrator in v3.8.1, any user (or any client on a default no-auth-code instance) can retrieve these private keys via POST /api/file/getFile. On deployments with TLS enabled, this allows decryption of captured HTTPS traffic (key.pem) and forging of certificates trusted by clients that imported SiYuan's CA (ca.key).

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-03T13:06:25.270Z",
  "pubdate": "2026-09-03T13:06:25.270Z",
  "executiveSummary": "SiYuan versions 3.8.1 and earlier contain a critical security vulnerability involving an incomplete path blocklist and a flawed authorization check. The vulnerability resides within the file retrieval mechanism, which fails to properly restrict access to sensitive cryptographic assets stored in the configuration directory.\nThe vulnerability allows unauthorized users—including those on instances without authentication codes—to access sensitive files, specifically TLS private keys (conf/key.pem) and CA private keys (conf/ca.key). By exploiting the RoleAdministrator privilege assignment logic, attackers can bypass intended access controls to exfiltrate these keys.\nThe impact of this vulnerability is severe, as it enables the decryption of intercepted HTTPS traffic and facilitates the creation of forged certificates. This compromises the integrity and confidentiality of the entire communication channel. The flaw stems from an insufficient validation process in the file handling layer combined with a logic error that grants administrative privileges to all authenticated users, effectively rendering the restriction mechanism useless against malicious or unauthorized actors.",
  "technicalDetails": "The root cause of this vulnerability lies in the IsForbiddenAbsPath() function located in kernel/util/path_guard.go, which implements a narrow blocklist that only filters for exact matches of conf/conf.json. This implementation fails to account for other highly sensitive files residing within the conf/ directory, specifically conf/key.pem and conf/ca.key.\nThe vulnerability is further exacerbated by the logic within the getFile handler. In SiYuan version 3.8.1, the application automatically assigns the RoleAdministrator privilege to all authenticated users. Since the getFile handler explicitly skips the IsForbiddenAbsPath() security check for users possessing the RoleAdministrator role, any authenticated user—or any user on a default instance that does not require an authentication code—can bypass the path guard entirely.\nThe attack flow proceeds as follows: First, an attacker identifies a target SiYuan instance. If the instance is configured without an authentication code, the attacker interacts directly with the API. If authentication is enabled, the attacker authenticates normally, which automatically grants them the RoleAdministrator role. Second, the attacker crafts a POST request to the /api/file/getFile endpoint, specifying the path to the desired sensitive file (e.g., conf/key.pem or conf/ca.key). Third, the system evaluates the request, determines the user possesses administrative privileges, and bypasses the file blocklist check. Finally, the application returns the contents of the requested file in the HTTP response.\nThe exploitation allows an attacker to retrieve the TLS private key (key.pem), which enables the decryption of captured HTTPS traffic, leading to a total loss of data confidentiality. Furthermore, the exfiltration of the CA private key (ca.key) allows an attacker to sign fraudulent certificates that will be trusted by any clients that have previously imported the SiYuan CA, leading to potential man-in-the-middle attacks and complete identity spoofing. The vulnerability persists in versions up to and including 3.8.1, with a fix implemented in version 3.8.2."
}