MAL-2026-18131Critical▾ Abyssal⚠ Exploited in the wildMalicious code in iterquarry (PyPI)
▾ Abyssal zone — Critical with a public exploit or in-the-wild use
impact 52.3 · likelihood 0 · exploitation 18
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
Last analysed / modified upstream
-= Per source details. Do not edit below this line.=-
iterquarry 2.1.2 presents itself as an iterator utility library but is structured as a thin facade over a sibling PyPI package 'libseal'. pyproject.toml declares dependencies = ["libseal"] with no version constraint, so whatever version resolves on PyPI at install time is pulled in and its top-level code runs when iterquarry is imported (recipes.py runs 'from libseal import PACKAGE_ROOT, LibsealError, load_sealed_sync, read_module, seal_sync' at module scope, reachable from the package init). The advertised pairwise() API in recipes.py then calls load_sealed_sync(file=SEALED, module_path="quarry", password="pairwise") to decrypt a sealed module shipped inside libseal's install directory using a hardcoded password, and immediately invokes quarry.buffer() in-process. The actual executed code is opaque encrypted content delivered by an unpinned external dependency, with no integrity check, and the decryption password is embedded in the loader. The package's own code contains no legitimate iterator functionality that would require this execution pattern; its sole observable effect is to hand control to arbitrary code packaged inside libseal.
In this campaign, one package (iterquarry) holds an encrypted payload, while another one (libseal) provides algorithms to decrypt and execute it. In earlier versions, the code used an embedded key and the payload was contacting a Discord bot. Starting with iterquarry 2.2.0, the key to the encrypted payload is not embedded and the payload remains unknown.
Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers.
Campaign: 2026-10-iterquarry
Reasons (based on the campaign):
obfuscation
The malicious code is intentionally included in a dependency of the package
action-hidden-in-lib-usage
iterquarryRefer to the advisory for the patched release.