Coding Agents Propagate Vulnerabilities in Code Bases

Authors: Chenhao Sun, Niels Mündler-Sasahara, Mark Vero, Martin Vechev (ETH Zurich)

Summary (Overview)

• First empirical study of vulnerability propagation by LLM-based coding agents: whether insecure existing code leads agents to introduce similar vulnerabilities in newly generated code
• Two complementary evaluation settings: (1) 96 backend generation tasks with controlled secure/insecure neighboring applications, and (2) 20 pairs of repository-level C/C++ code generation tasks with secure/insecure analogous code variants
• Key finding: All evaluated frontier agents (GLM 5.3, Claude Opus 5/5.5, GPT-5.6 Sol, GPT-6 Astra) propagate vulnerabilities—insecure context reduces secure implementation rates by up to 49.0% in real repositories
• Prompting is not a solution: Following code-style instructions amplify propagation; security warnings reduce but do not eliminate it
• Knowledge-behavior gap: Agents recognize 69.9% of introduced vulnerabilities during review but rarely warn users (0–11.8%), attributing vulnerable choices to following existing code in 76.5% of cases

Introduction and Theoretical Foundation

Background

LLM-based coding agents (e.g., Claude Code, Codex) have become essential in software development. Key statistics:

• 68% of professional developers use coding agents daily (2026 survey)
• Google reports 75% of new code is agent-generated
• Linux kernel has adopted formal policies for LLM-assisted contributions

The Core Problem

Coding agents' most powerful feature—autonomous repository exploration—creates a double-edged sword: agents load existing code as context, which helps them adapt to coding style but also exposes them to existing vulnerabilities. If agents follow vulnerable patterns instead of detecting and avoiding them, each vulnerability becomes a template for new ones.

Problem Setting (Formal Definition)

Let $R$ denote a repository, $t = (d, \ell)$ an implementation task (description $d$ at location $\ell$). An agent $A$ produces implementation $y \sim A(R, t, p)$. The security pass rate is defined as:

$$\operatorname{pass}^{\sec}(C) = \mathbb{E}_{t} \mathbb{E}_{y \sim A(C, t, p)} \left[ \prod_{v \in V(t)} \operatorname{pass}_{t}(y) \times \sec_{t}^{v}(y) \right], \tag{1}$$

where $\operatorname{pass}_{t}(y)$ is the functionality oracle and $\sec_{t}^{v}(y)$ is the security oracle for vulnerability class $v \in V(t)$.

Vulnerability propagation occurs when:

• $\operatorname{pass}^{\sec}(R^{-}) < \operatorname{pass}^{\sec}(R^{\varnothing})$ (insecure context worse than standalone), or
• $\operatorname{pass}^{\sec}(R^{-}) < \operatorname{pass}^{\sec}(R^{+})$ (insecure context worse than secure context)

Contexts: $R^{+}$ (secure), $R^{-}$ (insecure), $R^{\varnothing}$ (standalone/no related code)

Methodology

Evaluation Setting 1: Backend Application Generation

• Tasks: 24 scenarios from AutoBaxBench × 4 frameworks (Python-Flask, Go-net/http, JavaScript-Express, Rust-Actix) = 96 tasks
• Vulnerability classes: CWE-20, CWE-22, CWE-78, CWE-79, CWE-89, CWE-522, CWE-863
• Context: Synthetic web-services project with neighboring applications (functionally independent of target)
• Context variants: $R^{\varnothing}$ (no neighbors), $R^{+}$ (secure neighbors), $R^{-}$ (insecure neighbors)
• Evaluation: Functionality tests + end-to-end exploits (split per CWE class, unified payloads across tasks)

Evaluation Setting 2: C/C++ Repository-Level Coding

• Tasks: 20 pairs from CyberGym across 5 real projects (selection pipeline: single-function patch → fuzzy matching for similar sites → manual review → verify fixability)
• Context intervention: Masked region at known memory-safety vulnerability site; analogous code elsewhere varied between secure/insecure patterns
• Evaluation: Build success + ground-truth proof-of-concept exploit

