Summary
Fickling can incorrectly analyze pickle STACK_GLOBAL references containing dotted attribute paths, treating them as ordinary imports instead of resolving the referenced attribute. When a crafted pickle passes this incomplete safety analysis and is loaded through the library's gated loading path, an attacker may reach a code-executing class method and achieve arbitrary code execution.
Fickling can incorrectly analyze pickle STACK_GLOBAL references containing dotted attribute paths, treating them as ordinary imports instead of resolving the referenced attribute. When a crafted pickle passes this incomplete safety analysis and is loaded through the library's gated loading path, an attacker may reach a code-executing class method and achieve arbitrary code execution.
Affected context
The vulnerability affects Fickling deployments that:
- Analyze pickle data containing
STACK_GLOBALoperands with dotted attribute paths - Rely on
check_safety()as a security gate before deserialization - Load the analyzed pickle through Fickling's loading workflow
The issue is relevant when an attacker can supply or influence a crafted pickle that is subsequently analyzed and loaded. It concerns incomplete handling of attribute paths and is separate from module-origin trust decisions.
The vulnerability affects Fickling deployments that:
- Analyze pickle data containing
STACK_GLOBALoperands with dotted attribute paths - Rely on
check_safety()as a security gate before deserialization - Load the analyzed pickle through Fickling's loading workflow
The issue is relevant when an attacker can supply or influence a crafted pickle that is subsequently analyzed and loaded. It concerns incomplete handling of attribute paths and is separate from module-origin trust decisions.
Exploit preconditions
- Attack surface: Applications or services that accept and process attacker-controlled pickle data through Fickling
- Required access: Ability to provide, replace, or cause loading of a crafted pickle
- Trigger point: Fickling's analysis and subsequent deserialization of a
STACK_GLOBALreference containing a dotted attribute path - Why exploitation is possible: The analyzer tracks only the leading module or name component, fails to fully inspect the referenced attribute path, and may approve the object for loading even though resolution reaches a code-executing method
- Attack surface: Applications or services that accept and process attacker-controlled pickle data through Fickling
- Required access: Ability to provide, replace, or cause loading of a crafted pickle
- Trigger point: Fickling's analysis and subsequent deserialization of a
STACK_GLOBALreference containing a dotted attribute path - Why exploitation is possible: The analyzer tracks only the leading module or name component, fails to fully inspect the referenced attribute path, and may approve the object for loading even though resolution reaches a code-executing method
Why this happens
The underlying flaw is an unsafe mismatch between static pickle analysis and Python's runtime name-resolution behavior. A dotted __qualname__ in a STACK_GLOBAL operand can cause pickle resolution to traverse attributes, while Fickling records and renders only the leading component as an import. Consequently, the referenced method is not modeled as a callable operation and the safety check can return no findings.
This maps primarily to CWE-502: Deserialization of Untrusted Data, because attacker-controlled serialized data reaches pickle.loads() after an incomplete security review. It also relates to CWE-706: Use of Incorrectly-Resolved Name or Reference, because the analyzer does not resolve dotted names according to the runtime semantics used by pickle.
The underlying flaw is an unsafe mismatch between static pickle analysis and Python's runtime name-resolution behavior. A dotted __qualname__ in a STACK_GLOBAL operand can cause pickle resolution to traverse attributes, while Fickling records and renders only the leading component as an import. Consequently, the referenced method is not modeled as a callable operation and the safety check can return no findings.
This maps primarily to CWE-502: Deserialization of Untrusted Data, because attacker-controlled serialized data reaches pickle.loads() after an incomplete security review. It also relates to CWE-706: Use of Incorrectly-Resolved Name or Reference, because the analyzer does not resolve dotted names according to the runtime semantics used by pickle.
Potential impact
- An attacker may achieve arbitrary Python or operating-system command execution in the loading process.
- The application or service processing the pickle could be compromised.
- Sensitive data accessible to the process may be disclosed or modified.
- Compromised execution contexts could be used for lateral movement or persistence.
- An attacker may achieve arbitrary Python or operating-system command execution in the loading process.
- The application or service processing the pickle could be compromised.
- Sensitive data accessible to the process may be disclosed or modified.
- Compromised execution contexts could be used for lateral movement or persistence.
General mitigation guidance
Mitigation generally focuses on eliminating trust in attacker-controlled pickle data and making static analysis match runtime name-resolution behavior.
Common defensive patterns include:
- Avoiding pickle as an interchange format for untrusted or semi-trusted data, using a non-executable, schema-based format where practical.
- Treating every dotted attribute path as a potentially callable or executable reference and resolving the complete path before approving deserialization.
- Failing closed when a name, module, attribute, or callable cannot be completely modeled.
- Applying an explicit allowlist of permitted modules, classes, and callable behavior rather than relying only on blocklists or heuristic checks.
- Separating safety inspection from deserialization and preventing loading when analysis is incomplete, ambiguous, or bypassed.
- Running unavoidable deserialization in a tightly isolated, least-privileged environment with restricted filesystem, network, and process permissions.
- Reducing input trust through authenticated artifacts, integrity checks, provenance validation, and controlled ingestion paths.
Mitigation generally focuses on eliminating trust in attacker-controlled pickle data and making static analysis match runtime name-resolution behavior.
Common defensive patterns include:
- Avoiding pickle as an interchange format for untrusted or semi-trusted data, using a non-executable, schema-based format where practical.
- Treating every dotted attribute path as a potentially callable or executable reference and resolving the complete path before approving deserialization.
- Failing closed when a name, module, attribute, or callable cannot be completely modeled.
- Applying an explicit allowlist of permitted modules, classes, and callable behavior rather than relying only on blocklists or heuristic checks.
- Separating safety inspection from deserialization and preventing loading when analysis is incomplete, ambiguous, or bypassed.
- Running unavoidable deserialization in a tightly isolated, least-privileged environment with restricted filesystem, network, and process permissions.
- Reducing input trust through authenticated artifacts, integrity checks, provenance validation, and controlled ingestion paths.
How teams detect issues like this
High-level detection can include:
- Static analysis rules that identify pickle loading of data from external, mutable, or insufficiently authenticated sources.
- Tests covering
STACK_GLOBALreferences with multi-segment dotted names and verifying that the full attribute path is analyzed. - Code review checks for analyzers that truncate qualified names, model only module prefixes, or assume imported names are non-callable.
- Regression tests confirming that ambiguous or unresolved attribute paths cause a safe rejection rather than an approval.
- Runtime monitoring for unexpected pickle processing, dynamic imports, filesystem reads, child-process creation, or command execution in deserialization workers.
- Policy enforcement that prohibits untrusted pickle loading and requires isolation for approved legacy workflows.
Automated code-review and security-analysis tools may help identify unsafe deserialization and incomplete name-resolution patterns, but should be supplemented with behavior-focused tests.
High-level detection can include:
- Static analysis rules that identify pickle loading of data from external, mutable, or insufficiently authenticated sources.
- Tests covering
STACK_GLOBALreferences with multi-segment dotted names and verifying that the full attribute path is analyzed. - Code review checks for analyzers that truncate qualified names, model only module prefixes, or assume imported names are non-callable.
- Regression tests confirming that ambiguous or unresolved attribute paths cause a safe rejection rather than an approval.
- Runtime monitoring for unexpected pickle processing, dynamic imports, filesystem reads, child-process creation, or command execution in deserialization workers.
- Policy enforcement that prohibits untrusted pickle loading and requires isolation for approved legacy workflows.
Automated code-review and security-analysis tools may help identify unsafe deserialization and incomplete name-resolution patterns, but should be supplemented with behavior-focused tests.
Sources
| Source | Link |
|---|---|
| bombadil. | bombadil.systems/ |
| github. | github.com/ |
| github. | github.com/ |
| pypi. | pypi.org/ |
