CVE-2026-78148: a sentinel in the wrong position¶

A graph arriving over the RPC surface refers to its tensors by identifier. In one position, that of an optional source for a tensor, the identifier zero is meaningful and legitimate: it says there is no such source. In another position, that of a top-level node in the graph, zero means nothing at all.

The server does not distinguish the two positions. A graph whose top-level node list contains the sentinel is accepted, the lookup produces nothing, and planning dereferences it anyway.

What the evidence supports¶

• The primitive is a NULL pointer dereference, reached remotely and without authentication.
• The witness is a rebuild and replay against upstream HEAD, producing a segmentation fault.
• A maintainer reproduced it on the public issue and stated the invariant directly: id 0 is only a valid sentinel for optional tensor sources, not a top-level graph node.

What the evidence does not support¶

• No write occurs. Nothing is stored through the null pointer.
• The faulting address is not attacker-chosen. The client selects that a dereference happens, not where.
• Nothing is returned to the client. No memory reaches the attacker.

The impact is availability, and only availability. This is a crash, and describing it as anything more would be a different claim than the one the evidence makes.

Why it is worth a record anyway¶

A sentinel value is only a sentinel in the position that gives it meaning. The defect here is not a missing null check in isolation; it is that one value carries two meanings and the code that accepts it never asks which position it arrived in. That shape recurs, which is why the plate leads with the ambiguity rather than with the fault.

Remedy shape¶

Reject the sentinel where a real node is required, before the graph is planned.

Sources: the canonical CVE ledger and the public CRUCIBLE-2026-055 record.