Source-linked AI summary
POLYFLOW: A Neuro-Symbolic Framework for Static Cross-Language Information Flow Analysis
Haoran Yang, Zhixuan Zhong, Jiawei Guo, Haipeng Cai
TL;DR
Cross-language information-flow analysis is difficult because multilingual systems combine heterogeneous semantics, challenging language features, and limited dynamic-test coverage. PolyFlow combines static analysis with guided LLM reasoning and expert-panel validation to analyze these flows, achieving strong benchmark performance and discovering vulnerabilities missed by all baselines.
Problem
Multilingual systems create cross-language vulnerabilities, while existing static analyses struggle with heterogeneous semantics and dynamic features and dynamic approaches have limited test coverage.
Method
PolyFlow augments a lightweight cross-language interprocedural control-flow representation with LLM-identified implicit-flow facts, then performs directed taint approximation and instructed refinement.
Results
PolyFlow achieved 97.9% precision, 87.3% recall, and 91.8% F1 on the microbench, and found 17 previously unknown exploitable vulnerabilities missed by all baselines.
Takeaways & Limitations
The results demonstrate a neuro-symbolic paradigm in which static analysis directs and validates LLM assistance for cross-language vulnerability discovery.
Takeaways & Limitations
The implementation supports only Python-C and Java-C, with Python-C analysis focused on FFI interfaces; LLM reasoning may also hallucinate and be difficult to interpret.
Abstract
from arXiv · showhide
Modern software systems are commonly constructed in multiple, interacting programming languages. This construction leads to additional, often stealthy vulnerabilities buried in complex information flow due to language interactions. Existing static analyzers are impeded by the heterogeneous semantics of different languages, whereas dynamic approaches suffer from the limited coverage of (available and/or generated) test inputs. In this paper, we develop PolyFlow, a neural-symbolic framework for statically reasoning about information flow across language boundaries, combining large language models (LLMs) and static analysis synergistically. Governed by the control-flow representation of a given multi-language system, PolyFlow leverages LLMs to identify implicit flow facts due to challenging language features, hence augmenting the base representation and then propagating data flow through the system. It tackles inherent barriers (e.g., token limit and hallucination) of LLMs by putting them under careful guidance (e.g., static-analysis-guided scoping, context management, and fact checking), along with a multi-LLM expert panel for negotiated validation. Our experiments on real-world Python-C and Java-C systems show that PolyFlow is cost-effective and superior to various kinds of state-of-the-art baselines, revealing previously unknown cross-language vulnerabilities that are missed by all the baselines.
1. Introduction
Multilingual systems create stealthy cross-language vulnerabilities that existing language-specific, dynamic, and static analyses struggle to detect. PolyFlow addresses these challenges with a guided neural-symbolic static analysis that combines LLM reasoning with traditional analysis and demonstrates strong effectiveness on benchmarks and real-world systems.
- Motivation: Multilingual software increases security risk because semantic mismatches, implicit flows, and unsafe data exchange can create stealthy cross-language vulnerabilities.Existing tools often operate in language-specific silos, while dynamic methods depend on scarce or manually generated tests.
- Challenges: Different language semantics and challenging features such as dynamic typing, reflection, function pointers, and inline assembly complicate unified static reasoning.These features can obscure information flow across language boundaries.
- Approach: Static analysis constrains LLM assistance to minimal, on-demand scopes, coordinates interprocedural and inter-language context, and fact-checks outputs through a multi-LLM expert panel.This design targets token limits and hallucinations while retaining symbolic control over the analysis.
- Approach: POLYFLOW combines lightweight cross-language interprocedural analysis with LLM-based identification of implicit flows and fixed-point feature handling.The resulting representation augments explicit control/data-flow facts before taint propagation and refinement.
- Evaluation: The evaluation covers Python-C and Java-C systems, 29 real-world projects, and xFlowBench, a benchmark with ground-truth cross-language information-flow facts.The authors report effectiveness, vulnerability-discovery, cost-effectiveness, and scalability advantages over state-of-the-art baselines.
- Evaluation: 97.9% precision, 87.3% recall, and 91.8% F1 were achieved on the microbench, while real-world systems produced 76.8% precision and 17 previously unknown exploitable vulnerabilities.None of the 17 vulnerabilities were found by any baseline; average analysis consumed 2.81-M tokens per system.
2. Background and Motivation
Multilingual systems create cross-language information-flow vulnerabilities that existing analyses may miss, especially when language-specific features obscure control flow. POLYFLOW is motivated by the need to support challenging features across language boundaries.
- Foreign Function Interfaces let host-language code call guest-language functions, enabling interactions between Python or Java and C.
- Cross-language vulnerabilities arise when information sources and sinks lie in different languages or when language features obscure intermediate flow segments.
- The Cvxopt example combines a Python decorator, a Python-to-C native call, and C function-pointer dispatch to create a format-string vulnerability.
- Existing language-specific analyzers may miss the decorator-registered entry point, unresolved function-pointer target, and cross-language path.
- The motivating study identified 8 C, 6 Python, and 5 Java features that can cause missing analysis entities or flow facts.
- POLYFLOW aims to support all 19 features while using static infrastructure that exposes analysis representations, tolerates incomplete code, and is free at any scale.
3. Technique
POLYFLOW combines a cross-language control-flow representation with LLM-assisted feature handling and taint analysis. Static analysis narrows scope and validates LLM reasoning, while an expert panel supports feature detection and flow refinement.
- POLYFLOW accepts a multilingual repository and source/sink lists, then performs control-flow and data-flow phases assisted by multiple negotiating LLMs.
- Phase 1 constructs a basic CICFG across languages and augments it through fixed-point handling of targeted language features.
- The expert panel uses two efficient non-reasoning models initially and invokes a reasoning model as arbiter when disagreements occur.
- An augmented CICFG spanning both languages provides the structure for identifying taint flows, including cross-language call edges derived from language interactions and FFI specifications.
- Iterative processing revisits related features until no further updates arise, incorporating control-flow edges introduced by dynamic or conditional constructs.
- Phase 2 first approximates source-to-sink taint using directed control-flow reachability, then refines candidate paths with feature knowledge and LLM-assisted context.
4. Implementation and Limitations
POLYFLOW has a modular implementation intended to accommodate new languages, models, and analysis infrastructure. Its main limitations concern LLM reliability, source/sink quality, and restricted language and interface coverage.
- POLYFLOW’s modular architecture allows new language pairs through parsers and language-specific feature handlers while keeping core analysis logic largely language-independent.
- LLM components are accessed through adaptable interfaces, permitting changes or upgrades to foundation models and providers.
- The CICFG construction and augmentation logic is self-contained, allowing potential replacement of Joern for initial control-flow generation when formats are compatible.
- Analysis accuracy depends on LLM capabilities, and hallucinations or difficult-to-interpret LLM decisions remain possible despite expert-panel mitigation.
- Detected taint-flow relevance and completeness are sensitive to inaccuracies in user-provided or LLM-identified source and sink definitions.
- The implementation supports only Python-C and Java-C, and its Python-C analysis focuses on FFI, excluding non-FFI information flows.
5. xFlowBench: A Multilingual Microbench
xFlowBench was created to evaluate cross-language static information-flow analysis on interactions and language features that existing benchmarks may underrepresent. Its benchmarks target systematic assessment across Python, Java, and C.
- Existing benchmarks often lack coverage of cross-language interactions and challenging features relevant to precision and recall evaluation.
- xFlowBench contains 104 micro-benchmarks covering challenging information-flow features across Python, Java, and C.
- Each benchmark focuses on one or more features and tests whether analysis correctly handles constructs that can challenge traditional static analysis.
6. Evaluation
POLYFLOW’s evaluation shows that challenging language features are common in real-world Python-C and Java-C systems, and that its feature-aware, LLM-assisted analysis improves cross-language flow detection. Ablations further show complementary contributions from path coverage, data-flow refinement, and expert-panel reasoning.
- Feature prevalence: First-Class Functions appeared in 10 of 14 Python-C projects, while Java reflection appeared in 87% of Java-C projects.Conditional compilation, function pointers, macros, and callback-related indirection were also common across the evaluated multilingual systems.
- Effectiveness: 0.979 precision, 0.873 recall, and 0.918 F1-score were achieved by the expert panel on xFlowBench implicit-flow identification.The panel was evaluated on identifying implicit control and data flows that traditional static analyzers struggle to interpret.
- Effectiveness: 76.8% precision and 454 true-positive cross-language data-flow paths were achieved across the evaluated projects.POLYFLOW reached 100% precision on five projects, while xLoc failed to detect any vulnerability path.
- Effectiveness: Feature-aware augmentation recovered cross-language control/data-flow facts that made otherwise disconnected source-to-sink paths visible.This supports POLYFLOW’s end-to-end effectiveness across Python-C and Java-C projects at scale.
- Ablation studies: Removing FDF primarily harms precision, removing ACF severely harms recall, and removing the expert panel harms both precision and recall.Without the expert panel, precision fell from 80.4% to 73.8%, while true positives rose only modestly from 348 to 375.
- Efficiency: LLM-centric steps dominate runtime and token consumption, with average LLM-step times of 3.21h and 5.13h for Python-C and 3.90h and 5.20h for Java-C.Per-query latency remained 2.70s on Python-C and 2.50s on Java-C, indicating that runtime is driven primarily by reasoning overhead rather than tokens alone.
7. Discussion
POLYFLOW combines static analysis with guided, multi-LLM reasoning to enrich cross-language control-flow representations and refine taint paths. Its design improves analytical coverage but incurs runtime, component-dependence, validation, and extensibility trade-offs.
- Design principles: POLYFLOW incrementally enriches cross-language interprocedural control-flow graphs with implicit-flow facts identified by LLMs for challenging features.The static analyzer remains the controller and invokes LLMs only within minimal scopes such as functions or control-flow paths.
- Design principles: The expert panel negotiates across multiple LLMs and fact-checks their results against static-analysis facts to mitigate inaccurate outputs.This validation complements adaptive scoping and context management for targeted semantic reasoning.
- Design principles: POLYFLOW first computes a fast taint over-approximation to isolate candidate paths, then applies LLM-driven refinement only to those paths.The two-phase process concentrates expensive reasoning where it matters while keeping analysis practical for real systems.
- Trade-offs and limitations: POLYFLOW inherits parsing limitations and inaccuracies from Joern, while its probabilistic LLM reasoning can also be inaccurate.These dependencies require mitigation such as the expert panel and constrain the reliability of the analysis.
- Trade-offs and limitations: Long runtimes on very large systems reflect a deliberate rigor–speed trade-off caused by iterative feature handling and multistage LLM-assisted taint refinement.The computational cost can limit suitability for some development workflows.
- Trade-offs and limitations: Real-world deployment may require manual exploitability validation, and adding new language pairs demands specialized handlers, interaction rules, and substantial domain expertise.The framework is modular, but extending it beyond supported combinations remains non-trivial.
8. Limitations of Existing Techniques
Existing techniques miss cross-language vulnerabilities for different reasons: static tools fail to resolve some semantic interactions, dynamic tools depend on explored execution paths, and learning-based tools depend on training patterns.
- Static approaches: MultiQL detected no cross-language vulnerabilities because it does not track data flows through Python object fields across language boundaries.In Aubio, it recognizes a Python object reference but cannot resolve subsequent field access on the method.
- Dynamic approaches: Dynamic tools such as PolyCruise and PolyFuzz found none of POLYFLOW’s new vulnerabilities because their effectiveness depends on test-case or fuzzing coverage.The bounter vulnerability requires a large input that causes memory allocation failure, a condition dynamic exploration may miss.
- Learning-based approaches: xLoc found no vulnerabilities in the target projects because learning-based techniques may not generalize beyond bug patterns represented in their training data.Recognizing the bounter case would require examples of cross-language parameter handling leading to unchecked allocation failures.
9. Related Work
Related work spans LLM-assisted program analysis, static taint and information-flow analysis, and cross-language code analysis. These lines of work provide complementary capabilities but do not by themselves establish POLYFLOW’s targeted framework.
- LLM-assisted/agent-based program analysis: LLMs have assisted program analysis tasks including source-code comprehension, vulnerability detection, symbolic-execution constraints, and recovery of binary names and types.Examples include LLift’s symbolic-execution assistance and ReSym’s combination of fine-tuned LLMs with Prolog-based reasoning.
- Static taint/information flow analysis: Static taint and information-flow analyses detect vulnerabilities and privacy leaks through language-level checking or application-level data-flow analysis.Representative systems include JFlow, Pixy, SUPOR, and UIPicker using FlowDroid.
- Cross-language code analysis: Cross-language code-analysis approaches include CodeQL extensions for interoperability rules, WebAssembly-based unified intermediate representations, and differential testing for JVM-language compilers.These approaches address cross-language analysis through distinct static, representation-level, and testing strategies.
10. Conclusion
POLYFLOW is a neuro-symbolic framework for statically reasoning about information flow across language boundaries by combining traditional static analysis with LLMs. It demonstrates cost-effectiveness and cross-language vulnerability discovery across diverse real-world systems, with implementations for Python-C and Java-C.
- Conclusion: POLYFLOW combines traditional static analysis and LLMs to address semantic disparities and challenging language features in heterogeneous software.The framework targets static reasoning about information flow across language boundaries.
- Conclusion: POLYFLOW demonstrated cost-effectiveness and cross-language vulnerability discovery against state-of-the-art solutions on diverse real-world multi-language systems.The conclusion reports merits across both evaluation dimensions without specifying a single representative metric.
- Conclusion: POLYFLOW has been implemented for Python-C and Java-C systems and remains extensible to other language combinations.These combinations correspond to machine-learning, web, and mobile software ecosystems.
Appendix A.
Appendix A presents Conditional Compilation as a representative C feature handler. It augments a CICFG with interprocedural edges for constructs whose execution targets are indirect, deferred, or runtime-resolved.
- Conditional Compilation is the representative C feature handler presented in Appendix A.
- The handler augments a CICFG with additional interprocedural edges.
- Its target construct has execution targets that are indirect, deferred, or runtime-resolved.
A.1. Conditional Compilation
Conditional compilation can hide configuration-dependent statements and control-flow edges from a single preprocessed build. PolyFlow detects these branches, enumerates their guarded statements and feasible edges, and augments the CICFG so downstream taint analysis can traverse them.
- Motivation: A single preprocessed CICFG loses statements and edges from alternative conditional-compilation branches, biasing downstream reachability and taint computations.
- Detection: The handler first asks the expert panel whether each input file contains preprocessor branching, skipping files without directives.
- Branch enumeration: For positive files, the panel returns branch-guarded statements with source lines and feasible cross-branch control-flow edges.
- Augmentation: The augmentation inserts branch-specific statements as condcomp nodes and adds tagged edges, preventing their silent omission under another configuration.
- Example: In the example, downstream taint analysis can reach the NEON intrinsic regardless of the developer’s selected local configuration.
C.1. Polymorphism
Java polymorphic dispatch resolves calls according to a receiver’s runtime type, so static-type-only call graphs can miss concrete overrides and downstream data-flow paths. The handler extracts virtual callsites, determines candidate types, resolves implementations, and augments the CICFG with call/return edges.
- Motivation: Runtime dispatch on interface- or base-class-typed receivers can make purely syntactic call graphs miss concrete overriding methods.
- CICFG augmentation: Each resolved implementation receives augmented CICFG call and return edges for downstream analysis.
- Type resolution: An optional LLM refinement prunes candidate types using local allocation evidence, instanceof checks, and guards.
- Callsite extraction: The handler extracts polymorphic callsites and records receiver, static type, method signature, and call-line information.
- Type resolution: Candidate dynamic receiver types come from points-to information when available, otherwise CHA conservatively enumerates subtypes of the static receiver type.
- Example: In the example, the candidate set contains FileSink and NetSink for the Sink-typed callsite, and refinement leaves both candidates unchanged.