Summary
Fickling can incorrectly classify dangerous callables from standard-library modules as safe during pickle safety analysis. An attacker who supplies a crafted pickle payload may bypass the safety gate and achieve code execution or unauthorized file writes when the victim process deserializes it.
Fickling can incorrectly classify dangerous callables from standard-library modules as safe during pickle safety analysis. An attacker who supplies a crafted pickle payload may bypass the safety gate and achieve code execution or unauthorized file writes when the victim process deserializes it.
Affected context
The issue affects Fickling deployments that use the library's safety analysis before loading pickle data and rely on versions whose import-trust logic accepts callable names from standard-library modules without evaluating their behavior. It becomes risky when an attacker can provide or influence a pickle payload that reaches a callable incorrectly classified as likely safe, particularly in processes with meaningful filesystem or operating-system privileges.
The issue affects Fickling deployments that use the library's safety analysis before loading pickle data and rely on versions whose import-trust logic accepts callable names from standard-library modules without evaluating their behavior. It becomes risky when an attacker can provide or influence a pickle payload that reaches a callable incorrectly classified as likely safe, particularly in processes with meaningful filesystem or operating-system privileges.
Exploit preconditions
- Attack surface: Pickle data processed through Fickling's safety-checking and loading workflow
- Required access: Ability to supply, modify, or otherwise influence a pickle payload consumed by the victim process
- Trigger point: Safety analysis followed by deserialization through
fickling.load()andpickle.loads() - Why exploitation is possible: The analysis trusts callable names associated with permitted standard-library modules and skips dangerous-call checks without inspecting the callable's behavior
- Environmental factors: Impact depends on the Python version, available standard-library modules, operating-system support, and privileges of the deserializing process
- Attack surface: Pickle data processed through Fickling's safety-checking and loading workflow
- Required access: Ability to supply, modify, or otherwise influence a pickle payload consumed by the victim process
- Trigger point: Safety analysis followed by deserialization through
fickling.load()andpickle.loads() - Why exploitation is possible: The analysis trusts callable names associated with permitted standard-library modules and skips dangerous-call checks without inspecting the callable's behavior
- Environmental factors: Impact depends on the Python version, available standard-library modules, operating-system support, and privileges of the deserializing process
Why this happens
The root cause is an unsafe trust-boundary inference in the deserialization analysis. Fickling adds imported names to a likely-safe set based on the origin module and absence from a denylist, rather than establishing that each resolved callable is behaviorally safe.
The analysis then suppresses findings for calls whose names appear in that set. This maps primarily to CWE-502: Deserialization of Untrusted Data, with CWE-693: Protection Mechanism Failure reflecting the failure of the safety gate to detect dangerous operations. The issue is distinct from dotted __qualname__ resolution weaknesses addressed by a separate vulnerability.
The root cause is an unsafe trust-boundary inference in the deserialization analysis. Fickling adds imported names to a likely-safe set based on the origin module and absence from a denylist, rather than establishing that each resolved callable is behaviorally safe.
The analysis then suppresses findings for calls whose names appear in that set. This maps primarily to CWE-502: Deserialization of Untrusted Data, with CWE-693: Protection Mechanism Failure reflecting the failure of the safety gate to detect dangerous operations. The issue is distinct from dotted __qualname__ resolution weaknesses addressed by a separate vulnerability.
Potential impact
- An attacker may execute arbitrary code in the context of the victim process.
- A payload could modify, create, or overwrite files accessible to that process.
- The attacker could abuse inherited operating-system, application, or cloud credentials.
- The affected application may experience data loss, tampering, or service disruption.
- A compromised process could facilitate lateral movement where additional privileges or network access are available.
- An attacker may execute arbitrary code in the context of the victim process.
- A payload could modify, create, or overwrite files accessible to that process.
- The attacker could abuse inherited operating-system, application, or cloud credentials.
- The affected application may experience data loss, tampering, or service disruption.
- A compromised process could facilitate lateral movement where additional privileges or network access are available.
General mitigation guidance
Mitigation generally focuses on removing implicit trust from deserialization analysis and reducing the consequences of any missed finding.
Common defensive patterns include:
- Treating all externally sourced pickle data as untrusted and avoiding pickle for interchange when a non-executable format is sufficient.
- Requiring callable-level safety evaluation instead of inferring safety from module membership or import origin.
- Maintaining explicit allowlists of narrowly defined data types and operations, with safe behavior as the default.
- Applying schema, provenance, and integrity checks before deserialization.
- Running deserialization in isolated, least-privileged environments with restricted filesystem, process, and network access.
- Separating deserialization from sensitive credentials and high-value application operations.
- Keeping denylist and allowlist policy decisions centralized, reviewable, and covered by regression tests for dangerous standard-library behavior.
Mitigation generally focuses on removing implicit trust from deserialization analysis and reducing the consequences of any missed finding.
Common defensive patterns include:
- Treating all externally sourced pickle data as untrusted and avoiding pickle for interchange when a non-executable format is sufficient.
- Requiring callable-level safety evaluation instead of inferring safety from module membership or import origin.
- Maintaining explicit allowlists of narrowly defined data types and operations, with safe behavior as the default.
- Applying schema, provenance, and integrity checks before deserialization.
- Running deserialization in isolated, least-privileged environments with restricted filesystem, process, and network access.
- Separating deserialization from sensitive credentials and high-value application operations.
- Keeping denylist and allowlist policy decisions centralized, reviewable, and covered by regression tests for dangerous standard-library behavior.
How teams detect issues like this
Organizations can look for:
- Static-analysis patterns that add imported names to trusted or safe-call sets based only on module origin.
- Code paths that skip dangerous-call checks when a function name appears in an inferred allowlist.
- Review signals involving generic pickle loading, dynamic callable resolution, or safety decisions made before full target inspection.
- Regression tests using representative standard-library callables with code-execution, command-execution, and file-write behavior.
- Runtime policy alerts for unexpected child processes, shell invocation, or writes outside approved directories during deserialization.
CI policy enforcement can require approved serialization formats, prohibit unsafe deserialization APIs, and flag changes to trust-boundary logic. Automated code-review and static-analysis tools may help identify these patterns, but findings should be validated against actual control flow.
Organizations can look for:
- Static-analysis patterns that add imported names to trusted or safe-call sets based only on module origin.
- Code paths that skip dangerous-call checks when a function name appears in an inferred allowlist.
- Review signals involving generic pickle loading, dynamic callable resolution, or safety decisions made before full target inspection.
- Regression tests using representative standard-library callables with code-execution, command-execution, and file-write behavior.
- Runtime policy alerts for unexpected child processes, shell invocation, or writes outside approved directories during deserialization.
CI policy enforcement can require approved serialization formats, prohibit unsafe deserialization APIs, and flag changes to trust-boundary logic. Automated code-review and static-analysis tools may help identify these patterns, but findings should be validated against actual control flow.
Sources
| Source | Link |
|---|---|
| bombadil. | bombadil.systems/ |
| github. | github.com/ |
| github. | github.com/ |
| pypi. | pypi.org/ |
