CVE-2026-14535
WysokieCVSS 8.8Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 22 - wyżej niż 22% wszystkich znanych CVE
Streszczenie
W bibliotece fickling do wersji 0.1.11 włącznie, analiza UnsafeImportsML rejestruje skrócony kod każdego importu w współdzielonym zbiorze, co powoduje, że następująca analiza MLAllowlist pomija wszystkie sprawdzenia, uznając je za już zgłoszone. W rezultacie MLAllowlist staje się martwym kodem, a importy modułów spoza listy dozwolonych (np. torch, numpy) mogą być pominięte, prowadząc do fałszywie pozytywnego wyniku LIKELY_SAFE.
Ocena ryzyka
Organizacja może zostać oszukana przez fałszywie bezpieczny wynik check_safety(), co umożliwia deserializację złośliwego ładunku pickle i potencjalne wykonanie dowolnego kodu przez atakującego.
Rekomendacja
Należy natychmiast zaktualizować bibliotekę fickling do wersji 0.1.12 lub nowszej, która usuwa współdzielony stan między analizami. Do czasu aktualizacji należy unikać używania fickling.load() z niezaufanymi danymi.
Inne podatności w fickling
Zobacz wszystkie- CVE-2026-22612Wysokie
Fickling, narzędzie do dekompilacji i analizy statycznej plików pickle w Pythonie, przed wersją 0.1.7 zawiera podatność umożliwiającą obejście wykrywania złośliwego kodu. Problem wynika z braku analizy obiektów typu 'builtins' i został naprawiony w wersji 0.1.7.
- CVE-2026-22609Wysokie
Fickling to dekompilator i statyczny analizator plików pickle w Pythonie. Przed wersją 0.1.7 metoda unsafe_imports() nie wykrywała kilku wysokiego ryzyka modułów Pythona, które mogą być użyte do wykonania dowolnego kodu. Złośliwe pliki pickle importujące te moduły nie były oznaczane jako niebezpieczne, co pozwalało atakującym ominąć główne statyczne kontrole bezpieczeństwa Ficklinga.
- CVE-2026-22608Wysokie
Fickling to dekompilator i statyczny analizator plików pickle w Pythonie. Przed wersją 0.1.7 nie blokował on jawnie modułów ctypes i pydoc, co w połączeniu z funkcją pydoc.locate umożliwia zdalne wykonanie kodu (RCE), podczas gdy skaner nadal raportuje plik jako LIKELY_SAFE. Problem został naprawiony w wersji 0.1.7.
- CVE-2026-22607Wysokie
Fickling w wersjach do 0.1.6 nie traktuje modułu cProfile Pythona jako niebezpiecznego. Złośliwy pickle wykorzystujący cProfile.run() jest klasyfikowany jako PODEJRZANY zamiast JAWNIE ZŁOŚLIWY, co może prowadzić do wykonania kodu atakującego.
- CVE-2026-22606Wysokie
Fickling w wersjach do 0.1.6 nie traktuje modułu runpy Pythona jako niebezpiecznego. Złośliwy pickle wykorzystujący runpy.run_path() lub runpy.run_module() jest klasyfikowany jako PODEJRZANY zamiast JAWNIE ZŁOŚLIWY. Może to prowadzić do wykonania kodu atakującego, jeśli użytkownik polega na wynikach Ficklinga przy deserializacji.
- CVE-2026-14534Wysokie
Podatność w bibliotece fickling do wersji 0.1.10 włącznie polega na braku modułów standardowej biblioteki Pythona (_posixsubprocess, site, atexit) na liście UNSAFE_IMPORTS. Powoduje to, że funkcja check_safety() błędnie klasyfikuje złośliwe ładunki pickle jako LIKELY_SAFE, co umożliwia ich deserializację i wykonanie niebezpiecznych funkcji, takich jak fork_exec, execsitecustomize czy _run_exitfuncs.
Oryginalny opis (angielski, źródło NVD)
In Trail of Bits fickling versions up to and including 0.1.11, the UnsafeImportsML analysis pass unconditionally calls AnalysisContext.shorten_code(node) on every import node it inspects, regardless of whether the import is flagged as unsafe. This call registers the shortened code representation in the shared AnalysisContext.reported_shortened_code set. When the MLAllowlist analysis pass subsequently runs, it calls the same shorten_code() method, receives already_reported=True for every import, and executes a continue statement that skips its allowlist check entirely. This renders MLAllowlist dead code for all imports — it never evaluates whether an import is in the ML allowlist or not. The MLAllowlist pass was designed to catch imports of modules outside the known-safe ML ecosystem (torch, numpy, transformers, etc.) that slip past the UnsafeImports denylist. With MLAllowlist inoperative, any standard library module not in the UNSAFE_IMPORTS denylist can be invoked via pickle deserialization while fickling's check_safety() returns LIKELY_SAFE. The fickling.load() API chains check_safety() into pickle.loads() as an explicit security gate, meaning a LIKELY_SAFE verdict causes the payload to be deserialized and executed. The root cause is shared mutable state between independently-correct analysis passes — UnsafeImportsML works as designed in isolation, MLAllowlist works as designed in isolation, but the shared reported_shortened_code set causes UnsafeImportsML to poison MLAllowlist's deduplication logic.