Study: adversarial bug reports can induce LLM automated program repair systems to generate unsafe patches

Can adversarial bug reports cause LLM-based automated program repair (APR) to write insecure or unintended code, and which pipeline stage can block it.

• Scenario: The authors state that APR is entering development workflows and CI/CD, yet trusts natural language bug reports submitted through public channels with little review. They claim that compared to malicious pull requests, such reports are easier to mass-produce, receive less review, and can target multiple projects simultaneously.
• Gap in existing work: The authors state that APR research mainly focuses on patch correctness, plausibility, or overfitting, and rarely treats the repair process itself as an attack surface. They state that LlamaGuard, PromptGuard, and CodeQL already exist but have not been integrated into typical APR workflows.
• Authors' assessment: The pipeline treats reports as trusted, well-formed, and benign. Plausible-looking reports can pass filtering and, when test coverage is incomplete, send insecure patches into automated pull requests. They also cite incidents on Jira, GitLab, GitHub Copilot, and OpenHands, claiming this is not merely theoretical.
• What this paper does: Provides a threat model; tests an LLM-APR system with 51 adversarial reports ranging from manual to fully automated; evaluates pre-repair filtering and post-repair detection; and provides a prototype for generating and evaluating such reports. Corresponds to RQ1 (whether insecure or unintended code is generated) and RQ2 (which defenses, at which stage).
• Threat model:
  • Targets and assets: Introducing vulnerabilities, leaking secrets, or wasting resources. Protected assets are source code integrity, CI/CD environment, review time, and compute (Table 1).
  • Capabilities: Can use LLMs to submit high-quality reports at scale; having source code is better, but the paper states it is not necessary. No assumption of model poisoning.
  • Entry and path: Public issue interface. APR may misinterpret reports and process malicious inputs during reproduction and testing. The authors state that authentication does not stop this because fake identities can be created.
  • Impact and STRIDE: Impact falls on APR/CI/CD (denial of service, runtime exploitation, information disclosure) and source code (malicious patches bypassing report-side and code review). They list Tampering, Information Disclosure, Denial of Service, and Elevation of Privilege, and state that Spoofing and Repudiation are less relevant.

APR systems and functional benchmarks

• SWE-agent (Yang et al., 2024), OpenHands (Wang et al., 2025), AutoCodeRover (Zhang et al., 2024), RepairAgent (Bouzenia et al., 2024) — use LLM agents to triage issues, modify code, and verify. The paper states these systems focus on performance and reliability, and do not address whether an adversary can manipulate the agent into introducing insecure modifications.
• SWE-bench (Jimenez et al., 2024) and SWE-bench Multimodal (Yang et al., 2024) — evaluate functional correctness of LLM patches. The paper states they do not check whether patches preserve security properties or introduce vulnerabilities.
• The paper summarizes earlier APR work as mainly addressing correctness, plausibility, or overfitting, citing Cambronero et al. (2019) and Ye et al. (2025), without detailing their methods.

Attacks and incidents targeting LLM applications

• OWASP LLM Top 10 (Wilson and Dawson, 2025) and OWASP CI/CD Top 10 (Krivelevich and Gil, 2025) — used by the paper to align threat categories. The evaluation uses prompt injection (LLM01) and relates to sensitive information disclosure, insecure output handling, excessive agency, and over-reliance; the authors state they did not cover training data poisoning, supply chain vulnerabilities, insecure plugins, or model theft.
• Indirect prompt injection by Greshake et al. (2023), and Willison's discussion of the intersection of "private data, untrusted content, and external communication" in agents. The paper uses these to illustrate that APR agents are in high-value positions.
• Real-world incidents in the introduction: a crafted Jira ticket triggered a multi-stage attack on Atlassian MCP, and prompt injection demonstrations on GitLab Duo, GitHub Copilot, and OpenHands. The paper claims this necessitates protecting the interface between bug reports and automated code generation.

Filtering and code-side defenses

