Fickling: OBJ opcode call invisibility bypasses all safety checks
Date: 2026-02
Affected: pip/fickling
Attack vector: deserialization
Category: vulnerability-disclosure
Severity: High
CWE: CWE-436

# Assessment The interpreter so it behaves closer to CPython when dealing with `OBJ`, `NEWOBJ`, and `NEWOBJ_EX` opcodes (https://github.com/trailofbits/fickling/commit/ff423dade2bb1f72b2b48586c022fac40cbd9a4a). # Original report ## Summary All 5 of fickling's safety interfaces -- `is_likely_safe()`, `check_safety()`, CLI `--check-safety`, `always_check_safety()`, and the `check_safety()` context manager -- report `LIKELY_SAFE` / raise no exceptions for pickle files that use the OBJ opcode to call dangerous stdlib functions (signal handlers, network servers, network connections, file operations). The OBJ opcode's implementation in fickling pushes function calls directly onto the interpreter stack without persisting them to the AST via `new_variable()`. When the result is discarded with POP, the call vanishes from the final AST entirely, making it invisible to all 9 analysis passes. This is a separate vulnerability from the REDUCE+BUILD bypass, with a different root cause. It survives all three proposed fixes for the REDUCE+BUILD vulnerability. ## Details The vulnerability is a single missing `new_variable()` call in `Obj.run()` (`fickle.py:1333-1350`). **REDUCE** (`fickle.py:1286-1301`) correctly persists calls to the AST: ```python # Line 1300: call IS saved to module_body var_name = interpreter.new_variable(call) interpreter.stack.append(ast.Name(var_name, ast.Load())) ``` The comment on lines 1296-1299 explicitly states: "if we just save it to the stack, then it mi


Mitigations:

Architectural layers (MAESTRO):