CVE-2026-72798

CVE: This vulnerability corresponds to CVE-2026-72798.

renderAttributeView correctly applies the reader publish-access filter, but the filter's row-accessibility decision is keyed solely to the row's first cell, and it never inspects the remaining cells' values. Relation and Rollup cells carry mirrored content from a different database, so a row belonging to a published database can hand an anonymous reader the contents of a related database whose host document is hidden, publish-forbidden, or password-protected. Separately, when the first column is not a block value the accessibility check is skipped entirely and the row is returned unchecked.

Note:

This is distinct from the previously reported password-tier omission in the same function that concerns the row's own primary block, whereas these two defects concern (a) other cells' related-database content, which no row-level check covers and (b) rows where the first cell is not a block at all. A fix to the row-drop condition alone would close neither.

Details

renderAttributeView applies the filter (kernel/api/av.go:68):

retDataMap["view"] = model.FilterViewByPublishAccess(c, publishAccess, retDataMap["view"].(av.Viewable))

Inside FilterViewByPublishAccess (kernel/model/publish_access.go):

if row.Cells[0].Value.Block != nil {
    bt = treenode.GetBlockTree(row.Cells[0].Value.Block.ID)
}
if bt != nil {
    if !CheckPathAccessableByPublishIgnore(bt.BoxID, bt.Path, publishIgnore) {
        row = nil   // drop
    }
}
// every other cell in the row is returned as-is

(a) Relation and Rollup cells leak the related database. These value types carry mirrored content, not just references:

type ValueRelation struct { BlockIDs []string; Contents []*Value }
type ValueRollup   struct { Contents []*Value }

The render pipeline populates them from a different attribute view e.g. kernel/model/attribute_view.go:2731:

v.GroupVal.Relation.Contents = []*av.Value{ relationDestAv.GetBlockValue(groupValue) }

relationDestAv is a separate database that may live in a hidden, publish-forbidden, or password-protected document. When a published database's row survives the filter (because its column-0 document is public), its Relation and Rollup columns return the related, non-published database's content block text, titles, and mirrored column values. FilterViewByPublishAccess performs no publish-access evaluation on Relation.Contents or Rollup.Contents.

(b) Fail-open when column 0 is not a block. bt is assigned only when row.Cells[0].Value.Block != nil. If the first column is a non-block type (Relation, Text, …) or the row is detached, bt remains nil, the if bt != nil guard is skipped, and the row is returned with no accessibility check at all. Column order is user-reorderable, so any database whose first column is not the document block bypasses row filtering entirely.

Verified at origin/master (eef105683).

Proof of Concept

Precondition: publish mode enabled (default port 6808); anonymous when Publish.Auth.Enable is false. Two databases: DB-A hosted in a published document, DB-B hosted in a publish-forbidden or password-protected document, with a Relation column in DB-A pointing at DB-B and containing a distinctive marker value.

(a) Related-database content disclosure:

POST http://127.0.0.1:6808/api/av/renderAttributeView
{"id":"<DB_A_AV_ID>"}

Rows of DB-A are returned (correctly, since its host document is public), and their Relation/Rollup cell Contents include DB-B's block text and mirrored column values, despite DB-B's host document being excluded from publishing.

(b) Fail-open row:
Reorder DB-A so its first column is a non-block type (or use a detached row), mark its host document publish-forbidden, and request the same endpoint the row is returned without any accessibility evaluation.

Verification status: both defects are confirmed by code inspection at origin/master. A live demonstration requires a build from HEAD with two linked databases; available on request.