How severe is CVE-2026-33139?

No CVSS score has been assigned to CVE-2026-33139 yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by CVE-2026-33139?

CVE-2026-33139 affects the following packages: pyspector (PyPI). Ecosystems affected: PyPI.

How do I fix CVE-2026-33139?

Update pyspector to 0.1.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-33139 is resolved across your whole dependency graph.

How do I detect CVE-2026-33139 in my PyPI dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for pyspector, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate CVE-2026-33139 if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Is CVE-2026-33139 actively exploited in the wild?

No public exploit code has been indexed for CVE-2026-33139 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for CVE-2026-33139?

CVE-2026-33139 has an EPSS (Exploit Prediction Scoring System) score of 0.2%, placing it in the 7th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is CVE-2026-33139?

CVE-2026-33139 is classified as CWE-184 (CWE-184). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was CVE-2026-33139 published, and has it been updated?

CVE-2026-33139 was published on March 18, 2026 and was last updated on July 13, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐍 PyPI

Not in CISA KEV

CVE-2026-33139 — pyspector

CVE-2026-33139 is a CWE-184 vulnerability in pyspector. A fix is available for pyspector — see the affected versions and patch details below.

PySpector has a Plugin Sandbox Bypass leads to Arbitrary Code Execution

Also known asPYSEC-2026-3030

Published

Mar 18, 2026

Updated

Jul 13, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Oct 31, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
A successful exploit gives an attacker total control of the affected component, not partial access.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-33139.

EPSS Exploitation Probability

via FIRST.org ↗

0.2%probability of exploitation in next 30 days

Lower Risk-0.01%

Lower risk than most CVEs7th percentile — riskier than 7% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected

🐍pyspector

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

Summary

PySpector versions <= 0.1.6 are affected by a security validation bypass in the plugin system. The validate_plugin_code() function in plugin_system.py, performs static AST analysis to block dangerous API calls before a plugin is trusted and executed. However, the internal resolve_name() helper only handles ast.Name and ast.Attribute node types, returning None for all others. When a plugin uses indirect function calls via getattr() (such as getattr(os, 'system')) the outer call's func node is of type ast.Call, causing resolve_name() to return None, and the security check to be silently skipped. The plugin incorrectly passes the trust workflow, and executes arbitrary system commands on the user's machine when loaded.

Impact

An attacker who can deliver a malicious plugin file to a PySpector user and convince them to install it, can achieve arbitrary code execution on the user's local machine. Exploitation requires the victim to explicitly run pyspector plugin install --trust on the malicious file (a deliberate multi-step action that meaningfully limits the attack surface compared to passive vulnerabilities). However, the bypass directly undermines the security guarantee that validate_plugin_code() is designed to provide. Once the plugin is trusted and executed, the following is achievable:

Full read/write access to the local filesystem
Exfiltration of sensitive data and environment variables (i.e. API keys, credentials, etc...)
Establishment of persistence mechanisms
Lateral movement in CI/CD environments where PySpector runs with elevated permissions (pre-commit hooks and scheduled scans)

Any user of PySpector who installs third-party plugins outside the official repository is potentially affected.

PoC

The following steps reproduce the vulnerability on PySpector <= 0.1.6:

Create a malicious plugin file that uses getattr-based indirect calls to bypass AST validation, and confirm the validator incorrectly marks it as safe: <img width="1300" height="675" alt="image" src="https://github.com/user-attachments/assets/4de3a0d1-1c77-4454-ad10-2369d5ca9997" />
Run PySpector Plugin Validator module (this confirms the validator incorrectly marks the plugin as safe): <img width="908" height="239" alt="image" src="https://github.com/user-attachments/assets/3e3b9603-4d95-4a39-be97-4163f6639599" />
Install and trust the plugin through the normal PySpector workflow:

pyspector plugin install /tmp/evil_plugin.py --trust 4. Execute the plugin, during a scan: pyspector scan /any/target --plugin evil

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐍PyPI	`pyspector`	all versions	0.1.7`pip install --upgrade 'pyspector==0.1.7'`

Affected Products

1 product · 1 configurations

Application

pyspectorparzivalhack

< 0.1.7

range

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for pyspector, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update pyspector to 0.1.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-33139 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

### Summary PySpector versions `<= 0.1.6` are affected by a security validation bypass in the plugin system. The `validate_plugin_code()` function in `plugin_system.py`, performs static AST analysis to block dangerous API calls before a plugin is trusted and executed. However, the `internal resolve_name()` helper only handles `ast.Name` and `ast.Attribute` node types, returning `None` for all others. When a plugin uses indirect function calls via `getattr()` (such as `getattr(os, 'system')`) the outer call's func node is of type `ast.Call`, causing `resolve_name()` to return `None`, and the se