Listen to this Post
The vulnerability resides in the route POST /api/notebook/getEncryptedNotebookStatus, which is exposed without proper publish‑access filtering. The route is registered in `kernel/api/router.go:131` with only `CheckAuth` middleware; crucially, it lacks `CheckReadonly` and `CheckAdminRole` checks. This means that any authenticated `RoleReader` token, and even the anonymous user when `Publish.Auth.Enable` is false, can call this endpoint. The handler in `kernel/api/notebook.go` accepts no request parameters and contains no `IsReadOnlyRoleContext` branch, nor any logic to filter results based on publish visibility. For every encrypted notebook on the system, it returns a JSON object containing the notebook’s internal ID, its user‑provided name, and a boolean `unlocked` that indicates whether the decrypted plaintext is currently resident in memory. Additionally, the response leaks auxiliary fields such as enabled, count, migrationPending, migrationBoxes, and hasHistoryDependency. A striking asymmetry exists with the legitimate listing endpoint lsNotebooks, which is also reader‑reachable but applies a strict filter: it skips notebooks marked `Closed` and those whose `publishAccess` is not Visible. The project clearly intends to scope notebook visibility for public sessions, yet `getEncryptedNotebookStatus` enumerates every encrypted notebook unconditionally, bypassing that safeguard. At the time of writing, the issue remains unfixed in HEAD; the broader encrypted‑notebook hardening series (issue 18034) addresses local‑threat scenarios like auto‑lock and key handling, but commit `f2d966659` (“Expose encrypted notebook unlock status to plugins”) introduced this exposure, and no subsequent commit has retrofitted a publish‑boundary gate. The secondary effect is particularly critical: `unlocked: true` provides a real‑time signal that the notebook’s plaintext is in memory, which is the exact window during which other reader‑reachable code paths (that accept a notebook argument) could be abused to read decrypted content. A proof‑of‑concept is trivial: with publish mode enabled (default port 6808) and anonymous access allowed or using any valid reader token, an attacker sends an empty JSON POST to the endpoint and receives the full list of encrypted notebooks, including those hidden from lsNotebooks. No arguments or privileged permissions are required, making exploitation straightforward. The impact is strictly confidentiality‑based, but it defeats the core privacy expectation of encrypted notebooks, as names often disclose the sensitive subject matter that motivated encryption in the first place.
DailyCVE Form:
Platform: Notebook Service
Version: Unfixed HEAD
Vulnerability: Info Disclosure
Severity: Medium
date: 2026-09-04
Prediction: No patch yet
What Undercode Say:
Analytics:
- Attack surface: anonymous/reader reachable
- Leaked fields: id, name, unlocked, migration status
- Exploit reliability: 100% (no prerequisites)
- Exposure window: since commit f2d966659
- Affected roles: RoleReader, anonymous
Bash commands & codes:
Check if anonymous access is enabled (default port 6808)
curl -s -X POST http://127.0.0.1:6808/api/notebook/getEncryptedNotebookStatus -H "Content-Type: application/json" -d '{}' | jq .
If authentication is required, use a valid RoleReader token
curl -s -X POST http://127.0.0.1:6808/api/notebook/getEncryptedNotebookStatus \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <READER_TOKEN>" \
-d '{}' | jq '.data[] | {id, name, unlocked}'
Automate checking for unlocked notebooks (educational)
curl -s -X POST http://127.0.0.1:6808/api/notebook/getEncryptedNotebookStatus -d '{}' \
| jq -r '.data[] | select(.unlocked==true) | "(.name) is currently decrypted in memory"'
Exploit: (Educational Purposes!)
1. Identify target publish instance (default port 6808).
- If `Publish.Auth.Enable` is false, directly send POST with empty body.
- Otherwise, obtain any valid `RoleReader` token (e.g., guest account).
4. Send `POST /api/notebook/getEncryptedNotebookStatus {}`.
- Parse response to retrieve all encrypted notebook IDs, names, and live lock state.
- Use `unlocked: true` as a timing oracle – during that window, combine with other reader‑reachable endpoints (e.g., those accepting a notebook ID) to extract decrypted contents.
Protection:
- For `IsReadOnlyRoleContext` sessions, reject the request entirely or restrict response to only publish‑visible notebooks, mirroring `lsNotebooks` filtering.
- Encrypted notebooks should never be enumerated to any reader in a publish context; gate the handler with both `CheckAdminRole` and a dedicated publish‑visibility filter.
- As a temporary workaround, disable anonymous access (
Publish.Auth.Enable = true) and avoid granting `RoleReader` permissions to untrusted parties. - Monitor logs for unusual `getEncryptedNotebookStatus` calls from non‑admin IPs.
Impact:
An unauthenticated or low‑privileged reader can enumerate all encrypted notebooks, obtaining their names (which are often sensitive and disclose the encrypted content’s subject) and a live indicator of whether the notebook’s plaintext is currently loaded in memory. This defeats the confidentiality guarantee of encrypted notebooks, and the `unlocked` signal creates a window for further data extraction via other reader‑accessible APIs that operate on notebook content. Confidentiality is the sole affected property, but the breach can be severe depending on the sensitivity of notebook names and the availability of complementary read endpoints.
🎯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
