GO-2026-4705: SiYuan: Incomplete sensitive path blocklist in globalCopyFiles allows reading /proc and Docker secrets

Q: Who can exploit this issue?

An attacker needs administrative access to the SiYuan globalCopyFiles API. They can then request files readable by the SiYuan process, including files outside the workspace that are not covered by the incomplete sensitive-path blocklist.

Q: Are containerized deployments particularly exposed?

Yes. In containerized deployments, injected secrets and process environment variables may be readable through paths such as /run/secrets/ and /proc/1/environ, which are not blocked by the affected versions' sensitive-path checks.

Q: How can I tell whether sensitive data may already have been exposed?

Files copied through globalCopyFiles become available through the standard workspace file API and remain there until manually deleted. Review workspace contents for copied sensitive files and remove any discovered artifacts.

Q: What should be done if immediate patching is not possible?

Restrict administrative access to the globalCopyFiles API and prevent untrusted administrators from using it. Review and manually delete sensitive files that may already have been copied into workspaces; the issue is fixed in version 3.6.1.

Published Mar 19, 2026

Updated

SiYuan is a personal knowledge management system. In versions 3.6.0 and below, the globalCopyFiles API eads source files using filepath.Abs() with no workspace boundary check, relying solely on util.IsSensitivePath() whose blocklist omits /proc/, /run/secrets/, and home directory dotfiles. An admin can copy /proc/1/environ or Docker secrets into the workspace and read them via the standard file API. An admin can exfiltrate any file readable by the SiYuan process that falls outside the incomplete blocklist. In containerized deployments this includes all injected secrets and environment variables - a common pattern for passing credentials to containers. The exfiltrated files are then accessible via the standard workspace file API and persist until manually deleted. This issue has been fixed in version 3.6.1.

Affected Software

1 affected component

SiYuan SiYuan<=3.6.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade SiYuan to a version that resolves this vulnerability.
Fixed in 3.6.1

Event History

Mar 19, 2026

CVE Published

via OSV·09:02 PM

Data Sourced

via OSV·09:02 PM

DescriptionSeverityWeakness

Frequently Asked Questions

Who can exploit this issue?

An attacker needs administrative access to the SiYuan globalCopyFiles API. They can then request files readable by the SiYuan process, including files outside the workspace that are not covered by the incomplete sensitive-path blocklist.

Are containerized deployments particularly exposed?

Yes. In containerized deployments, injected secrets and process environment variables may be readable through paths such as /run/secrets/ and /proc/1/environ, which are not blocked by the affected versions' sensitive-path checks.

How can I tell whether sensitive data may already have been exposed?

Files copied through globalCopyFiles become available through the standard workspace file API and remain there until manually deleted. Review workspace contents for copied sensitive files and remove any discovered artifacts.

What should be done if immediate patching is not possible?

Restrict administrative access to the globalCopyFiles API and prevent untrusted administrators from using it. Review and manually delete sensitive files that may already have been copied into workspaces; the issue is fixed in version 3.6.1.

GO-2026-4705: SiYuan: Incomplete sensitive path blocklist in globalCopyFiles allows reading /proc and Docker secrets

Affected Software

Remediation

Event History

Frequently Asked Questions

Who can exploit this issue?

Are containerized deployments particularly exposed?

How can I tell whether sensitive data may already have been exposed?

What should be done if immediate patching is not possible?

Company

Resources

Contact

Frequently Asked Questions

Who can exploit this issue?

Are containerized deployments particularly exposed?

How can I tell whether sensitive data may already have been exposed?

What should be done if immediate patching is not possible?