Aug 2026· 1 citation· ⚡ 1 influential· 31 references
Computer Science
TL;DR
An empirical study of Python bytecode as a security artifact is presented, measuring bytecode exposure in PyPI distributions, evaluating practical analyzability using version-aware tooling, assessing CPython runtime robustness under adversarial bytecode, and test source-level reproduction of bytecode findings.
Abstract
Python package security is largely source-centric, yet Python runtimes can execute bytecode directly through .pyc files, compiled-only modules, and marshalled code objects, creating an inspection-execution gap. We present an empirical study of Python bytecode as a security artifact. We measure bytecode exposure in PyPI distributions, evaluate practical analyzability using version-aware tooling, assess CPython runtime robustness under adversarial bytecode, and test source-level reproduction of bytecode findings. Across 1,034,843 collected PyPI artifacts, we identify 7,388 bytecode-containing artifacts, including 228,578 .pyc files and 28,193 artifact-local source-less .pyc files. For modern CPython 3.8-3.14 bytecode, at least one selected decompiler emits source for 204,901 of 204,904 in-scope files, a result measuring emission rather than verified functional equivalence. Tools are non-robust: observed PyPI bytecode triggers managed-code exceptions and timeouts, while adversarial mutated bytecode also drives decompilers into native process failures; together these outcomes yield 17 distinct robustness signatures. Fuzzing produces 1,009 stack-deduplicated runtime findings dominated by pointer-dereference symptoms; 261 groups exhibit potential memory-corruption characteristics, and at least 91.7% of groups reach execution beyond the documented-unsafe ingestion boundary. None reproduce from ordinary Python source. Bytecode is thus a visible ecosystem artifact, a practical analysis target, and a security-relevant interpreter input whose behavior need not match source-level behavior.
This work presents SCRIPTIOC-BENCH, a benchmark for measuring static IOC extraction capability on real-world malicious scripts, and evaluates a broad range of proprietary and open-weight LLMs, showing that IOC recovery without execution remains challenging across model scales.
Hanna Kim, Jian Cui, Minkyoo Song et al.· 0 citations
The Static-Pass Dynamic-Fail (SPDF) phenomenon and a three-stage agentic pipeline combining static scanning, LLM-driven Common Weakness Enumeration (CWE) reasoning, and autonomous exploit verification in isolated Docker containers are introduced.
Jessica Pourleyli, Maitreyee Das Urmi, Glaucia Melo· 0 citations
Malicious npm package detection tools now leverage LLMs'semantic understanding of source code to detect malicious intent at scale. This capability has proven invaluable in identifying packages involved in recent supply-chain attacks such as Shai-Hulud. However, threat actors exploit the limited context windows of LLMs...
Jean-Charles Noirot Ferrand, David Adei, Anders Møller et al.· 0 citations
This work presents an end-to-end methodology and the first measurement-based study that systematically compares malware generated by censored and uncensored LLMs against 119 real-world malware samples from multiple families and categories, estimating how safety-alignment affects malicious capabilities.
Francesco Saccone, Giuseppe Riccio, Filippo Ianniello et al.· Journal of Computer Virology...· 0 citations
A security assessment on 75 FastAPI backends generated by three contemporary LLMs revealed a disconnect between functional correctness and secure logic, which is interpreted as a review-risk pattern, which is called the human-in-the-loop paradox.
Abdul Ali Khan, S. Rauti, T. Mäkilä· IEEE Access· 0 citations
Behavioral malware analysis relies on dynamic-analysis logs—sequences of Windows API calls recorded by sandboxes such as CAPEv2—assumed to represent the malware’s effects faithfully. To the best of our knowledge, this assumption has never been tested by re-executing the recorded calls. We propose WinAPIReplay, which re...