GHSA-V3XV-8VC3-H2M6
Vulnerability from github – Published: 2026-03-18 16:33 – Updated: 2026-03-20 21:33Summary
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:
1. Create a malicious plugin file that uses getattr-based indirect calls to bypass AST validation, and confirm the validator incorrectly marks it as safe:
2. Run PySpector Plugin Validator module (this confirms the validator incorrectly marks the plugin as safe):
3. 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": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.1.6"
},
"package": {
"ecosystem": "PyPI",
"name": "pyspector"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33139"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-18T16:33:34Z",
"nvd_published_at": "2026-03-20T20:16:48Z",
"severity": "HIGH"
},
"details": "### Summary\nPySpector versions `\u003c= 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, \u0027system\u0027)`) the outer call\u0027s 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\u0027s machine when loaded.\n\n### Impact\nAn 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\u0027s 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:\n- Full read/write access to the local filesystem\n- Exfiltration of sensitive data and environment variables (i.e. API keys, credentials, etc...)\n- Establishment of persistence mechanisms\n- Lateral movement in CI/CD environments where PySpector runs with elevated permissions (pre-commit hooks and scheduled scans)\n\nAny user of PySpector who installs third-party plugins outside the official repository is potentially affected.\n\n### PoC\nThe following steps reproduce the vulnerability on PySpector `\u003c= 0.1.6`:\n1. Create a malicious plugin file that uses getattr-based indirect calls to bypass AST validation, and confirm the validator incorrectly marks it as safe:\n\u003cimg width=\"1300\" height=\"675\" alt=\"image\" src=\"https://github.com/user-attachments/assets/4de3a0d1-1c77-4454-ad10-2369d5ca9997\" /\u003e\n2. Run PySpector Plugin Validator module (this confirms the validator incorrectly marks the plugin as safe):\n\u003cimg width=\"908\" height=\"239\" alt=\"image\" src=\"https://github.com/user-attachments/assets/3e3b9603-4d95-4a39-be97-4163f6639599\" /\u003e\n3. Install and trust the plugin through the normal PySpector workflow:\n\n`pyspector plugin install /tmp/evil_plugin.py --trust`\n4. Execute the plugin, during a scan:\n`pyspector scan /any/target --plugin evil`",
"id": "GHSA-v3xv-8vc3-h2m6",
"modified": "2026-03-20T21:33:07Z",
"published": "2026-03-18T16:33:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ParzivalHack/PySpector/security/advisories/GHSA-v3xv-8vc3-h2m6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33139"
},
{
"type": "PACKAGE",
"url": "https://github.com/ParzivalHack/PySpector"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "PySpector has a Plugin Sandbox Bypass leads to Arbitrary Code Execution"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.