thrift CVE-2026-43868 via parquet 58 — fix is parquet 59, blocked on Ballista > 54

[vyncint]

Today — Cargo.lock resolves thrift 0.17.0, reached only through parquet 58.4.0 → thrift ^0.17 (→ datafusion 54 → ballista 54). GitHub's advisory database reports it as CVE-2026-43868 / GHSA-2f9f-gq7v-9h6m, medium: excessive memory allocation from a size value during decode. cargo deny check passes because RustSec does not carry the advisory yet; the acceptance is already recorded in deny.toml so the gate stays green with the reason on file when it does.

$ cargo tree -i thrift -e normal
thrift v0.17.0
└── parquet v58.4.0
    └── datafusion v54.1.0
        └── ballista v54.1.0
$ parquet 58.4.0 requires thrift ^0.17

Why it is worth tracking — Thrift is how a Parquet footer is decoded, so the vulnerable path is entered by opening a Parquet file. For an engine whose entire storage layer is Parquet, that is the front door. SECURITY.md scopes input files to infrastructure you control, which bounds it today; it does not close it.

Fix — not a thrift bump. Measured on crates.io:

parquet 59.0.0 … 59.3.0   thrift: (none)      # upstream removed the dependency
ballista 54.1.0 (newest)  datafusion ^54      # parquet 59 needs datafusion 55

So the fix is the chain bump ballista → datafusion 55 → parquet 59, and it is blocked until a Ballista release targets DataFusion 55 (docs/dependencies.md, rule 4: "Ballista wins until it moves"). Nothing OxideLake can do inside the pinned set short-circuits it.

Done when —

• Cargo.lock has no thrift entry (parquet ≥ 59 in the chain).
• The GHSA-2f9f-gq7v-9h6m ignore is removed from deny.toml and the entry from SECURITY.md's known-advisories list.
• make coherence still reports one major per chain crate after the bump.

Unmilestoned on purpose: the trigger is upstream. Re-check Ballista's newest datafusion requirement at every chain review.