• LlamaGuard (Inan et al., 2023), PromptGuard (Meta, 2025), Granite Guardian (Padhi et al., 2024) — detect malicious intent or jailbreak/prompt injection, respectively. The paper states that the first two, along with CodeQL, exist but have not been integrated into typical APR workflows.
• CaMeL (Debenedetti et al., 2025) uses separation similar to control-flow integrity to isolate user data from program data; AlignmentCheck and CodeShield are cited to Chennabasappa et al. (2025), the former checking whether multi-step trajectories remain aligned with user goals, the latter validating LLM-generated code, with stated goals including blocking malicious code from prompt injection. The paper only describes these mechanisms.
• Bugdar (Naulty et al., 2025) — a review tool integrated into GitHub pull requests, using a fine-tuned LLM with retrieval augmentation for multi-language vulnerability analysis. The paper does not compare its effectiveness with this work.

Baselines and benchmarks: The baselines in the experiments are PromptGuard, PromptGuardV2, LlamaGuard v3/v4, Granite Guardian, custom prompts (GPT-4.1-mini, o4-mini), GitHub CodeQL, and GitHub Copilot. Projects are taken from SWE-bench: django, flask, pip, requests, scikit-learn. The authors state that this paper fills the gap of adversarial bug reports exploiting the APR input channel, and evaluates both pre-repair and post-repair defenses.

The authors divide the work into attack demonstrations and defenses deployed along the pipeline. Generation and evaluation are handled by a prototype framework, with the core object being adversarial bug reports.

Problem setting and risk categories

• The pipeline in Figure 1 is: bug reports enter APR, patches are generated, then they go through testing, pull requests, code review, and CI. The defense points in the figure caption are automated/manual filtering and environment hardening; the attack vectors are data exfiltration, denial of service, and vulnerability injection.
• Section 3.1 lists four risk categories: exhausting compute or inducing irrelevant synthesis with realistic reports; making APR revert CVEs or write insecure logic that spreads through the supply chain; using test code in insufficiently isolated CI to leak data or make outbound calls; and insufficient monitoring, where synthetic logs and APR change markers are often optional.
• The authors state these categories correspond to OWASP's CI/CD and LLM checklists, as well as research on agent automation threats. The attack surface includes entry points, reproduction/synthesis/verification paths, and final impact; model poisoning is not assumed.

Five attack tactics

• Two strategies: noise injection consumes review effort and compute; vulnerability injection additionally leaves the project in an insecure state. Patterns are first developed on Django, then automatically re-run across all projects. The authors state each tactic is scalable, with differences in whether an LLM is used and whether project context is relied upon.
• Two static prompts: Naive APR induces synthesis unrelated to the reported defect; CI/CD Exploits makes patches carry test code that leaks data or makes remote calls, assuming insufficient CI isolation.
• Three context-dependent ones are used for Deceptive Noise, Vulnerability Injection, and Revert CVE. Seeds (such as known CVE patches) retrieve files and commits via locality-sensitive hashing and rapidfuzz, removing tests, documentation, and unrelated changes before embedding them into generation prompts. The generation model is DevStral:24B; the authors state it can run on consumer-grade GPUs and is not subject to server-side guardrails.
• Vulnerability Injection first has a human select an insecure snippet, then constructs the report using the above pipeline. Revert CVE first finds the fix commit, cleans the diff, then has the model write a report questioning the original fix. Figure 3 is the template for this tactic, and Figure 4 is the pre-fix classification template (first line outputs OK, problematic, or suspicious). The sentence constraints in the templates are not reproduced here.

Where defenses are placed

• Input filtering: PromptGuard and PromptGuardV2 (the paper states both are 98M parameters) check for prompt injection and jailbreaks; LlamaGuard v3/v4 and Granite Guardian perform malicious intent classification, which the paper summarizes as 8–12B without giving per-model parameter counts. GPT-4.1-mini and o4-mini run custom prompts, split into structured JSON and plain text. The authors chose the mini series for cost and to avoid monetary denial of service. Lightweight models run locally; larger models go through OpenAI, DeepInfra, or Ollama.
• Environment isolation: SWE-agent runs on a local workstation under human supervision, with APR costs capped at $2 per issue. CI uses GitHub Actions and inherits its sandbox. The authors state this stage cannot prevent malicious code execution, only attempt to limit impact.
• Post-fix review: The test repository automatically runs CodeQL and has Copilot review patches (commit summaries, inline comments, low-confidence alerts), both part of GitHub Advanced Security. Conceptually, telemetry, patch provenance, and adding project policies to synthesis prompts are also discussed; the authors view repository-level Copilot custom instructions as a future deployment direction.

