CVE-2026-16760: Fickling check_safety() bypass: likely_safe_imports grants module-origin trust to unvalidated standard library callables

In Trail of Bits fickling through 0.1.12, the processimport() method in fickle.py adds an imported name to the likelysafeimports set whenever the source module is present in sys.stdlibmodulenames and the name is absent from the UNSAFEIMPORTS denylist, without inspecting what the name resolves to or how it behaves. The OvertlyBadEvals analysis pass in analysis.py then unconditionally skips any call whose function name appears in likelysafeimports, including calls that would otherwise be flagged as overtly dangerous. As a result, any callable reachable through a non-blocked standard library module inherits module-level trust regardless of its own behavior, and checksafety() returns LIKELYSAFE with zero findings for pickle payloads that reach code execution or file write through such callables. Demonstrated primitives: dataclasses.createfn, which passes an attacker-controlled function body to exec() and yields arbitrary code execution on Python 3.7 through 3.12 (the internal createfn function was removed in Python 3.13); mailcap.findmatch, which internally calls os.system() on a test command taken from an attacker-controlled caps dictionary, yielding arbitrary code execution on Python versions through 3.12 (the mailcap module was removed in Python 3.13); and readline.addhistory() followed by readline.writehistoryfile(), which writes attacker-controlled content to an arbitrary filesystem path (POSIX platforms, where the readline module is available). fickling.load() chains checksafety() into pickle.loads() as an explicit security gate, so a LIKELYSAFE verdict causes the payload to be deserialized and executed with the privileges of the victim process. The root cause is the inference of callable safety from module origin; it is independent of, and separately fixable from, the dotted qualname resolution weakness tracked as CVE-2026-118938, which this advisory does not address. As of 2026-10-30 the three demonstrated modules were added to UNSAFEIMPORTS on the vendor master branch (commit d011709) pending release; released versions through 0.1.12 remain affected, and the module-origin trust root cause persists, as demonstrated by the related CVE-2026-118938 remaining exploitable on that same build.