CVE-2026-72800

GHSA-5fhr-f75j-8wr9 MEDIUM
Published September 3, 2026

**CVE:** This vulnerability corresponds to [CVE-2026-72800](https://nvd.nist.gov/vuln/detail/CVE-2026-72800). ### Summary `POST /api/av/getAttributeViewKeysByID` returns a database's full column schema with no publish-access filtering, while its sibling `getAttributeViewKeys` applies the filter...

Full CISO analysis pending enrichment.

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Jupyter Notebook go < 0.0.0-20260724103335-f36331956ae9 0.0.0-20260724103335-f36331956ae9
13.3K OpenSSF 5.7 3.0K dependents Pushed 10d ago 79% patched ~133d to patch Full package profile →

Do you use Jupyter Notebook? You're affected.

How severe is it?

CVSS 3.1
5.8 / 10
EPSS
0.2%
chance of exploitation in 30 days
Higher than 15% of all CVEs
Exploitation Status
No known exploitation
Sophistication
N/A

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR None
UI None
S Changed
C Low
I None
A None

What should I do?

Patch available

Update Jupyter Notebook to version 0.0.0-20260724103335-f36331956ae9

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is CVE-2026-72800?

**CVE:** This vulnerability corresponds to [CVE-2026-72800](https://nvd.nist.gov/vuln/detail/CVE-2026-72800). ### Summary `POST /api/av/getAttributeViewKeysByID` returns a database's full column schema with no publish-access filtering, while its sibling `getAttributeViewKeys` applies the filter for reader sessions. Two further endpoints, `getBlockDefIDsByRefText` and `getBlockRelevantIDs` return workspace-wide block IDs with no publish scoping. All three are `CheckAuth`-only, so they are reachable by the publish `RoleReader` token and by the anonymous account when `Publish.Auth.Enable` is `false`. ### Details **(a) `getAttributeViewKeysByID`: ungated column-schema disclosure** The entire handler (`kernel/api/av.go`, router line 548): ```go ret.Data = model.GetAttributeViewKeysByID(avID, keyIDs...) // no publish gate ``` With an empty `keyIDs`, `GetAttributeViewKeysByID` calls `av.ParseAttributeView(avID)` and returns every column's `*av.Key`: | Field | Discloses | |---|---| | `Name`, `Desc` | column title and user-authored description | | `Options` | the full single/multi-select vocabulary and colours (e.g. status labels such as "Fired", "Confidential") | | `Template` | the column's Sprig template expression — logic and field references | | `Relation` | the target `avID`, allowing pivot to another database | | `Rollup`, `NumberFormat`, date config | further schema | **Guarded-sibling asymmetry, same file:** `getAttributeViewKeys` (router line 526) runs `FilterBlockAttributeViewKeysByPublishAccess(...)` when `IsReadOnlyRoleContext`. `getAttributeViewKeysByID` applies nothing. A reader who knows an `avID` — trivially harvested from the `data-av-id` attribute of any published document embedding a database obtains the schema of any database in the workspace, including those whose host documents are hidden, password-protected, or publish-forbidden. `Relation` targets allow walking to sibling databases. **(b) Two unscoped block-ID enumeration oracles** Both `CheckAuth`-only with no publish gate. Neither returns content of its own, but both yield valid block IDs that other endpoints turn into content: - `getBlockDefIDsByRefText` (router line 237) → `GetBlockDefIDsByRefText(anchor)` returns the block IDs, workspace-wide and including private documents, whose reference/anchor text equals a caller-supplied string: a ref-text → ID oracle. - `getBlockRelevantIDs` (router line 274) → `GetBlockRelevantIDsInBox(id, <notebook from request>)` returns parent/previous/next block IDs and traverses decrypted encrypted-notebook structure while the notebook is unlocked, a tree-walk oracle. Verified at `origin/master` (`eef105683`): all three handler bodies contain no publish-access, publish-ignore, or readonly-role check; all three routes are registered `CheckAuth` without `CheckAdminRole`. ### Proof of Concept Precondition: publish mode enabled (default port 6808); anonymous when `Publish.Auth.Enable` is `false`, otherwise any publish reader account. A database exists whose host document is publish-forbidden or password-protected. **(a) Column schema of any database:** ``` POST http://127.0.0.1:6808/api/av/getAttributeViewKeysByID {"avID":"<AV_ID>"} ``` Returns every column's key object names, descriptions, select vocabularies, template expressions, and `Relation` target `avID`s for a database whose host document the reader may not access. **Control:** the sibling `getAttributeViewKeys` with the same `avID` returns filtered results for the same reader session, confirming the boundary is enforced there and omitted here. **(b) ID oracles:** ``` POST http://127.0.0.1:6808/api/block/getBlockDefIDsByRefText {"anchor":"<known ref text>"} → block IDs workspace-wide, including blocks in private documents POST http://127.0.0.1:6808/api/block/getBlockRelevantIDs {"id":"<BLOCK_ID>","notebook":"<BOX_ID>"} → parent/previous/next block IDs; traverses encrypted-notebook structure when unlocked ``` ### Impact An anonymous reader (publish mode with auth disabled) or any publish `RoleReader` can read the complete column schema of any database in the workspace, including column descriptions, select-option vocabularies (which frequently encode sensitive category labels), template logic, and relation targets that permit pivoting to further databases regardless of whether the host document is hidden, password-protected, or excluded from publishing. The two enumeration endpoints additionally supply valid block IDs across the publish boundary, including from encrypted notebooks while unlocked. This removes the "attacker must already know a valid ID" precondition from other block-read endpoints, converting ID knowledge into content disclosure. Confidentiality-only. ### Note getAttributeViewKeysByID is a distinct handler from getAttributeView; although column definitions also appear within the latter's response payload, a fix applied to one handler does not remediate the other, and getAttributeViewKeysByID has its own filtered sibling (getAttributeViewKeys) demonstrating the intended treatment. ### Suggested fix - Gate `getAttributeViewKeysByID` with `FilterBlockAttributeViewKeysByPublishAccess`, mirroring `getAttributeViewKeys`. - Scope `getBlockDefIDsByRefText` and `getBlockRelevantIDs` to publish-accessible blocks for reader sessions, and ensure the `*InBox` traversal path applies the same check before walking encrypted-notebook structure.

Is CVE-2026-72800 actively exploited?

No confirmed active exploitation of CVE-2026-72800 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-72800?

Update to patched version: Jupyter Notebook 0.0.0-20260724103335-f36331956ae9.

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

CVE-2026-72800 has a CVSS v3.1 base score of 5.8 (MEDIUM). The EPSS exploitation probability is 0.24%.

What are the technical details?

Original Advisory

**CVE:** This vulnerability corresponds to [CVE-2026-72800](https://nvd.nist.gov/vuln/detail/CVE-2026-72800). ### Summary `POST /api/av/getAttributeViewKeysByID` returns a database's full column schema with no publish-access filtering, while its sibling `getAttributeViewKeys` applies the filter for reader sessions. Two further endpoints, `getBlockDefIDsByRefText` and `getBlockRelevantIDs` return workspace-wide block IDs with no publish scoping. All three are `CheckAuth`-only, so they are reachable by the publish `RoleReader` token and by the anonymous account when `Publish.Auth.Enable` is `false`. ### Details **(a) `getAttributeViewKeysByID`: ungated column-schema disclosure** The entire handler (`kernel/api/av.go`, router line 548): ```go ret.Data = model.GetAttributeViewKeysByID(avID, keyIDs...) // no publish gate ``` With an empty `keyIDs`, `GetAttributeViewKeysByID` calls `av.ParseAttributeView(avID)` and returns every column's `*av.Key`: | Field | Discloses | |---|---| | `Name`, `Desc` | column title and user-authored description | | `Options` | the full single/multi-select vocabulary and colours (e.g. status labels such as "Fired", "Confidential") | | `Template` | the column's Sprig template expression — logic and field references | | `Relation` | the target `avID`, allowing pivot to another database | | `Rollup`, `NumberFormat`, date config | further schema | **Guarded-sibling asymmetry, same file:** `getAttributeViewKeys` (router line 526) runs `FilterBlockAttributeViewKeysByPublishAccess(...)` when `IsReadOnlyRoleContext`. `getAttributeViewKeysByID` applies nothing. A reader who knows an `avID` — trivially harvested from the `data-av-id` attribute of any published document embedding a database obtains the schema of any database in the workspace, including those whose host documents are hidden, password-protected, or publish-forbidden. `Relation` targets allow walking to sibling databases. **(b) Two unscoped block-ID enumeration oracles** Both `CheckAuth`-only with no publish gate. Neither returns content of its own, but both yield valid block IDs that other endpoints turn into content: - `getBlockDefIDsByRefText` (router line 237) → `GetBlockDefIDsByRefText(anchor)` returns the block IDs, workspace-wide and including private documents, whose reference/anchor text equals a caller-supplied string: a ref-text → ID oracle. - `getBlockRelevantIDs` (router line 274) → `GetBlockRelevantIDsInBox(id, <notebook from request>)` returns parent/previous/next block IDs and traverses decrypted encrypted-notebook structure while the notebook is unlocked, a tree-walk oracle. Verified at `origin/master` (`eef105683`): all three handler bodies contain no publish-access, publish-ignore, or readonly-role check; all three routes are registered `CheckAuth` without `CheckAdminRole`. ### Proof of Concept Precondition: publish mode enabled (default port 6808); anonymous when `Publish.Auth.Enable` is `false`, otherwise any publish reader account. A database exists whose host document is publish-forbidden or password-protected. **(a) Column schema of any database:** ``` POST http://127.0.0.1:6808/api/av/getAttributeViewKeysByID {"avID":"<AV_ID>"} ``` Returns every column's key object names, descriptions, select vocabularies, template expressions, and `Relation` target `avID`s for a database whose host document the reader may not access. **Control:** the sibling `getAttributeViewKeys` with the same `avID` returns filtered results for the same reader session, confirming the boundary is enforced there and omitted here. **(b) ID oracles:** ``` POST http://127.0.0.1:6808/api/block/getBlockDefIDsByRefText {"anchor":"<known ref text>"} → block IDs workspace-wide, including blocks in private documents POST http://127.0.0.1:6808/api/block/getBlockRelevantIDs {"id":"<BLOCK_ID>","notebook":"<BOX_ID>"} → parent/previous/next block IDs; traverses encrypted-notebook structure when unlocked ``` ### Impact An anonymous reader (publish mode with auth disabled) or any publish `RoleReader` can read the complete column schema of any database in the workspace, including column descriptions, select-option vocabularies (which frequently encode sensitive category labels), template logic, and relation targets that permit pivoting to further databases regardless of whether the host document is hidden, password-protected, or excluded from publishing. The two enumeration endpoints additionally supply valid block IDs across the publish boundary, including from encrypted notebooks while unlocked. This removes the "attacker must already know a valid ID" precondition from other block-read endpoints, converting ID knowledge into content disclosure. Confidentiality-only. ### Note getAttributeViewKeysByID is a distinct handler from getAttributeView; although column definitions also appear within the latter's response payload, a fix applied to one handler does not remediate the other, and getAttributeViewKeysByID has its own filtered sibling (getAttributeViewKeys) demonstrating the intended treatment. ### Suggested fix - Gate `getAttributeViewKeysByID` with `FilterBlockAttributeViewKeysByPublishAccess`, mirroring `getAttributeViewKeys`. - Scope `getBlockDefIDsByRefText` and `getBlockRelevantIDs` to publish-accessible blocks for reader sessions, and ensure the `*InBox` traversal path applies the same check before walking encrypted-notebook structure.

Weaknesses (CWE)

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.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N

Timeline

Published
September 3, 2026
Last Modified
September 3, 2026
First Seen
September 4, 2026

Related Vulnerabilities