picklescan - Universal Blocklist Bypass via pkgutil.resolve_name

An attacker crafts a pickle file that uses `STACK_GLOBAL` to push `pkgutil.resolve_name` onto the stack, then calls `REDUCE` with the string `"os:system"` (or any other blocked function name) to obtain the actual function object. A second `REDUCE` call invokes that function with an attacker-controlled argument (e.g., a shell command). Because picklescan only checks `GLOBAL`/`INST`/`STACK_GLOBAL` opcodes against its blocklist and does not inspect `REDUCE` arguments, the scan reports zero issues while `pickle.loads` executes arbitrary code [ref_id=1].

picklescan's `_unsafe_globals` blocklist (in versions ≤1.0.3) does not include `pkgutil`, and the opcode scanner only inspects `GLOBAL`/`INST`/`STACK_GLOBAL` opcodes — it never analyzes the arguments passed to `REDUCE` calls. This allows an attacker to chain two `REDUCE` calls: the first resolves `pkgutil.resolve_name` (which is not blocked), and the second invokes the resolved dangerous function (e.g., `os.system`) without that function ever appearing in an import opcode [ref_id=1].

The advisory recommends adding `"pkgutil": {"resolve_name"}` to `_unsafe_globals` and also blocking `importlib` and `importlib.util` to prevent similar indirect resolution gadgets. However, the advisory notes that the blocklist approach is fundamentally fragile — even after blocking `pkgutil`, an attacker could find other stdlib functions that resolve module attributes. The suggested architectural fix is to analyze `REDUCE` arguments for suspicious strings, treat unknown globals as dangerous by default, or switch to an allowlist model [ref_id=1].