CVE-2026-85578: siyuan auth bypass leaks hidden

CISO Take

SiYuan's /api/file/getFile endpoint fails to re-validate the per-notebook Visible:false flag server-side, so any authenticated reader-role account can retrieve files from notebooks explicitly hidden from them simply by knowing the notebook ID and file path. There is no public exploit code, no Nuclei template, and it does not appear in CISA KEV or carry an EPSS score, so this reads as a targeted insider or low-trust-tenant risk rather than a mass-scan threat. The impact is confidentiality-only (CVSS 3.1 C:H/I:N/A:N), but in a knowledge-management tool that scope still includes notebook metadata and internal configuration that organizations assumed were access-controlled from lower-privilege users. Until a confirmed patched release is available, restrict reader-role accounts to fully trusted users or isolate sensitive notebooks in a separate SiYuan instance, and audit access logs for /api/file/getFile calls referencing notebook IDs outside a user's normal working set. No downstream package dependents or Scorecard data were available to further scope exposure.

Sources:NVDGitHub AdvisoryATLAS

What is the risk?

Medium risk in practice despite the CVSS 6.5 base score being purely confidentiality-driven. Exploitation requires an existing authenticated reader-role account (PR:L) but no user interaction and low attack complexity, so any malicious or compromised low-privilege user can pivot to data they were explicitly denied. The absence of a public PoC, Nuclei template, KEV listing, or EPSS score suggests low current exploitation likelihood, but the flaw is trivial to exploit once discovered (direct API call with a known/guessed identifier) and requires no special AI/ML expertise. Risk is concentrated in multi-user SiYuan deployments where notebook-level visibility controls are relied upon as a genuine security boundary rather than a UI convenience.

How does the attack unfold?

Initial Access

Attacker obtains or already holds a legitimate reader-role account on a shared SiYuan instance.

AML.T0012

Exploitation

Attacker calls /api/file/getFile directly with a known or guessed hidden notebook ID and file path, bypassing the UI-enforced Visible:false restriction due to missing server-side authorization (CWE-862).

AML.T0049

Data Collection

Attacker retrieves notebook metadata, internal configuration, and file contents from notebooks they were explicitly denied visibility into.

AML.T0036

Impact

Confidential workspace content is exposed, risking leakage of credentials, internal documentation, or knowledge-base data feeding downstream AI/retrieval workflows.

Initial Access

Attacker obtains or already holds a legitimate reader-role account on a shared SiYuan instance.

AML.T0012

Exploitation

Attacker calls /api/file/getFile directly with a known or guessed hidden notebook ID and file path, bypassing the UI-enforced Visible:false restriction due to missing server-side authorization (CWE-862).

AML.T0049

Data Collection

Attacker retrieves notebook metadata, internal configuration, and file contents from notebooks they were explicitly denied visibility into.

AML.T0036

Impact

Confidential workspace content is exposed, risking leakage of credentials, internal documentation, or knowledge-base data feeding downstream AI/retrieval workflows.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
siyuan	—	—	No patch

Do you use siyuan? You're affected.

How severe is it?

CVSS 3.1

6.5 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 32% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVNetwork

ACLow

PRLow

UINone

SUnchanged

CHigh

INone

ANone

What should I do?

1 step

1) Track the vendor advisory (GHSA-8ggq-wq3f-vxrw) for a patched release beyond 3.8.1 and upgrade as soon as one is published — no patched version is currently listed. 2) Until patched, treat every reader-role account as having potential read access to the full workspace: do not rely on Visible:false alone to protect sensitive notebooks, and move genuinely confidential content to a separate instance or workspace with no shared reader accounts. 3) Audit and tighten who holds reader-role accounts; remove any semi-trusted or external accounts. 4) Monitor access logs for /api/file/getFile requests referencing notebook IDs or paths outside a given user's assigned/visible notebooks, which would indicate probing or active exploitation. 5) Rotate any credentials or secrets that may have been stored in plaintext within notebooks, regardless of their visibility setting, going forward.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableNo

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth BypassData LeakageRAGAML.T0025- Exfiltration via Cyber Means AML.T0036- Data from Information Repositories

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.7.2-Data for AI systems

Frequently Asked Questions

What is CVE-2026-85578?

SiYuan's /api/file/getFile endpoint fails to re-validate the per-notebook Visible:false flag server-side, so any authenticated reader-role account can retrieve files from notebooks explicitly hidden from them simply by knowing the notebook ID and file path. There is no public exploit code, no Nuclei template, and it does not appear in CISA KEV or carry an EPSS score, so this reads as a targeted insider or low-trust-tenant risk rather than a mass-scan threat. The impact is confidentiality-only (CVSS 3.1 C:H/I:N/A:N), but in a knowledge-management tool that scope still includes notebook metadata and internal configuration that organizations assumed were access-controlled from lower-privilege users. Until a confirmed patched release is available, restrict reader-role accounts to fully trusted users or isolate sensitive notebooks in a separate SiYuan instance, and audit access logs for /api/file/getFile calls referencing notebook IDs outside a user's normal working set. No downstream package dependents or Scorecard data were available to further scope exposure.

Is CVE-2026-85578 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-85578, increasing the risk of exploitation.

How to fix CVE-2026-85578?

1) Track the vendor advisory (GHSA-8ggq-wq3f-vxrw) for a patched release beyond 3.8.1 and upgrade as soon as one is published — no patched version is currently listed. 2) Until patched, treat every reader-role account as having potential read access to the full workspace: do not rely on Visible:false alone to protect sensitive notebooks, and move genuinely confidential content to a separate instance or workspace with no shared reader accounts. 3) Audit and tighten who holds reader-role accounts; remove any semi-trusted or external accounts. 4) Monitor access logs for /api/file/getFile requests referencing notebook IDs or paths outside a given user's assigned/visible notebooks, which would indicate probing or active exploitation. 5) Rotate any credentials or secrets that may have been stored in plaintext within notebooks, regardless of their visibility setting, going forward.

What systems are affected by CVE-2026-85578?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines.

What is the CVSS score for CVE-2026-85578?

CVE-2026-85578 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.38%.

What is the AI security impact?

Affected AI Architectures

RAG pipelines

MITRE ATLAS Techniques

AML.T0025Exfiltration via Cyber Means

AML.T0036Data from Information Repositories

Compliance Controls Affected

ISO 42001: A.7.2

What are the technical details?

Original Advisory

SiYuan through 3.8.1 contains an authorization bypass vulnerability in the /api/file/getFile endpoint that allows readers to retrieve files from notebooks explicitly configured as Visible:false. Attackers with reader role can access private workspace files including notebook metadata and internal configuration by knowing the hidden notebook identifier and file path.

Exploitation Scenario

An attacker who has (or compromises) a legitimate reader-role account on a shared SiYuan instance notices that the UI hides certain notebooks per workspace policy. Rather than trying to bypass the UI, they call /api/file/getFile directly with a notebook identifier and file path they've enumerated or guessed from prior legitimate access, workspace naming conventions, or leaked references. Because the endpoint does not re-check the Visible:false authorization flag server-side, it returns the file contents regardless of the attacker's intended visibility restriction. The attacker repeats this against other suspected hidden notebook IDs to harvest internal configuration files and confidential notes, potentially surfacing credentials or sensitive project data that were assumed to be segregated from their reader role.

Weaknesses (CWE)

CWE-862Missing AuthorizationPrimary CWE-862Missing Authorization

CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

[Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
[Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.