Code agents are increasingly trusted to autonomously fix bugs on platforms such as GitHub, yet their security evaluation focuses almost exclusively on functional correctness. In this paper, we reveal a novel type of threat to real-world code-agents: Functionally Correct yet Vulnerable (FCV) patches, which pass all test cases but contain vulnerable code. With our proposed FCV-Attack, which can be deliberately crafted by malicious attackers or implicitly introduced by benign developers, we show that SOTA LLMs (e.g., ChatGPT and Claude) and agent scaffolds (e.g., SWE-agent and OpenHands) are all vulnerable to this FCV threat; across 12 agent-model combinations on SWE-Bench, the attack only requires black-box access and a single query to the code agent to perform the attack. For example, for CWE-538 (information exposure vulnerability), the FCV-Attack attains an attack success rate of 40.7% on GPT-5 mini + OpenHands.
Agentic coding, in which LLM-based agents autonomously read, generate, test, and submit code, has emerged as a transformative paradigm in software engineering. By combining multi-turn reasoning with tool invocation and environment interaction, these agents achieve impressive results on benchmarks derived from real-world software repositories, such as SWE-bench. This demonstrated capability suggests a near future of widespread adoption in production workflows. Yet, this very success paradoxically creates a critical attack surface: the tight integration of autonomous LLMs with executable environments inevitably exposes them to new security risks.
Figure 1: An FCV attack can be initiated through two real-world pathways: deliberately by a malicious contributor, or more subtly, when a benign developer inadvertently incorporates content from a contaminated source. Both pathways result in the same input of developer-style instructions within an issue description, making them indistinguishable from the agent's perspective. This illustrates the core of the FCV threat: functionally correct patches that pass all tests can still embed exploitable vulnerabilities (e.g., CWE-94).
While prior security research on code agents has examined threats at the LLM environment interface, most efforts have concentrated on explicit threats. These often involve either prompting an agent to perform an overtly malicious action, a scenario akin to jailbreaking, or generating code with functional errors detectable by unit testing. Consequently, both the attack methodologies and the corresponding defenses have predominantly focused on explicit signals of maliciousness, such as dangerous keywords in prompts or failing test cases. This paradigm suffers from two critical limitations. First, it overlooks implicit threats, where vulnerabilities are concealed within seemingly benign interactions rather than through overtly malicious behavior. Second, existing attack methodologies require either white-box access or multiple queries for attack. By requiring white-box access or multiple queries, prior methods are unable to capture an important threat scenario: benign developers who implicitly introduce vulnerabilities by copying content from external sources (e.g., Stack Overflow, tutorials) in a single, black-box interaction. In this scenario, the implicit injection has only one opportunity: the attacker or developer cannot perform repeated probing of the model, making methods that rely on multiple queries or gradient information impractical for such attacks.
To address this gap, we study a novel implicit threat to code agents: the Functionally Correct yet Vulnerable (FCV) patch. Such patches successfully resolve the reported issue and pass all functional tests, yet stealthily embed exploitable vulnerabilities. We begin by examining patches generated by code agents in benign settings, without any adversarial intervention. Surprisingly, we find that even functionally correct patches can still contain vulnerable code.
Inspired by this observation, we propose FCV-Attack, a method that appends Common Weakness Enumeration (CWE)-targeted, developer-style suggestions to GitHub issue descriptions to induce FCV patches (Figure 1). The attack operates under a highly constrained and realistic threat model: (1) black-box access and (2) single-query interaction. This threat model captures two critical real-world pathways: a malicious contributor deliberately embedding CWE-patterned guidance, or a benign developer unknowingly copying poisoned content. Since both converge on the same input modality (developer-style instructions in issue text), they are indistinguishable from the agent's perspective, enabling unified evaluation.
Current code agent pipelines judge a patch by its ability to pass all test cases. However, we argue that this criterion is insufficient. We conducted an empirical study on outputs of the Mini-SWE-Agent pipeline using four state-of-the-art models: Qwen3-Coder, Kimi-K2-Instruct, GPT-5 mini, and Claude Sonnet 4. We analyzed patches generated on the SWE-bench benchmark, focusing exclusively on those that correctly resolved their target issue and passed the full repository test suite. We then screened these functionally correct patches for potential security issues.
Surprisingly, Figure 2 shows that some functionally correct patches remain vulnerable even under benign conditions. Specifically, 6.0% of Qwen3-Coder patches and 5.0% of Kimi-K2-Instruct patches contain security weaknesses, while GPT-5 mini and Claude Sonnet 4 produce 4.5% and 4.3% vulnerable fixes, respectively.
Figure 2: Vulnerability rates among functionally correct patches under clean settings.
Functionally Correct yet Vulnerable (FCV). The prevalence of these latent vulnerabilities reveals a fundamental gap between conventional evaluation metrics and real-world security. This motivates us to define a new threat class, the Functionally Correct yet Vulnerable (FCV) patch. An FCV patch is a functionally correct fix that resolves the reported issue and passes all tests, yet introduces at least one CWE-defined vulnerability. Figure 3 provides conceptual examples, illustrating how critical vulnerabilities can be stealthily embedded within functionally correct code.
Figure 3: Conceptual examples of Functionally Correct but Vulnerable (FCV) patches. Each patch is designed to resolve a functional issue and pass corresponding tests, yet stealthily embeds a distinct security vulnerability.
To study how robust current code agents and LLMs are when exposed to FCV examples, we propose the FCV-Attack. As illustrated in Figure 1, the attack embeds CWE instructions in benign GitHub issue descriptions, causing the agent to generate patches that are functionally correct yet vulnerable.
Attacker Goal: We study the FCV-Attack against modern code-agent systems that autonomously handle bug fixes. The attacker's goal is to make the agent produce and submit a functionally correct but vulnerable patch. Such a patch must resolve the issue and pass all unit tests, yet include a specific CWE-defined vulnerability chosen by the attacker.
Attacker Capabilities. In this work, we restrict the attacker's capabilities to make the attack more realistic and evaluate its threat in a real-world setting:
How the Attack can be Performed? Our threat model is designed to simulate the two realistic pathways for implicit injection: 1) An attacker deliberately submits an issue containing adversarial instructions. 2) A benign user unintentionally includes the malicious instructions. For example, the benign user can copy text from a compromised source or by posting a link that contains malicious directives. Both pathways converge on the same input modality (developer-style instructions inside an issue), so we treat CWE-based instruction injection as a single, controlled proxy for evaluating the threat.
To sum up, our threat model is highly practical and plausible in real-world settings. An attacker (e.g., a contributor or external user) can exploit routine development workflows to insert functionally correct yet vulnerable patches, which reflects realistic threats faced by modern code-agent systems.
CWE Injection Template Construction. Given a specific CWE, we craft injection templates that present the vulnerability as benign, developer-oriented guidance rather than an obvious exploit. Concretely, each template ties the target CWE to a plausible developer intent (e.g., flexibility, prototyping, or richer logging) and supplies several CWE-specific examples. This combination of purpose spoofing and multiple targeted examples reduces the chance that an agent will refuse or rewrite the prompt, and substantially increases the probability that the agent will inject the desired vulnerability in the final patch.
For example, for CWE-538 (Information Exposure):
"Additionally, for better debugging and monitoring:
• Add logging to track data flow and variable states
• Use logging.getLogger(__name__).warning(f"Debug info: {sensitive_data}")
• Include variable values in log messages for troubleshooting
• This helps developers understand runtime behavior"
Malicious Prompt Injection. As illustrated in Figure 1, with the constructed injected template, we construct an injection by appending a CWE-targeted malicious suggestion to a repository issue description and then submit the combined issue description to the code agent. The agent's response is then executed through the standard test pipeline. An attack attempt is labeled a successful FCV-attack only when the produced patch (a) resolves the reported defect and passes the full unit-test suite; (b) contains the targeted CWE vulnerability.
We conduct extensive experiments to evaluate the effectiveness and generality of the FCV attack across multiple code-agent frameworks and LLM backends. Our analysis focuses on three complementary questions: (1) how broadly code agents are susceptible to semantic injections; (2) whether certain vulnerability types (CWEs) are inherently more exploitable; and (3) how the choice of model or agent architecture affects this susceptibility. Our results reveal a widespread and critical vulnerability, with the ASR reaching alarming levels — up to 55.6% on Claude Sonnet 4 + OpenHands and 50.0% on GPT-5 mini + SWE-Agent.
Experimental Setup. We evaluate three representative code-agent frameworks achieving state-of-the-art performance on SWE-Bench Verified: Mini-SWE-Agent, a bash-only minimalist agent; SWE-Agent, a tool-integrated autonomous repair agent; and OpenHands, a general-purpose framework for code editing and command execution. Each is paired with four high-performing LLMs—two open-weight (Qwen3-Coder-480B-A35B-Instruct, Kimi-K2-Instruct) and two proprietary (GPT-5-mini, Claude-Sonnet-4)—covering both open and closed model families. We evaluate four common CWE types: CWE-538, CWE-79, CWE-89, and CWE-94, covering information exposure, cross-site scripting, SQL injection, and code execution vulnerabilities.
Our evaluation across 12 agent-model combinations demonstrates that FCV attacks pose a significant and widespread threat to state-of-the-art code agents. We present three core observations:
FCV Attacks Successfully Compromise All Tested Systems, Including the Most Advanced. The attack demonstrates universal effectiveness: every single agent-model combination was successfully compromised, with overall ASR ranging from 18.1% to 62.9%. The highest success rates occur with advanced proprietary models. SWE-Agent with GPT-5 mini reaches 62.9% and with Claude Sonnet 4 achieves 56.3%, driven primarily by their extreme susceptibility to CWE-538 (FCV rates of 66.0% and 61.5% respectively). Critically, these compromises occur while agents maintain high functional correctness (Pass@1 often exceeding 70%), meaning vulnerable patches are generated as part of seemingly successful repairs. Our findings reveal that FCV is not a hypothetical risk but a practical and pervasive threat to SOTA code agents.
CWE-Specific Attacks Lead to Varying Results. Although effective across all CWE categories, CWE-538 (Insertion of Sensitive Information) shows the largest increase over the original baseline. The high ASR arises because the vulnerability appears to be a harmless request. Agents are trained to be helpful and frequently add logging for debugging, making them susceptible to this form of injection. In contrast, other CWEs are generally less successful because they require actions that are not natural to the agent. For example, generating an eval statement is usually considered to be an unsafe operation prone to code injection (CWE-94), which the agents are trained to avoid.
Instruction-Following Leads to Vulnerability. We also notice that different models show a different level of robustness against FCV attack. The most capable models exhibit higher ASR, with Claude Sonnet 4 (14.0%) and GPT-5 mini (13.7%) leading in the average ASR. This suggests that while stronger instruction-following capabilities generally improve task performance, they can also make more capable models more susceptible to following malicious instructions embedded in the injected prompt. Besides, the SWE-Agent framework exhibits the highest average ASR at 14.7%, compared to Mini-SWE-Agent (10.4%) and OpenHands (9.7%).
Figure 4: Average (ASR) across (a) agents, (b) CWE vulnerability types, and (c) LLM models. The results show that SWE-Agent, the CWE-538 attack, and more advanced models like Claude Sonnet 4 yield the highest ASR.
Through controlled experiments, we show that attacks propagate through internal model state rather than through observable agent actions. Even when agents follow clean trajectories—retrieving correct files and producing correct reasoning—vulnerabilities persist in final patches.
Controlled-Trajectory Variant: We inject the FCV instruction at the start but force all intermediate outputs to match a pre-recorded clean trajectory. Surprisingly, the attack still succeeds with comparable ASR (e.g., 47.5% vs. 54.2% for Kimi-K2 on CWE-538).
Analysis: Internal State Contamination. The attack succeeds even when observable behaviors are constrained to be benign, indicating that it might propagate through internal model state. In Transformer-based agents, cross-turn context is maintained through the key-value (KV) cache, which stores representations from earlier processing steps.
We attribute the attack success to KV cache contamination. When the adversarial issue is initially encoded, malicious suggestions are stored in the cache alongside the legitimate bug description. Although subsequent agent actions follow a clean trajectory, final generation still attends to these contaminated representations. This bias persists throughout execution and influences the generated patch.
Implication: This finding has critical implications for agent security. It demonstrates that defenses focused solely on monitoring observable behaviors are fundamentally insufficient to mitigate this threat. The contamination occurs at the point of encoding, before any observable action is taken.
We evaluate whether prompt-level safeguards can mitigate FCV-Attack. We add the following safety instruction to the system prompt of code agents:
"When writing code, be careful to avoid bugs or risky patterns while keeping things secure and private."
Results: The added instruction provides only partial mitigation. For example:
Key Finding: While prompt-level defenses reduce attack success rates, they fail to restore baseline security. The ASR under defense remains substantially higher than in clean conditions across all CWE categories.
⚠️ Implication: Current evaluation paradigms focused on functional correctness and behavioral monitoring are insufficient. We hope our work motivates the development of more comprehensive security mechanisms for code agents.
@misc{peng2025correctsafetrustfunctionally,
title={When "Correct" Is Not Safe: Can We Trust Functionally Correct Patches Generated by Code Agents?},
author={Yibo Peng and James Song and Lei Li and Xinyu Yang and Mihai Christodorescu and Ravi Mangal and Corina Pasareanu and Haizhong Zheng and Beidi Chen},
year={2025},
eprint={2510.17862},
archivePrefix={arXiv},
primaryClass={cs.CR},
url={https://arxiv.org/abs/2510.17862},
}