Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
PyCFunction::newclosure (and the temporary newclosurebound 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.
Recommended action: Upgrade to 0.29.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PyO3 0.24.0 added optimized implementations of Iterator::nth and DoubleEndedIterator::nthback for the BoundListIterator and BoundTupleIterator types. These implementations computed the target index using unchecked usize addition (index + n) before bounds-checking against the sequence length, then read the element via getitemunchecked. In nth methods, a sufficiently large n (combined with a non-zero internal index) could cause the addition to overflow and wrap around, producing a small "target index" that passed the bounds check and enabling reads at the front of the list or tuple of elements previously yielded by the iterator. In nthback methods, a sufficiently large n could cause underflow in a similar fashion, however would instead allow reads of arbitrary memory past the end of the list or tuple storage.
Recommended action: Upgrade to 0.29.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PyO3 0.28.1 added support for #[pyclass(extends=PyList)] struct NativeSub (and other native types) when targeting Python 3.12 and up with the abi3 feature. It was discovered that subclasses of such classes would use the type of the subclass when attempting to access to data of NativeSub contained within Python objects, amounting to memory corruption. PyO3 0.28.2 fixed the issue by using the type of (e.g.) NativeSub correctly.
Recommended action: Upgrade to 0.28.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PyString::fromobject 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.
Recommended action: Upgrade to 0.24.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In PyO3 0.23.0 the PYO3CONFIGFILE environment variable used to configure builds regressed such that changing the environment variable would no longer trigger PyO3 to reconfigure and recompile. In combination with workflows using tools such as maturin to build for multiple versions in a single build, this leads to Python wheels being compiled against the wrong Python API version. All users who distribute artefacts for multiple Python versions are encouraged to update and rebuild with PyO3 0.23.3. Affected wheels produced from PyO3 0.23.0 through 0.23.2 are highly unstable and will crash the Python interpreter in unpredictable ways.
Recommended action: Upgrade to 0.23.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The family of functions to read "borrowed" values from Python weak references were fundamentally unsound, because the weak reference does itself not have ownership of the value. At any point the last strong reference could be cleared and the borrowed value would become dangling. In PyO3 0.22.4 these functions have all been deprecated and patched to leak a strong reference as a mitigation. PyO3 0.23 will remove these functions entirely.
Recommended action: Upgrade to 0.22.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in the pyo3 crate before 0.12.4 for Rust. There is a reference-counting error and use-after-free in From<Py<T.
Recommended action: Upgrade to 0.12.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.