Resolved from the running container (podman exec open-notebook-surrealdb /surreal version); the image is ghcr.io/surrealdb/surrealdb:v2@sha256:e5d7387… — digest-pinned, so it will not move on its own.
Highs: CVE-2026-63735/GHSA-848m-r628-vrxw
(fix 3.2.0), GHSA-4vgr-h27g-cf9p, GHSA-5qfp-32cf-69jh, CVE-2026-63760/GHSA-q729-696q-g9pq,
GHSA-wjjj-24cx-f28g (all fix 3.1.0), GHSA-cc8f-fcx3-gpjr (fix 3.1.5). The advisory texts describe server
behaviour (LIVE queries, HTTP /rpc, permissions, JWKS SSRF); the server is reachable only from the open-notebook pod network.
Action: decide the open-notebook upgrade path to a 3.x server (data-directory migration is the real
work, not the tag), or record the accepted risk next to the pin so the digest stops reading as "current".
**Severity:** 6 HIGH + 19 MODERATE (OSV `crates.io` / `surrealdb` @ 2.7.0 → 25 matches, all ranges
`introduced: 0 → fixed: 3.x`).
Resolved from the running container (`podman exec open-notebook-surrealdb /surreal version`); the image is
`ghcr.io/surrealdb/surrealdb:v2@sha256:e5d7387…` — digest-pinned, so it will not move on its own.
Highs: [CVE-2026-63735/GHSA-848m-r628-vrxw](https://github.com/surrealdb/surrealdb/security/advisories/GHSA-848m-r628-vrxw)
(fix 3.2.0), GHSA-4vgr-h27g-cf9p, GHSA-5qfp-32cf-69jh, [CVE-2026-63760/GHSA-q729-696q-g9pq](https://github.com/surrealdb/surrealdb/security/advisories/GHSA-q729-696q-g9pq),
GHSA-wjjj-24cx-f28g (all fix 3.1.0), GHSA-cc8f-fcx3-gpjr (fix 3.1.5). The advisory texts describe server
behaviour (LIVE queries, HTTP `/rpc`, permissions, JWKS SSRF); the server is reachable only from the
`open-notebook` pod network.
**Action:** decide the open-notebook upgrade path to a 3.x server (data-directory migration is the real
work, not the tag), or record the accepted risk next to the pin so the digest stops reading as "current".
Source: [vuln-dankclaw.md](https://gitea.franksdank.cloud/dank/command-center/src/branch/main/omp-docs/reports/vuln-dankclaw.md) · audit [fleet-security-audit-2026-10-21.html](https://gitea.franksdank.cloud/dank/command-center/src/branch/main/omp-docs/reports/fleet-security-audit-2026-10-21.html)
---
cwd: /home/blank/.omp/wt/wt-20261019-125509-7c8a99d · session: 01a155bb-6474-7366-be9d-629f74af0e05
Server: surrealdb/surrealdb:v2@sha256:e5d7387e… = 2.7.0, pinned in dankclaw/open-notebook/quadlet/open-notebook-surrealdb.container:75, Pull=never.
Store: named volume open-notebook-db → /mydata, Exec=start --log info rocksdb:/mydata/mydatabase.db.
Exposure: no PublishPort; the app reaches it by name on the private systemd-open-notebook bridge only. The image
is distroless (no shell), so any export/import has to run from a throwaway container.
All 25 advisories resolve only at 3.x. Current upstream server: v3.3.4 = latest/v3.3 (2026-10-13),
amd64 sha256:0d25256bbbe2….
The gate. Upstream lfnovo/open-notebook (main, read 2026-10-21) still ships image: surrealdb/surrealdb:v2 in docker-compose.yml and depends on surrealdb>=1.0.4 (PyPI: stable 2.0.0, 3.0.0b9 in beta — the SDK line that
matches a 3.x server is still pre-release for the 3.0 track). Running a 3.x server under this app is an unsupported
combination: the query dialect and the SDK API both move.
Migration shape, ready for the day upstream pins v3 (2.7.0 ≥ 2.6.0, so the 2.x server can already emit a
3.x-compatible export — official 2.x to 3.x guide plus surreal migration diagnostics):
podman pull the v3 digest; keep the running 2.x server up, app stopped.
Export from a throwaway container on the private bridge (surreal export --users --permissions ws://open-notebook-surrealdb:8000 …) into a host directory; run the diagnostics it offers and fix the named schema items.
Import into a new volume (open-notebook-db-v3), flip the Volume= line and the image digest in the unit, restart, verify /health + note counts through the app.
Rollback = revert the two lines: the 2.x volume is untouched. (Upstream's own upgrade page is explicit that
reverting past a recorded migration needs an export anyway — which is why the import goes to a fresh volume.)
Interim control, already in place: the RPC has no published port and the root credentials arrive by env file, so
the reachable set is one container on one bridge. Record the accepted risk on serverAppConfigs-docs/Dankclaw/Open Notebook.md when the pin is next touched — one line, not a new page.
Worked to the gate. The 25 advisories are real, but the upgrade is **blocked upstream**, not by a flag.
**Deployed shape (re-read 2026-10-21, `ssh dankclaw` + repo)**
- Server: `surrealdb/surrealdb:v2@sha256:e5d7387e…` = 2.7.0, pinned in
`dankclaw/open-notebook/quadlet/open-notebook-surrealdb.container:75`, `Pull=never`.
- Store: named volume `open-notebook-db` → `/mydata`, `Exec=start --log info rocksdb:/mydata/mydatabase.db`.
- Exposure: no `PublishPort`; the app reaches it by name on the private `systemd-open-notebook` bridge only. The image
is distroless (no shell), so any export/import has to run from a throwaway container.
- All 25 advisories resolve only at 3.x. Current upstream server: **v3.3.4** = `latest`/`v3.3` (2026-10-13),
amd64 `sha256:0d25256bbbe2…`.
**The gate.** Upstream `lfnovo/open-notebook` (main, read 2026-10-21) still ships `image: surrealdb/surrealdb:v2` in
`docker-compose.yml` and depends on `surrealdb>=1.0.4` (PyPI: stable 2.0.0, 3.0.0b9 in beta — the SDK line that
matches a 3.x server is still pre-release for the 3.0 track). Running a 3.x server under this app is an unsupported
combination: the query dialect and the SDK API both move.
**Migration shape, ready for the day upstream pins v3** (2.7.0 ≥ 2.6.0, so the 2.x server can already emit a
3.x-compatible export — official *2.x to 3.x* guide plus `surreal` migration diagnostics):
1. `podman pull` the v3 digest; keep the running 2.x server up, app stopped.
2. Export from a throwaway container on the private bridge (`surreal export --users --permissions ws://open-notebook-surrealdb:8000 …`) into a host directory; run the diagnostics it offers and fix the named schema items.
3. Import into a **new** volume (`open-notebook-db-v3`), flip the `Volume=` line and the image digest in the unit, restart, verify `/health` + note counts through the app.
4. Rollback = revert the two lines: the 2.x volume is untouched. (Upstream's own upgrade page is explicit that
reverting past a recorded migration needs an export anyway — which is why the import goes to a fresh volume.)
**Interim control, already in place:** the RPC has no published port and the root credentials arrive by env file, so
the reachable set is one container on one bridge. Record the accepted risk on
`serverAppConfigs-docs/Dankclaw/Open Notebook.md` when the pin is next touched — one line, not a new page.
**Watch command:**
`curl -s https://raw.githubusercontent.com/lfnovo/open-notebook/main/docker-compose.yml | grep -n 'image: surrealdb'`
---
cwd: /home/blank/.omp/wt/wt-20261019-125509-7c8a99d · session: 01a155bb-6474-7366-be9d-629f74af0e05
dank
self-assigned this 2026-10-21 15:59:09 -07:00
Taking ownership (agent). Needs a product decision (open-notebook data migration to 3.x vs recorded accepted risk at the v2 pin). Preparing the two concrete options; the pin will carry the decision either way.
**Taking ownership (agent).** Needs a product decision (open-notebook data migration to 3.x vs recorded accepted risk at the v2 pin). Preparing the two concrete options; the pin will carry the decision either way.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Severity: 6 HIGH + 19 MODERATE (OSV
crates.io/surrealdb@ 2.7.0 → 25 matches, all rangesintroduced: 0 → fixed: 3.x).Resolved from the running container (
podman exec open-notebook-surrealdb /surreal version); the image isghcr.io/surrealdb/surrealdb:v2@sha256:e5d7387…— digest-pinned, so it will not move on its own.Highs: CVE-2026-63735/GHSA-848m-r628-vrxw
(fix 3.2.0), GHSA-4vgr-h27g-cf9p, GHSA-5qfp-32cf-69jh, CVE-2026-63760/GHSA-q729-696q-g9pq,
GHSA-wjjj-24cx-f28g (all fix 3.1.0), GHSA-cc8f-fcx3-gpjr (fix 3.1.5). The advisory texts describe server
behaviour (LIVE queries, HTTP
/rpc, permissions, JWKS SSRF); the server is reachable only from theopen-notebookpod network.Action: decide the open-notebook upgrade path to a 3.x server (data-directory migration is the real
work, not the tag), or record the accepted risk next to the pin so the digest stops reading as "current".
Source: vuln-dankclaw.md · audit fleet-security-audit-2026-10-21.html
cwd: /home/blank/.omp/wt/wt-20261019-125509-7c8a99d · session: 01a155bb-6474-7366-be9d-629f74af0e05
Worked to the gate. The 25 advisories are real, but the upgrade is blocked upstream, not by a flag.
Deployed shape (re-read 2026-10-21,
ssh dankclaw+ repo)surrealdb/surrealdb:v2@sha256:e5d7387e…= 2.7.0, pinned indankclaw/open-notebook/quadlet/open-notebook-surrealdb.container:75,Pull=never.open-notebook-db→/mydata,Exec=start --log info rocksdb:/mydata/mydatabase.db.PublishPort; the app reaches it by name on the privatesystemd-open-notebookbridge only. The imageis distroless (no shell), so any export/import has to run from a throwaway container.
latest/v3.3(2026-10-13),amd64
sha256:0d25256bbbe2….The gate. Upstream
lfnovo/open-notebook(main, read 2026-10-21) still shipsimage: surrealdb/surrealdb:v2indocker-compose.ymland depends onsurrealdb>=1.0.4(PyPI: stable 2.0.0, 3.0.0b9 in beta — the SDK line thatmatches a 3.x server is still pre-release for the 3.0 track). Running a 3.x server under this app is an unsupported
combination: the query dialect and the SDK API both move.
Migration shape, ready for the day upstream pins v3 (2.7.0 ≥ 2.6.0, so the 2.x server can already emit a
3.x-compatible export — official 2.x to 3.x guide plus
surrealmigration diagnostics):podman pullthe v3 digest; keep the running 2.x server up, app stopped.surreal export --users --permissions ws://open-notebook-surrealdb:8000 …) into a host directory; run the diagnostics it offers and fix the named schema items.open-notebook-db-v3), flip theVolume=line and the image digest in the unit, restart, verify/health+ note counts through the app.reverting past a recorded migration needs an export anyway — which is why the import goes to a fresh volume.)
Interim control, already in place: the RPC has no published port and the root credentials arrive by env file, so
the reachable set is one container on one bridge. Record the accepted risk on
serverAppConfigs-docs/Dankclaw/Open Notebook.mdwhen the pin is next touched — one line, not a new page.Watch command:
curl -s https://raw.githubusercontent.com/lfnovo/open-notebook/main/docker-compose.yml | grep -n 'image: surrealdb'cwd: /home/blank/.omp/wt/wt-20261019-125509-7c8a99d · session: 01a155bb-6474-7366-be9d-629f74af0e05
Taking ownership (agent). Needs a product decision (open-notebook data migration to 3.x vs recorded accepted risk at the v2 pin). Preparing the two concrete options; the pin will carry the decision either way.