Anytype, Information Disclosure via Authorization Bypass, CVE-2026-72800 (Medium) -DC-Sep2026-2187

Listen to this Post

CVE-2026-72800 exposes three API endpoints in Anytype’s publish mode that fail to enforce publish‑access filtering, enabling an attacker with a reader‑level token—or even an anonymous user when `Publish.Auth.Enable` is false—to retrieve sensitive workspace metadata without proper authorization. The first endpoint, POST /api/av/getAttributeViewKeysByID, returns the complete column schema of any database given its avID. Unlike its guarded sibling getAttributeViewKeys, which applies `FilterBlockAttributeViewKeysByPublishAccess` for reader sessions, this handler calls `model.GetAttributeViewKeysByID(avID, keyIDs…)` with no additional gates. With an empty `keyIDs` parameter, it dumps every column’s name, description, select‑option vocabulary (including colour‑coded status labels like “Fired” or “Confidential”), Sprig template expressions, and `Relation` targets that can pivot to other databases. An attacker can trivially obtain a target `avID` from the `data‑av‑id` attribute present in any published document that embeds a database, even if that document is hidden, password‑protected, or explicitly excluded from publishing.
The other two endpoints act as block‑ID oracles. `POST /api/block/getBlockDefIDsByRefText` accepts an `anchor` string and returns workspace‑wide block IDs whose reference or anchor text matches that string, including blocks inside private documents. `POST /api/block/getBlockRelevantIDs` takes a `block ID` and a `notebook` (box) ID, returning parent, previous, and next block IDs; when the notebook is unlocked, it traverses the decrypted encrypted‑notebook structure, exposing additional valid IDs. Both endpoints are registered with `CheckAuth` only, lacking any publish‑scoping or admin‑role checks, as verified in origin/master (commit eef105683). The combined effect removes the “attacker must already know a valid ID” precondition from other block‑read endpoints, turning ID knowledge into full content disclosure. The impact is confidentiality‑only, but the data exposed—column schemas, option vocabularies, template logic, and cross‑database relations—can reveal sensitive business logic, category labels, and hidden database structures.

DailyCVE Form:

Platform: Anytype
Version: Pre‑patch
Vulnerability: Authorization Bypass
Severity: Medium
date: 2026‑09‑04

Prediction: Patch due 2026‑10‑01

What Undercode Say:

Retrieve full column schema of any database (requires avID)
curl -X POST http://127.0.0.1:6808/api/av/getAttributeViewKeysByID \
-H "Content-Type: application/json" \
-d '{"avID":"<target_avID>"}'
Enumerate block IDs by reference text (workspace‑wide)
curl -X POST http://127.0.0.1:6808/api/block/getBlockDefIDsByRefText \
-H "Content-Type: application/json" \
-d '{"anchor":"<known_ref_text>"}'
Traverse notebook structure to obtain surrounding block IDs
curl -X POST http://127.0.0.1:6808/api/block/getBlockRelevantIDs \
-H "Content-Type: application/json" \
-d '{"id":"<block_id>","notebook":"<box_id>"}'

Exploit: (Educational Purposes!)

  1. Identify a published document containing a database; extract its `avID` from the `data‑av‑id` attribute in the HTML source.
  2. Send a POST request to `/api/av/getAttributeViewKeysByID` with that avID; the response will contain all column definitions, including hidden vocabularies and relation targets.
  3. Use the `Relation` target `avID`s to pivot to other databases in the same workspace, even if their host documents are inaccessible.
  4. For block enumeration, guess or harvest a reference/anchor string (e.g., a known page ) and call `/api/block/getBlockDefIDsByRefText` to obtain valid block IDs.
  5. With those IDs, invoke other block‑content endpoints (not listed here) to read the actual content, now that you have valid identifiers.

Protection:

  • Apply the same `FilterBlockAttributeViewKeysByPublishAccess` gate to `getAttributeViewKeysByID` that is already used by its sibling getAttributeViewKeys.
  • For `getBlockDefIDsByRefText` and getBlockRelevantIDs, restrict results to only those blocks that are publish‑accessible for the current reader session (i.e., apply publish‑scoping before returning IDs).
  • Ensure the `InBox` traversal path in `getBlockRelevantIDs` checks publish‑access before walking encrypted‑notebook structures.
  • As a workaround, enable `Publish.Auth.Enable` (default is false) to prevent anonymous access, and enforce strict RoleReader permissions.

Impact:

An attacker with minimal privileges (anonymous or RoleReader) can read the complete schema of any database in the workspace, including sensitive column options, template logic, and relation links, allowing full reconnaissance of hidden databases. The block‑ID oracles further enable enumeration of private document blocks, transforming ID‑based protection into a bypass that facilitates content extraction from other read endpoints. The vulnerability compromises confidentiality of metadata and indirectly of block contents, potentially exposing proprietary workflows, category labels, and internal document structures.

🎯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

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow DailyCVE & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin Featured Image

Scroll to Top