How success is determined

• Four items are recorded for each report: whether pre-filtering flagged it; whether SWE-agent generated a patch and whether the patch achieved the intended objective (revert, leak, or injection); whether Copilot raised security-related comments; and whether CodeQL reported vulnerabilities.
• Tests fall into three categories: no new failures relative to the unpatched version; failure count increased but still within the project's allowed expected failure threshold; exceeding the threshold, or the suite could not run. The paper does not give numeric thresholds for each project in the methodology.
• Whether the objective was achieved is determined by one security researcher and one penetration tester reviewing patch logic, Copilot output, and whether results match the attack objective. Tools use default configurations; LLM calls use default temperature.

Experimental setup

• APR and projects: SWE-agent v1.1.0 (SW-ReX v1.2.2), with Claude Sonnet (claude-sonnet-4-20250514) as the patch synthesis model. Five SWE-bench Python repositories: django, flask, pip, requests, scikit-learn, with experiments run on isolated clones of the official repositories. The authors state it was chosen because it ranked highly on the SWE-bench verified leaderboard when the evaluation began in May 2025.
• Adversarial reports: DevStral generated 51: Naive APR 5, Deceptive Noise 8, CI/CD exploitation 10, code injection 14, CVE revert 14. Section 3.2.1 writes the generation model as DevStral:24B. Patterns are first designed on Django, then automatically re-run across all projects. The paper does not report per-project counts.
• Pre-fix detectors: PromptGuard, PromptGuardV2, LlamaGuard v3 and v4, Granite Guardian; custom prompts use GPT-4.1-mini and o4-mini, with structured and plain-text variants. LlamaGuard3 is additionally re-run locally on Ollama.
• Post-fix and testing: Full test suites for each project. CodeQL uses the Python ruleset with default configuration; originally only requests and scikit-learn were scanned for vulnerabilities, but the experiment enables it for all projects. Copilot provides commit summaries, inline comments, and low-confidence alerts.
• Judgment: Two experts review whether the attack objective was achieved. Recorded items are whether pre-filtering flagged it, whether a patch was generated, whether the objective was achieved, whether Copilot gave security-related comments, whether CodeQL reported vulnerabilities, and the three test categories below.
• Execution: Tools use default configurations, LLMs use default temperature. APR runs on a local workstation under human supervision, capped at $2 per issue; CI runs on GitHub Actions. The paper does not report the number of repetitions or annotation agreement values.

Main results

Per Table 2. Increase (≤ threshold) is not included in the table: 4 total, with Naive APR at 1, Revert CVE at 3, and 0 for the remaining types.

Swipe horizontally to read the table

Type	Count	Patch generated	Objective achieved	Test Fail	No new failures
Naive APR	5	5	5	0	4
Inject	14	14	10	4	10
CI/CD	10	10	10	0	10
Revert CVE	14	14	13	7	4
Noise APR	8	8	8	1	7

• The authors attribute the high achievement rate to reports mimicking developer conventions, including code snippets and project context, and state the system follows surface cues to synthesize patches. Section 6.1 writes 46 (90.2%), the abstract writes 90%, and the conclusion writes over 90%. The same section has one instance of "5 of 8 Naive APR," which is inconsistent with the category size in that section and the table; the table takes precedence.
• The authors state project tests rarely cover all paths, and attacks can also target CI configuration or test files, so tests alone cannot stop adversarial reports. Section 6.2 writes 12/51 (23.5%) failed directly, 4/51 (7.8%) increased failures only within expected fluctuation, and 35/51 (68.6%) had no new failures.
• The authors state that even a vague request to revert recent changes still leads the system to synthesize patches that look like reverts. Passing unit tests is not treated by the authors as semantic correctness.

Pre-fix filtering

