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

Open
  • Is something wrong?
#4 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
backend, security

Research direction

Read docs/dependencies.md rule 4 and check Ballista’s latest DataFusion requirement; the issue says the required release is not available yet. Once Ballista targets DataFusion 55, update the dependency chain and inspect Cargo.lock for any remaining thrift entry. Remove the GHSA ignore from deny.toml and the known advisory from SECURITY.md, then run make coherence.

Written by the indexing model from the issue text.

Description

help wanted

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.

Dominant language
Rust
Stars
1
Forks
2
Avg merge
1d 11h
Merged PRs (30d)
7

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from vyncint/oxidelake

All issues in vyncint/oxidelake

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.