Technical Summary: POC-GYM: Towards More Reliable LLM-Assisted Proof-of-Concept Exploit Generation

Problem Statement

The generation of Proof-of-Concept (PoC) exploits is critical for validating vulnerabilities, aiding patch development, and serving as regression tests. However, a significant fraction of publicly disclosed vulnerabilities lack available PoCs. While Large Language Models (LLMs) have been increasingly applied to automate vulnerability detection and exploit generation, existing approaches often suffer from reliability issues.

Current LLM-assisted methods typically generate PoCs based on vulnerability descriptions and validate them using shallow signals, such as printed markers, generated files, or runtime side effects. The core problem identified by the authors is that these signals can be satisfied by "false-positive" code paths that do not actually trigger the underlying vulnerability. Consequently, a PoC may appear successful under automated runtime checks while failing to reach the actual vulnerable code location (the ground truth). There is a need for a more reliable generation pipeline that distinguishes between superficial success and genuine exploitation.

Methodology: PoC-Gym Framework

The authors propose PoC-Gym, a hybrid pipeline designed to generate Java PoC exploits by combining Static Application Security Testing (SAST) dataflow traces with LLM reasoning. The framework operates through three iterative stages:

1. Prompt Construction:

   • Vulnerability-Specific Context: The system uses an LLM to generate explicit "CVE-specific guidance," defining a concrete exploit goal and a programmatic validation check based on the CVE and Common Weakness Enumeration (CWE) descriptions.
   • Trace Context: To provide concrete program paths, PoC-Gym integrates static source-to-sink dataflow traces extracted using CodeQL and the IRIS framework. These traces are ranked by an LLM triage assistant to select the most relevant paths before being formatted and inserted into the prompt.
   • Repository Constraints: The prompt includes metadata about the vulnerable repository (URL, commit, build scripts) and strict constraints on API usage (e.g., avoiding reflection, limiting dependencies) to ensure the generated code is executable.

2. PoC Generation:

   • An LLM agent (e.g., Claude Sonnet 4, GPT-5) receives the structured prompt and generates a single Java source file (PoCTest.java).
   • The agent is constrained to create a public class with a main method that triggers the vulnerability and prints a specific success marker ([VULN]).

3. PoC Validation:

   • Runtime Validation: The candidate PoC is compiled and executed on the vulnerable project using AspectJ instrumentation. A candidate is deemed "runtime-valid" only if it:
     1. Exits successfully (exit code 0).
     2. Prints the [VULN] marker.
     3. Reaches the specific sink location defined in the static trace (SinkReachability).
   • Iterative Feedback: If validation fails, a failure summary (including output and trace coverage) is appended to the prompt for the next iteration.
   • Post-Hoc Validation: Crucially, the authors introduce a separate validation step against "ground-truth" vulnerable locations provided by the CWE-Bench-Java benchmark. This step verifies if the execution actually reached the specific file and line range identified in the patch, distinguishing true exploitation from simulation.

Key Contributions

• Hybrid Pipeline: The integration of static analysis-derived dataflow traces with LLM generation and dynamic sink-reachability checks to guide exploit generation.
• Dual-Validation Mechanism: The distinction between "runtime-valid" (satisfying the generation loop's criteria) and "post-hoc valid" (reaching the ground-truth vulnerable location), highlighting the overestimation of success in existing methods.
• Comprehensive Failure Analysis: An in-depth manual analysis of PoCs that passed runtime validation but failed post-hoc checks, categorizing failure modes such as "unrelated errors" (incorrect traces/descriptions), "hardcoding," "simulation" (re-implementing vulnerability logic instead of invoking it), and "bad validation" (unreliable success signals).

Experimental Results

The authors evaluated PoC-Gym on 20 real-world Java CVEs from CWE-Bench-Java using three different LLM configurations.

• Runtime vs. Post-Hoc Validity: Across 338 runs, PoC-Gym generated 116 runtime-valid candidates (34.3%). However, after post-hoc validation against ground-truth locations, only 65 candidates (19.2%) were confirmed valid. This indicates that 44% of candidates appearing successful under runtime checks were actually false positives that did not reach the real vulnerability sink.
• Impact of Trace Guidance: Experiments without trace information achieved a higher initial runtime success rate (86.7%) but a much lower post-hoc validity (36.7%). In contrast, the multi-trace setting had a lower initial success rate (23.0%) but a smaller drop in post-hoc validity (15.5%), suggesting that trace guidance helps filter out invalid solutions that do not correspond to real vulnerable paths.
• Comparison with FaultLine: On the 14 CVEs overlapping with the FaultLine system, the strongest PoC-Gym configuration (Claude Sonnet 4 with traces) achieved 8/14 post-hoc valid results, compared to 5/14 for FaultLine under its original evaluation criteria.

Significance and Claims

The paper claims that while LLMs show promise in generating exploit strategies, they cannot be treated as a complete replacement for deterministic test-generation techniques. The authors argue that:

1. Reliability requires ground-truth validation: Runtime signals alone substantially overestimate exploit correctness; post-hoc validation against known vulnerable locations is necessary to assess true efficacy.
2. Trace context reduces false positives: Although static traces do not eliminate all failures, they significantly reduce the proportion of invalid solutions that satisfy shallow success signals.
3. Failure patterns are systematic: Many failures arise from specific, recurring patterns (e.g., the LLM simulating the vulnerability rather than triggering it, or using unrelated traces). Understanding these patterns is essential for improving future system design.

The authors conclude that future progress in LLM-assisted PoC generation depends not only on improving generation quality but also on developing stronger validation mechanisms and using failure analysis to guide the combination of LLM creativity with specification-driven checks.