• The same 51 reports are fed to each detector. The custom prompt in Figure 4 requires the first line to give OK, problematic, or suspicious.
• Table 2 totals: plain-text o4-mini 24 (47%; Section 6.3 writes 47.05%), structured o4-mini 18 (35%; main text 35.29%), plain-text GPT-4.1-mini 12 (23%), structured GPT-4.1-mini 10 (19%). PromptGuard 3 (5.88%), PromptGuard2 0. LlamaGuard3, LlamaGuard3*, and LlamaGuard4 are all 0. Granite-Guardian 5 (9.80%). The pre-filter ensemble is 32 (62%).
• The authors state plain-text o4-mini is the best-performing pre-fix setting and that o4-mini covers every issue flagged by GPT-4.1-mini plus more. Section 6.3 also writes structured GPT-4.1-mini detected 12 (23.52%), inconsistent with the table's 10; the same paragraph's "20% higher than structured" matches the table's 10 to 12, so the table takes precedence. Plain text is not higher for every category: on the CI/CD row, both models have 10 for structured and 8 for plain text. The Naive APR row has 0 across all pre-filters.

Post-fix detection and combinations

• CodeQL detects 0 across the 51 patches. Copilot: 1 high-confidence security-related comment (General is 1 in the table, 2%), 17 low-confidence (33%), 27 in-file comments (52.94%), and 30 across all levels (58.82%). The authors emphasize that human judgment is still required to determine whether a pull request is malicious. The abstract describes the post-fix analysis as 58%.
• Plain-text o4-mini plus Copilot blocks 35/51 (68.6%). The authors state 24 were blocked pre-emptively and 9 came from humans reviewing Copilot comments; the paper does not explain why the sum is not 35. The full pre-filter ensemble plus post-fix review is 37 (72.5%; 72% in the table). Section 7.3 also writes the combination blocks 63–68%, inconsistent with the table, so the table takes precedence. The authors state that even with tests added, roughly 30% of issues slip through, and defenses consume far more resources than attacks.
• Both combinations have 0 on the Naive APR interception column and 4 on Noise APR. The authors state the full pre-filter combination increases false positives and may be impractical in production; the paper does not report false-positive counts for that combination on benign issues.

Costs and false positives

