arXiv subjects

Baihong Chen

Publications and source records attributed to Baihong Chen.

3 recordsLinked to original sources

arXiv2026

Python Import as an Execution Boundary: An Empirical Study of Bugs, Vulnerabilities, and Analysis Gaps

Python import does more than resolve dependencies: it executes code during module and package initialization. This behavior can trigger failures, load dynamic or native code, access resources, or change security-sensitive state before an application calls a package API. Prior work studies package selection, malicious packages, or package vulnerabilities. We present ImportMine, a study of import-related bugs and security vulnerabilities in Python software. We combine security advisories with PyPI project histories and use source and patch evidence to confirm how import activates cases, why the problem occurs, how developers fix it, and what program information is needed to explain the behavior. We retain 31 import-related advisory vulnerabilities and 38 application-data boundary cases and confirm 1,429 project-history bugs across 1,302 repositories. Among the project-history bugs activated during initialization, 97.6% stop or disrupt normal execution. In contrast, 90.0% of the 20 initialization- activated advisory vulnerabilities are High or Critical. Module-level code and package initialization activate 98.3% of the analyzed history cases. Dynamic loading is much less common, but most of its cases perform security-sensitive actions. We also find that many fixes change when an import becomes active instead of removing the dependency. Finally, we derive ImportVulBench, 228 paired pre-fix and fixed programs covering all 11 bug types.

cs.CR↗

arXiv2026

Beyond Source: An Empirical Study of Python Bytecode Security Risks

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.

cs.CR↗

arXiv2026

Dissecting Software Graphs: Structural Insights for Driver-Guided Fuzzing

Many software systems expose multiple execution modes through command-line options, subcommands, and configuration flags. For such programs, fuzzing depends on both mutated inputs and the invoked mode. Yet evaluations still focus on coverage and bug counts, leaving unclear how execution modes partition, overlap, and miss software structure, and how these differences affect effectiveness. We present an empirical study of software structure under multi-driver fuzzing. We propose a structural abstraction that uses a static call graph as a shared backbone and projects driver-specific dynamic coverage onto it to derive driver-induced subgraphs. Based on this abstraction, we develop a four-phase methodology for backbone construction, fuzzing and profiling, graph-based analysis, and research-question-driven evaluation. We apply it to 27 OSS-Fuzz-derived C/C++ projects, spanning 43 executables and 854 driver configurations. Under the same total budget, multi-driver fuzzing outperforms the best single-driver baseline, increasing covered call-graph nodes by 27.9% and CFG-edge coverage by 73.5%, and revealing 11 unique bugs and abnormal behaviors largely missed by single-driver fuzzing. However, driver contributions are uneven, subgraphs differ substantially in cohesion, fragmentation, modularity, overlap, and residual under-exploration follows recurring regimes rather than a homogeneous tail. These results show that multi-driver fuzzing is fundamentally a structural exploration problem.

cs.SE↗