PyPI / threadpoolctl / 3.7.0
threadpoolctl 3.7.0
- Source
- https://github.com/joblib/threadpoolctl
- Artifact scanned
threadpoolctl-3.7.0-py3-none-any.whl- Compared with
threadpoolctl-3.6.0-py3-none-any.whl(0 signals introduced since)- Files
- 1 scanned, 4 skipped (binary, oversized, or unrecognised)
- Signals
- 0 critical · 0 warn · 1 info
- Scan time
- 3.8 s
- LLM review
- Reviewed by claude-haiku-5-5 (Anthropic): 1 of 1 warn and critical signal; 1 demoted to info.
- Disclude version
- 4.3.0
- Scanned (UTC)
- 2026-10-23 07:22
Signals
Ordered by severity, then signals introduced in this release. Hidden characters are shown as ⟨U+…⟩.
-
likely benign A __main__ block in threadpoolctl.py calls exec on a command option, then prints thread pool debugging info as JSON.
Reasoning
The exec call runs options.command, which appears to come from the script's own command-line argument parsing, and the block then prints threadpool_info as JSON. That fits a developer debugging CLI that intentionally runs user-supplied code, not an obfuscated or hidden payload. The finding is a real dynamic-execution pattern, but nothing in the snippet shows data fetched from an untrusted source, encoding, or a dropper. The main doubt is that the argument source is not shown, so it is not fully verified.
Reproduce This Scan
Run disclude locally to verify. These commands scan the published file; the "new in this release" marks come from comparing it with the previous release's file, which they don't repeat. Add --format sarif for SARIF output. Add --llm (with an API key in the environment) to include the LLM review.
|