Loading story…
A thread-safety vulnerability in PyO3 exposed Rust applications embedding or extending Python to possible data races through pyo3::types::PyCFunction::new_closure and the temporary companion new_closure_bound. In affected 0.21-0.22 releases, closures supplied to those APIs were required to implement Send + 'static but not Sync, even though the resulting Python-callable object could be invoked from multiple Python threads through a shared reference. That gap allowed unsafe concurrent access to captured non-Sync types such as Cell and RefCell, creating a path to violate Rust’s aliasing and thread-safety guarantees.
The flaw affects all Python versions, but the risk is higher in free-threaded Python environments introduced by PEP 703 because execution is no longer serialized by the Global Interpreter Lock. Even in GIL-protected Python, concurrent or interleaved execution could still occur when code temporarily detaches from the interpreter, including through Python::allow_threads. PyO3 addressed the issue in version 0.29.0 by adding a Sync bound to closures accepted by new_closure and updating tests to use thread-safe primitives such as AtomicI32 instead of RefCell.
See affected versions and whether adversaries are exploiting it.
2 events from the most recent confirmed update back to the earliest known activity.
On 2026-06-11, a RustSec advisory disclosed a thread-safety vulnerability in PyO3 affecting `PyCFunction::new_closure` and the temporary complement `new_closure_bound` in the 0.21–0.22 series. The advisory warned that missing `Sync` bounds could allow concurrent closure execution and data races across Python threads.
PyO3 addressed a thread-safety flaw in `pyo3::types::PyCFunction::new_closure` by requiring closures to implement both `Send` and `Sync`. The fix was released in PyO3 version 0.29.0, and related test code was updated to use thread-safe primitives.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
2 references tracked. Mallory keeps watching after this page renders.
cvereports.com
Open sourcerustsec.org
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
CPython disclosed two medium-severity vulnerabilities affecting distinct parts of the runtime and tooling. **CVE-2026-1502** allows CR/LF bytes to pass through HTTP client proxy tunnel header or host handling, creating a header-injection risk in proxy tunnel scenarios. The issue was published through Python security channels and the `oss-sec` mailing list, with remediation details tracked in the CVE record and an associated CPython pull request. A second flaw, **CVE-2026-5713**, affects CPython remote debugging and introspection features and can trigger out-of-bounds read and write behavior when a privileged Python process connects to a malicious or compromised Python target. The bug impacts newer capabilities including `profiling.sampling` in Python 3.15+ and asyncio inspection commands such as ``` python -m asyncio ps python -m asyncio pstree ``` in Python 3.14+, and exploitation is expected to be unstable because the connecting process is likely to crash under ASLR.
Jun 29, 2026
GitPython has disclosed seven vulnerabilities affecting multiple versions of the widely used Python library, exposing CI/CD and other automation environments to supply-chain risk. The most severe issue, **CVE-2026-73625** (`CVSS 8.8`), allows remote code execution by bypassing `check_unsafe_options` and smuggling unsafe Git options through crafted keyword arguments, enabling arbitrary command execution through parameters such as `--upload-pack`. Affected methods include `clone_from`, `fetch`, `pull`, `push`, `ls_remote`, `iter_commits`, `blame`, and `archive`, according to public advisories and CVE records. The broader disclosure also includes **CVE-2026-73622**, which can leak secrets by expanding environment variables in attacker-controlled URLs and writing them into `.git/config` or `.gitmodules`, as well as **CVE-2026-73620** and **CVE-2026-73624**, which permit arbitrary file read or overwrite through unsafe option forwarding in functions such as `IndexFile.checkout()`, `TagReference.create()`, and `Diffable.diff()`. GitHub advisories further describe related issues involving local file disclosure, git-directory creation outside the destination, unsafe configuration handling, and hook or template abuse. Fixes were released across versions **3.1.54**, **3.1.55**, **3.1.56**, and **3.1.57**, with reports indicating that upgrading to **GitPython 3.1.57** remediates all seven CVEs; no active exploitation was reported at publication time.
Aug 14, 2026
Python disclosed **CVE-2026-15308**, a high-severity denial-of-service flaw in `html.parser.HTMLParser` that can drive CPU exhaustion when applications incrementally parse untrusted HTML containing repeated unterminated markup declarations. The bug stems from quadratic-time behavior in `feed()`, where small repeated chunks force expensive rescanning and buffer concatenation across malformed tags, comments, doctypes, CDATA sections, processing instructions, and RAWTEXT elements. CPython maintainers shipped fixes and backports across supported branches including 3.10 through 3.15, with commits updating buffering logic to accumulate pending input more efficiently, defer reparsing until enough data arrives, adapt parsing thresholds based on parser progress, and flush buffered data on `close()`. The Python Software Foundation also updated the CVE record to clarify that affected versions are **earlier than 3.15.0**, not earlier than 3.16.0, while published metadata classifies the issue as **CWE-400** and notes no known exploitation at the time of disclosure.
Jul 10, 2026