Summary
SiYuan on Windows contains a sensitive-path validation bypass in the standard Markdown import API. An authenticated API caller may use a Windows extended-length path prefix to copy protected workspace files, including API tokens and TLS private keys, into assets that unauthenticated clients can access.
SiYuan on Windows contains a sensitive-path validation bypass in the standard Markdown import API. An authenticated API caller may use a Windows extended-length path prefix to copy protected workspace files, including API tokens and TLS private keys, into assets that unauthenticated clients can access.
Affected context
The issue occurs in SiYuan deployments running on Windows when the import API accepts attacker-influenced local paths and relies on a denylist check after path normalization. The Windows extended-length path prefix can remain intact after cleaning and avoid matching forbidden path prefixes, allowing sensitive workspace files to be copied into web-accessible asset locations.
The issue occurs in SiYuan deployments running on Windows when the import API accepts attacker-influenced local paths and relies on a denylist check after path normalization. The Windows extended-length path prefix can remain intact after cleaning and avoid matching forbidden path prefixes, allowing sensitive workspace files to be copied into web-accessible asset locations.
Exploit preconditions
- Attack surface: The authenticated standard Markdown import API
- Required access: Valid authentication or an account permitted to invoke the API
- Trigger point: Processing of a crafted
localPathvalue during file import - Why exploitation is possible: Path normalization does not account for the Windows extended-length prefix before sensitive-path comparisons, allowing protected paths to bypass the denylist
- Attack surface: The authenticated standard Markdown import API
- Required access: Valid authentication or an account permitted to invoke the API
- Trigger point: Processing of a crafted
localPathvalue during file import - Why exploitation is possible: Path normalization does not account for the Windows extended-length prefix before sensitive-path comparisons, allowing protected paths to bypass the denylist
Why this happens
The vulnerability results from incomplete canonicalization and denylist-based path validation on Windows. The application checks whether a cleaned path begins with a forbidden prefix, but the \\?\ extended-length syntax can cause the resulting path representation to differ from the patterns used by the validation logic. This maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory, because attacker-controlled path input can reach files outside the intended import scope.
The vulnerability results from incomplete canonicalization and denylist-based path validation on Windows. The application checks whether a cleaned path begins with a forbidden prefix, but the \\?\ extended-length syntax can cause the resulting path representation to differ from the patterns used by the validation logic. This maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory, because attacker-controlled path input can reach files outside the intended import scope.
Potential impact
- API tokens may be disclosed
- TLS private keys may be exposed
- Workspace configuration and other sensitive files could be copied
- Unauthenticated clients may retrieve copied files from served assets
- Attackers could use disclosed credentials for further account or service compromise
- API tokens may be disclosed
- TLS private keys may be exposed
- Workspace configuration and other sensitive files could be copied
- Unauthenticated clients may retrieve copied files from served assets
- Attackers could use disclosed credentials for further account or service compromise
General mitigation guidance
Mitigation generally focuses on robust, platform-aware path confinement rather than relying solely on string-prefix denylists.
Common defensive patterns include:
- Canonicalizing and validating paths using Windows-aware filesystem semantics
- Rejecting alternate path syntaxes, including extended-length prefixes, unless explicitly required
- Resolving the candidate path and verifying that it remains within an intended import directory
- Using allowlisted source directories and file types instead of sensitive-path denylists
- Preventing imported files from being placed in unauthenticated web-accessible locations
- Applying least privilege to the service account and protecting credential and key files with restrictive permissions
- Separating private configuration storage from user-controlled or publicly served asset directories
Mitigation generally focuses on robust, platform-aware path confinement rather than relying solely on string-prefix denylists.
Common defensive patterns include:
- Canonicalizing and validating paths using Windows-aware filesystem semantics
- Rejecting alternate path syntaxes, including extended-length prefixes, unless explicitly required
- Resolving the candidate path and verifying that it remains within an intended import directory
- Using allowlisted source directories and file types instead of sensitive-path denylists
- Preventing imported files from being placed in unauthenticated web-accessible locations
- Applying least privilege to the service account and protecting credential and key files with restrictive permissions
- Separating private configuration storage from user-controlled or publicly served asset directories
How teams detect issues like this
High-level detection can include:
- Static analysis rules for path checks based only on string prefixes or incomplete normalization
- Code review searches for file operations that consume API-provided paths
- Tests covering Windows drive paths, UNC paths, dot segments, symbolic links, and extended-length prefixes
- Runtime monitoring for imports that reference configuration, credential, key, or parent-directory locations
- Access-log review for unusual downloads from asset paths following import activity
- Policy enforcement requiring canonical path resolution and directory-boundary checks before file access
Automated code review and security testing tools may help identify inconsistent path handling across operating systems.
High-level detection can include:
- Static analysis rules for path checks based only on string prefixes or incomplete normalization
- Code review searches for file operations that consume API-provided paths
- Tests covering Windows drive paths, UNC paths, dot segments, symbolic links, and extended-length prefixes
- Runtime monitoring for imports that reference configuration, credential, key, or parent-directory locations
- Access-log review for unusual downloads from asset paths following import activity
- Policy enforcement requiring canonical path resolution and directory-boundary checks before file access
Automated code review and security testing tools may help identify inconsistent path handling across operating systems.