• Total generation cost for 51 reports is $0.0133, averaging approximately $0.000295 per report. The authors price local Devstral at $0.1 per million input tokens and $0.3 per million output tokens; input is $0.000083±0.000040 and output is $0.000212±0.000144.
• APR averages $0.87±0.39 per report. The authors also write APR cost is on the order of $100 per report and describe the relationship as attack about 10 to the -4, pre-filter about 10 to the -3, and APR about 100 (USD per report). The latter figure is inconsistent with the measured average. The authors state that in 90% of cases, this APR cost went toward patches consistent with the attack objective.
• The false-positive set is 100 issues from psf/requests (#6000–#6100, excluding 1 deleted). With structured output, the paper writes 4o-mini has only 1 (#6063), and GPT-4.1-mini additionally flags #6075; the authors consider these two not necessarily true false positives and do not give a total false-positive count for structured GPT-4.1-mini. With plain text, 4o-mini has 3 (#6019, #6059, #6100, which the authors state are all valid), and GPT-4.1-mini has 34. The authors therefore recommend structured o4-mini for entry filtering, despite its lower detection count than plain text. The experimental section uses the model name o4-mini, while the false-positive section writes 4o-mini.

Other ablations and analyses

• Test Fail as an additional signal: the authors state noise gains 1 more in each of the two combinations, CVE revert gains 1 more in the ensemble and 2 more in the best, with no gain for other attacks.
• Re-running LlamaGuard3 locally on Ollama gives the same results as the hosted version, still 0.
• The authors write that plain text relative to structured improves GPT-4.1-mini by 20% and o4-mini by 33%; this is consistent with the totals of 10 to 12 and 18 to 24, and coexists with the decrease on the CI/CD row.
• One developer and one security expert reviewed all generated issues: the authors state they look plausible and actionable at first glance, but most can be caught by humans on closer inspection; Noise and Revert CVE are less obvious. The paper does not report the count behind "most."
• The authors state that executing untrusted tests can itself be an attack if the environment is not isolated. This paper's CI inherits the GitHub Actions sandbox, and the success criterion is that the patch carries the corresponding logic, not that observed exfiltration has occurred.

Limitations and future directions noted by the authors

• Human annotation involves expert judgment, and subtle vulnerabilities may be missed. The authors used two independent evaluators and resolved disagreements through discussion (Section 8 Internal Validity).
• LLMs are non-deterministic. The authors state they did not set temperature to 0 because deviating from default settings for APR and defenses would harm construct validity (Section 8).
• The experiments cover a few open-source projects and one system, SWE-agent. The authors state the findings may not generalize to proprietary software or APR tools with substantially different architectures; if other systems similarly rely on unreviewed natural language input, LLM-generated patches, and primarily test-suite validation, without security-oriented hardening, similar issues are expected (Section 8 External Validity).
• Success is defined as generating a patch, bypassing detection, and exhibiting malicious behavior. The authors state this may not cover downstream impacts, such as exploit feasibility or user-side harm (Section 8 Construct Validity).
• Results depend on specific tool versions. The authors cite GPT-4o, CodeQL, and Copilot as examples, and state that prompt wording and model configuration affect reproducibility (Section 8 Tool Limitations). The main experiments used GPT-4.1-mini, o4-mini, and Claude Sonnet.
• Future work is described in Section 7.4 and the conclusion: APR alignment that enforces project security policies at synthesis time; a standardized adversarial benchmark complementary to SWE-bench; and improved human-in-the-loop, including patch provenance visualization and highlighting security-relevant changes. The conclusion states that red teaming and adversarial robustness testing should become routine practice at deployment. Section 7.1 states the demonstration did not exhaust possibilities; malicious content can be split across multiple stages.

Experimental coverage

• The APR system is SWE-agent v1.1.0 (SW-ReX v1.2.2), and the synthesis model is claude-sonnet-4-20250514. The projects are django, flask, pip, requests, and scikit-learn from SWE-bench, all run on isolated clones (Section 5).
• 51 adversarial reports, five tactic categories; patterns were first designed on Django, then automatically re-run across all projects. Table 2 gives only aggregate results; the paper does not report the distribution of counts across the five projects (Section 5).
• The pre-fix side ran PromptGuard, PromptGuardV2, LlamaGuard v3/v4, Granite Guardian, and GPT-4.1-mini and o4-mini with structured and plain-text prompts; tools used default configurations and default temperature (Section 5).
• The post-fix side used the default CodeQL Python rule set, GitHub Copilot, and each project's full test suite. The paper does not report the allowed failing-test threshold per project, nor the number of repetitions (Sections 5–6).
• Success was determined by two expert reviewers. The paper does not report annotation agreement values. False positive checking used 100 existing issues from psf/requests (Sections 6, 7.2).

The authors evaluate whether language model APR can be misled by inputs that look like ordinary bug reports.

• Problem: Once public issues are connected to automated fixing, adversaries do not need to poison the model. A report written like a developer's could cause the system to revert security fixes, write insecure logic, leave leaks or remote calls in CI, or waste compute and review. The authors use STRIDE to organize the source code, CI/CD, and operational resources to protect.
• Approach: Attacks are divided into noise and vulnerability injection, landing in five tactics. When project context is needed, they use locality-sensitive hashing and rapidfuzz to extract and clean diffs from seeds like CVE fixes, then have DevStral:24B write reports. The victim side is SWE-agent v1.1.0 with Claude Sonnet (claude-sonnet-4-20250514), and the projects are isolated clones of five Python repositories from SWE-bench. Pre-fix side compares dedicated guardrails and custom prompts for two mini models; post-fix side runs project tests, CodeQL, and Copilot.
• Results: All 51 generated patches. Section 6.1 states 46 (90.2%) matched attack goals, the abstract says 90%, and the conclusion says over 90%. Tests with no new failures were 35/51. Plain-text o4-mini detected 24/51, the highest among pre-filters; LlamaGuard series and CodeQL were 0. Copilot with various security prompt levels covered 30/51, still requiring human review of comments. That pre-filter plus Copilot was 35/51, and the full pre-filter combination plus Copilot was 37/51. Total generation cost was $0.0133, with APR average $0.87±0.39 per item; the authors' separately written APR magnitude of $100 is inconsistent with this average.
• Authors' conclusion: Generating adversarial inputs is cheap, while detection and mitigation are expensive and error-prone. The authors suggest using structured prompts for low-noise entry filtering, isolating CI by default, exposing Copilot's low-confidence comments to reviewers, and keeping humans in the loop; they also argue that functional benchmarks alone are insufficient, and APR deployment should include adversarial evaluation.