Apache Arrow Rust fixes an out-of-bounds read in run-end encoded arrays, with Anthropic credited as finder

The Apache Arrow project has disclosed CVE-2026-111959 in arrow-rs, the Rust implementation of the Arrow columnar format. In its oss-security announcement of 2 November, Apache says: “Improper validation of RunEndEncoded arrays in the ArrayData interface can allow reading data beyond the bounds of the child values array.” Apache rates it moderate. The GitHub advisory, GHSA-gqmm-qrjq-4c7h, is still unreviewed and shows no severity of its own.

Affected and fixed versions

Apache lists these affected ranges:

Release line	Affected	Fixed in
60	60.0.0 before 60.1.0	60.1.0
59	59.0.0 through 59.3.1	59.3.2
58	58.0.0 through 58.4.0	58.4.1
33 to 57	33.0.0 through 57.3.1	57.3.2

The fixed crates are already on crates.io: 57.3.2, 58.4.1 and 59.3.2 on 26 October, and 60.1.0 on 28 October, so the patches shipped about a week before the announcement.

What goes wrong

A run-end encoded (REE) array stores a column as runs: one list of where each run ends and one list of values. Issue #11587, opened on 15 October and closed on 19 October, shows the gap. Validation checked the run ends against the child array’s own length and offset, not the REE array’s logical length and offset, so an array claiming more rows than its runs cover was accepted. Reading those extra rows then indexed past the end of the values. The issue says it was found “with property-based tests that build arrays in every physical layout the Arrow format allows.”

The RustSec entry, added to the advisory database on 3 November against the arrow-data crate, says the out-of-bounds read can happen “when reading the last value via APIs such as TypedRunArray::value”. RustSec files it as informational, “unsound”, in the memory-exposure category. In the commit, the entry still carries the placeholder ID RUSTSEC-0000-0000; it is listed under its CVE and GHSA aliases.

This is an out-of-bounds read, not code execution. Whether a given program is exposed depends on whether a crafted REE array can reach it and be read, so we are not saying any particular downstream project is exploitable.

Who found it

The Apache credit reads, as written: “Adam Korczynski of Ada Logics (reporter)” and “Anthropic (finder)”. The advisory names no tool or method behind Anthropic’s part. It is one more core open-source fix with an AI lab in the credits, after the EPICS Base flaws an AI agent found.

What to do

Check what your lockfile resolves with cargo tree -i arrow-data (and -i arrow if you depend on the umbrella crate), then cargo update -p arrow-data and the other arrow crates to a fixed release on your line: 60.1.0, 59.3.2, 58.4.1 or 57.3.2. Arrow is often pulled in by higher-level crates, so a version requirement upstream may decide which line you can reach. Run cargo audit or cargo deny check advisories afterwards with a fresh advisory database. Because RustSec marks this as informational rather than a vulnerability, how loudly your tool reports it depends on your configuration; our guide to reading a RustSec advisory covers what “unsound” means.

Why this matters

arrow-rs sits under much of the Rust data-for-AI stack: crates.io’s current DataFusion release requires arrow ^59.2.0 and Lance requires arrow ^58.0.0, which is how a bug in REE validation reaches retrieval pipelines like the ones in our LanceDB 0.41.0 coverage. Those requirements allow patched releases, so for most projects this is a cargo update, not a code change. If your service reads Arrow data from sources you do not control, make this update a priority rather than waiting for the next routine bump.