fickling EUVD-2026-114513

Exploitation requires that a victim running fickling version ≤0.1.12 processes an attacker-controlled pickle or model file through check_safety() or fickling.load() while treating the result as a security gate - this is the required user interaction (UI:R), not remote drive-by access. The malicious payload must invoke a callable reachable through a standard-library module that is present in sys.stdlib_module_names and absent from UNSAFE_IMPORTS; the demonstrated callables are version- and platform-limited: dataclasses._create_fn gives code execution only on Python 3.7-3.12 (the internal _create_fn was removed in 3.13), mailcap.findmatch gives code execution only through Python 3.12 (the mailcap module was removed in 3.13), and readline.add_history()/write_history_file() gives arbitrary file write only on POSIX platforms where the readline module is available. These three specific primitives are blocked on the vendor master branch (commit d011709), but the module-origin trust root cause is not fixed, so other stdlib-reachable callables remain a path on all released versions and on Python 3.13+. Key limiting factor: the attack only matters where fickling is actually relied upon to vet untrusted pickles; it does not expose a network service directly.

This is a genuine high-priority issue, but its severity is conditional on fickling being relied upon as a security gate rather than on broad internet exposure. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, base 8.8) is consistent with the mechanism: an attacker needs no privileges, only that a victim (UI:R) processes an attacker-supplied pickle/model file through the vulnerable scanner. The vuln.today decision label is 'this_week', not 'act_now'/'emergency', which matches a serious-but-not-fire-drill posture. Critically, this is CWE-693 (protection-mechanism failure): fickling is itself a security tool, so the real-world impact is a false sense of safety - check_safety() returns LIKELY_SAFE with zero findings for payloads that achieve code execution or arbitrary file write. No EPSS score and no CISA KEV status were supplied, and the input does not confirm a packaged public exploit; absence of these signals is not evidence of low risk, but it means widespread automated exploitation is not demonstrated in the provided data. The dangerous combination is the intended use case: fickling is deployed precisely to vet untrusted ML pickle files, so the population most likely to run it is the population most exposed to malicious input. Net assessment: treat as a real priority for anyone using fickling in a scanning/loading pipeline, while recognizing exploitation is targeted at that specific trust relationship rather than opportunistic against the open internet.

An attacker publishes a malicious ML model or pickle file (for example to a model hub or shared artifact store) whose payload reaches code execution through a standard-library callable such as dataclasses._create_fn or mailcap.findmatch. A victim running fickling ≤0.1.12 scans the file with check_safety() or opens it with fickling.load(), expecting the tool to block dangerous pickles; instead the scanner whitelists the stdlib-origin callable, returns LIKELY_SAFE, and fickling.load() deserializes the payload, executing attacker code with the victim process's privileges. The advisory demonstrates concrete working primitives for this bypass, but the supplied input does not confirm a standalone, packaged public exploit.