This project contains known security vulnerabilities. Find detailed information at the bottom.

Crate polars-plan

Dependencies

(17 total, 10 outdated, 2 insecure)

CrateRequiredLatestStatus
 ahash^0.80.8.12up to date
 arrow2 ⚠️^0.170.18.0insecure
 chrono^0.40.4.45up to date
 chrono-tz^0.80.10.4out of date
 futures^0.3.250.3.34up to date
 once_cell^11.21.4up to date
 polars-arrow^0.29.00.55.2out of date
 polars-core^0.29.00.55.2out of date
 polars-io^0.29.00.55.2out of date
 polars-ops^0.29.00.55.2out of date
 polars-time^0.29.00.55.2out of date
 polars-utils^0.29.00.55.2out of date
 pyo3 ⚠️^0.180.30.1insecure
 rayon^1.61.12.0up to date
 regex^1.61.13.1up to date
 serde^11.0.229up to date
 smartstring^12.0.0out of date

Security Vulnerabilities

pyo3: Risk of buffer overflow in `PyString::from_object`

RUSTSEC-2025-0020

PyString::from_object took &str arguments and forwarded them directly to the Python C API without checking for terminating nul bytes. This could lead the Python interpreter to read beyond the end of the &str data and potentially leak contents of the out-of-bounds read (by raising a Python exception containing a copy of the data including the overflow).

In PyO3 0.24.1 this function will now allocate a CString to guarantee a terminating nul bytes. PyO3 0.25 will likely offer an alternative API which takes &CStr arguments.

arrow2: Out of bounds access in public safe API

RUSTSEC-2025-0038

Rows::row_unchecked() allows out of bounds access to the underlying buffer without sufficient checks.

The arrow2 crate is no longer maintained, so there are no plans to fix this issue. Users are advised to migrate to the arrow crate, instead.

pyo3: Missing `Sync` bound on `PyCFunction::new_closure` closures

RUSTSEC-2026-0177

PyCFunction::new_closure (and the temporary new_closure_bound complement in the 0.21–0.22 series) required the supplied closure to be Send + 'static but not Sync. The resulting PyCFunction is a Python callable that can be invoked from any Python thread, which means the closure may be called concurrently from multiple threads, and needs a Sync bound to prevent possible data races.

The problem exists under all Python versions but is particularly vulnerable under the newer free-threaded Python variant, which do not have serial execution imposed by the Global Interpreter Lock. Under releases protected by the GIL, the ability to "detach" from the Python interpreter temporarily inside the closure (e.g. by Python::detach) makes it possible for interleaved and/or concurrent execution of various portions of the closure.

PyO3 0.29.0 added a Sync bound to close this thread-safety bug.