Agents Evaluated

Prompt Conditions

Empirical Validation / Results

RQ1: Do Agents Propagate Vulnerabilities?

Backend generation (insecure neighbors vs. standalone):

• All three agents show declines: GLM 5.3 (−4.5%), Opus 5 (−2.1%), GPT-5.6 Sol (−3.5%)
• Average decrease: 3.4%

C/C++ repository coding (insecure vs. secure context):

Average gap: 35.4%

RQ2: Do Agents Adopt Secure Patterns?

Backend generation (secure neighbors vs. standalone):

• Gains: GLM 5.3 (+1.4%), Opus 5 (+2.8%), GPT-5.6 Sol (+9.0%)
• Average improvement: 4.4%; average secure-insecure gap: 7.8%

C/C++ repository: Secure context consistently outperforms insecure context (gap of 35.4% vs. 7.8% in backend), suggesting propagation strengthens when agents must rely on surrounding code.

RQ3: How Do Prompts Affect Propagation?

• follow_style amplifies: Doubles GLM 5.3's decline under insecure neighbors (4.5% → 9.0%); widens C/C++ gap to 55.0% for GPT-5.6 Sol
• careful mitigates but doesn't eliminate: Reduces harm from insecure context but also reduces benefit from secure context (non-selective)
• Generic security hint: Substantially improves standalone security but does not eliminate propagation—GPT-5.6 Sol reaches 100% under secure context but drops to 68.0% under insecure context

RQ4: Do Inapplicable Vulnerabilities Affect New Code?

• Insecure neighbors with inapplicable CWE classes produce small, inconsistent changes across agents
• Class-specific analysis shows propagation is mostly same-class (largest effects: CWE-522, CWE-22, CWE-79)

RQ5: Do Agents Recognize and Explain Vulnerabilities?

Critical finding: Agents rarely warn users about vulnerabilities in final responses (0% for GLM 5.3, GPT-5.6 Sol, GPT-6 Astra; 5.9% for Opus 5; 11.8% for Opus 5.5).

Theoretical and Practical Implications

Security Risk Across Frontier Agents

The consistency and magnitude of vulnerability propagation (25–49% gaps in real repositories) make this a critical concern for agent-assisted software development. Even with security warnings, gaps remain between 11% and 32% across all agents.

Knowledge-Behavior Misalignment

Agents demonstrate a fundamental misalignment: they can identify vulnerabilities in review (69.9%) yet still implement them, prioritizing repository conventions over security knowledge. This suggests a deeper alignment challenge: deciding when consistency with existing code is appropriate versus when security demands departure.

Long-Term Code Base Evolution

The findings raise concerns about compounding degradation:

1. Insecure context makes new implementations less secure
2. Effect grows with amount of insecure context
3. Each propagated vulnerability becomes a template for future contributions
4. The "least careful contributor" can establish security standards that even capable agents reproduce

Proposed Mitigations

• Model providers: Train models to weigh security against convention-following when they conflict; include vulnerable-existing-code tasks in training
• Harness developers: Defaults should encourage critical assessment of existing code; add review-after-implementation stages
• Developers: Add security reminders to prompts; fix existing vulnerabilities before delegating tasks

Conclusion

This work identifies vulnerability propagation as a critical security risk in agent-assisted software development. Key takeaways:

1. Insecure existing code degrades generated code security (7.8% average gap in backend, 35.4% in C/C++ repositories)
2. Prompting is insufficient: careful instructions and security hints narrow but never eliminate the gap
3. Vulnerability detection is insufficient: agents recognize defects but implement them anyway
4. Vulnerabilities may accumulate and spread through successive agent contributions, potentially degrading code base security over time

The authors call for coordinated mitigation efforts across model training, security-aware workflows, and active vulnerability removal. Future work should study real-world code base security evolution over successive agent contributions.