Pith. sign in

REVIEW 4 major objections 5 minor 2 cited by

Inducing Vulnerable Code Generation in LLM Coding Assistants

T0 review · 4 major / 5 minor · reviewed 2026-08-16 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Attackers can plant a short, meaningless sequence in an otherwise correct code answer and cause LLM coding assistants to generate attacker-chosen vulnerable code, with reported success rates over 80%.

desk verdict The headline 84.29% ASR is an optimization-run success rate, not a held-out attack success rate; the paper still demonstrates a real and transferable poisoning attack on retrieval-augmented code generation, but it needs honest reporting before publication. read the letter →

arxiv 2504.15867 v1 pith:OQCEHH2Q submitted 2025-04-22 cs.SE

Binqi Zeng , Quan Zhang , Chijin Zhou , Gwihwan Go , Yu Jiang , Heyuan Shi This is my paper · ORCID
classification cs.SE
keywords LLMsecuritycodegenerationretrieval-augmentedcodingassistantsattacksequencepromptinjectionStackOverflowpoisoningtransferableadversarialattacksvulnerable
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper claims that an attacker who posts a correct-looking answer to a programming question can embed a short meaningless string—an attack sequence—that, when retrieved by an LLM coding assistant, steers the model to emit code containing a chosen vulnerability such as a buffer overflow or missing validation. The claim matters because popular coding assistants routinely fetch external solutions from the web, so a poisoned answer could reach developers without any compromise of the model itself. The reported prototype, HACKODE, achieves an average 84.29% attack success rate across four open LLMs and 75.92% on a retrieval-based assistant in a local-web experiment, with attack sequences averaging about 33 tokens.

What carries the argument

The load-bearing object is the attack sequence (Seq), a short string of tokens generated by a two-phase gradient-guided mutation procedure and inserted into the referenced code as a comment. In the first phase, HACKODE optimizes a preliminary sequence against a fixed assembled input—query, instruction, prompt template, and reference—by computing cross-entropy loss between the model's logits and the target vulnerable code and replacing tokens with gradient-scored alternatives. In the second phase, it mutates the sequence further against randomly assembled inputs so the sequence generalizes across variations the attacker cannot control. The procedure treats the target vulnerability as a token-level goal and the attack sequence as the only manipulable variable.

What would settle it

Conduct a field test in which crafted but harmless answers are posted to a live Q&A forum and a retrieval-augmented coding assistant searches the open web without local-page forcing; if such pages are rarely retrieved or ranked below legitimate answers, the reported 75.92% real-world attack success rate would not transfer to actual deployments. A second check: measure whether removing the comment-inserted attack sequence while keeping the code identical eliminates the vulnerable output, confirming that the sequence itself is the causal agent.

Watch

Extended reading notes

Core claim

The central discovery is that LLMs generating code from external references can be induced to produce vulnerable code even when the referenced example is functionally correct and human-readable. The vulnerability appears because the attack sequence, inserted as an innocuous code comment near the code to be altered, biases the model's token predictions; the paper measures this by checking whether the target vulnerable code appears in responses. Across 35 StackOverflow-derived problems and five vulnerability types, the attack succeeded on average in 84.29% of cases over two general LLMs (Llama2-7b, Mistral-7b) and two code LLMs (CodeLlama-7b, StarChat2-15b), and it transferred to randomly assembled prompts and to GPTQ and BitsAndBytes quantized models with lower but substantial success rates.

Load-bearing premise

The real-world impact claim rests on the assumption that attacker-posted, correct-looking answers will actually be retrieved and ranked highly by coding assistants during organic web searches; the real-world experiment forced retrieval by hosting crafted pages locally rather than demonstrating organic ranking.

Editorial extensions

If this is right

  • Retrieval-based coding assistants can be attacked without access to model weights: attackers only need to publish a correct-looking answer containing the attack sequence.
  • Because attack sequences average 33 tokens, roughly 3.4% of the assembled input length, the manipulation is hard for a human reader to spot in a code answer.
  • The generated attack sequences transfer to unseen prompt templates, instructions, and user queries, and to GPTQ and BitsAndBytes quantized models, with average success rates of 48.07% and 53.45%.
  • Comment insertion is markedly more effective than variable renaming as an embedding position, raising average attack success rate from 11.43% to 80.00% on Mistral-7b.
  • Five vulnerability classes are inducible (CWE-125, CWE-787/CWE-120/CWE-122, CWE-457/CWE-190, CWE-20/CWE-570, CWE-835), so the threat is not limited to a single flaw type.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Extension: if search engines and Q&A forums rank human-plausible answers highly, this attack could combine with SEO to poison coding assistants at scale, turning every retrieved snippet into a potential exploit delivery vehicle.
  • Extension: a concrete defense to test is post-generation static analysis of LLM output; the paper notes high false-positive rates, so a calibrated experiment comparing detection of naturally vulnerable versus HACKODE-induced code would tell whether such tools can blunt the threat.
  • Extension: the mechanism suggests a broader class of reference poisoning beyond code—documentation pages, API examples, and config snippets could be tested for the same comment-insertion effect.
  • Extension: larger or safety-tuned closed models may resist better; a transfer test against a frontier model's retrieval pipeline, without access to model weights, would clarify how far the success rates generalize.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper presents HACKODE, an attack against LLM coding assistants that incorporate external references. The attacker posts a correct-looking code solution containing a short, optimized "attack sequence" hidden in a comment; when a retrieval-augmented assistant feeds this reference into an LLM, the sequence steers the LLM to generate code containing a predetermined vulnerability. The attack sequences are produced by a two-phase gradient-guided token-mutation algorithm (Algorithm 1) over a set of assembled inputs built from varied prompt templates, instructions, and user queries. Evaluation on 35 StackOverflow-derived problems across four 7B-15B open models reports an average 84.29% ASR (Table II), 57.97% average per-input transfer to fresh assembled inputs (Table VI), 50.76% on quantized models (Table IV), and 75.92% ASR on a ChatChat-based assistant with locally hosted references (Table V). The authors conclude that HACKODE poses a realistic real-world threat.

Significance. The attack surface is real and increasingly relevant: retrieval-augmented coding assistants are deployed, and poisoning external references with imperceptible content is a plausible supply-chain risk. The paper's core mechanism--optimizing a short token sequence in a comment to condition the model toward a target vulnerability--is interesting, and the ablations (progressive generation, insertion position) are useful. The strongest parts are the transfer evaluation on held-out assembled inputs and quantized models, and the release of source code. However, the significance of the headline numbers is currently overstated: the 84.29% figure is an optimization-run success rate rather than a deployment-time success rate, and the causal contribution of the sequence is not isolated from baseline LLM error. With a proper control condition and honest reporting of the held-out transfer ASR, the contribution would be solid empirical evidence for a new class of attack.

major comments (4)
  1. [§V-A and Algorithm 1 (Tables II, III, VI)] The headline 84.29% ASR in Table II is an optimization-run success rate, not a held-out success rate. In Algorithm 1, a run terminates when tVul appears in the output on the fixed input used during optimization (lines 6-7 for the preliminary phase and lines 15-16 for the enhancement phase), so Table II records the fraction of runs that found a sequence, not the probability that a fixed sequence succeeds on a fresh input. The paper's own held-out transfer evaluation gives a per-input average ASR of 57.97% (Table VI) and only 37.85% of problems pass all five fresh inputs (Table III). The abstract and conclusion should be reframed around the transfer success rate, and Table II should be labeled accordingly.
  2. [§V-A, §V-C (evaluation design)] There is no no-attack control. The experiments never measure the frequency with which the target LLMs generate the target vulnerability from the correct reference without the attack sequence. Since the target vulnerability is a small modification of the correct code (e.g., changing `histogramBinCount` to `histogramBinCount + 1` in Figure 5), part of the reported ASR could be ordinary LLM error on the referenced code rather than an effect of the sequence. A control condition (reference only, or reference with a benign comment of similar length) is required to attribute the observed vulnerable generation to the attack sequence. This concern applies to Tables II, III, and V.
  3. [§V-C and §VI (real-world experiment)] The real-world experiment does not exercise organic retrieval and ranking. The assistant was forced to retrieve from local web pages containing the crafted answers, and the tested models (Mistral-7b and CodeLlama-7b) are the same models on which the attack sequences were generated. The 75.92% ASR therefore measures transfer to one application's prompt template under forced retrieval, not success against real search ranking or against unseen models. The Discussion argues that such crafted answers would likely be prioritized, but this is not tested; the abstract's "real-world impact" claim is stronger than the experiment supports. The authors should present this as a controlled simulation and temper the corresponding claim.
  4. [§V-A and Algorithm 1 (vulnerability detection)] The vulnerability-matching procedure is underspecified. In the implementation description, the success check is only described as "comparing the differences between the code lines in the response and the correct code," and §V-C states that responses were "checked if the responses ... contained vulnerabilities" without specifying the exact matching rule, the handling of semantically equivalent but textually different code, or the criteria for distinguishing target vulnerabilities from similar benign patterns. Since every reported ASR depends on this check, the paper should provide the precise detection rule or release the verification script as part of the artifact.
minor comments (5)
  1. [§V-B (Table III)] The answer to RQ2 states an "average ASR of 57.97%" but Table III presents cumulative percentages of problems passing at least N tests; the relationship between the table and the reported average should be stated explicitly, or the per-input average should be shown directly in the table.
  2. [Algorithm 1, line 9] The notation `pSeq m := (pSeq[i]← pSeq[i] + grad[i])m` is confusing; the authors should clarify that m variants are generated and how the index i is selected.
  3. [§V-B (RQ2 wording)] The research question uses "quantified LLMs" where "quantized LLMs" is intended; likewise, the limitation section uses "quantified" in one place. These typos should be corrected.
  4. [§IV-A (User Query derivation)] The description of how generated queries are verified on StackOverflow does not specify which LLM is used for rephrasing or the verification criteria, which limits reproducibility; please provide the prompts and filtering rules.
  5. [§I (Motivating measurement)] The statement that GPT-4 can solve only 19 of the 50 most recently answered StackOverflow problems should include the evaluation date, model version, and sampling methodology, since this claim is used to motivate the need for external reference retrieval.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: HACKODE is an empirical attack whose success metric is its own optimization objective, with separate held-out transfer evaluations.

full rationale

This paper is an empirical attack study, not a derivation from first principles. The attack sequence Seq is optimized via gradient-guided token mutation so that the target LLM emits the target vulnerability tVul (Algorithm 1, lines 6-7 and 15-16); reporting the attack success rate on that same objective is the standard success measure for adversarial-example search, not a disguised fit. The paper separately evaluates transfer to assembled inputs built from instructions, queries, and prompt templates not used during generation (Section V-B), to quantized LLMs (Table IV), and to a real-world ChatChat assistant using locally hosted crafted pages (Section V-C). These are held-out, independent tests. There are no load-bearing self-citations: the cited works are prior external results and are not invoked to justify the attack's validity, and there is no imported uniqueness theorem or ansatz smuggled in via citation. The limitations section acknowledges scope restrictions on open-source models, parameter sizes, and quantization behavior, but none of these statements indicate a circular step. The distinction between the headline 84.29% optimization-run success and the lower per-fresh-input transfer numbers in Table III is a metric-interpretation caveat, not circularity. Overall, the derivation chain is self-contained: the attack method, its objective, and its evaluation are clearly separated, and the central claim rests on measured behavior rather than on redefining inputs as outputs.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The central claim is an empirical attack, not a derivation. The free parameters are experimental hyperparameters that affect reported success and transfer estimates. The axioms are threat-model and optimization assumptions: input assembly, retrieval, open-weight victim models, and the token-gradient heuristic.

free parameters (3)
  • maxStep = 500
    Maximum mutation iterations for attack sequence generation; hand-picked, affects the reported ASR and generation cost.
  • k = 3
    Number of randomly assembled inputs used per enhancement step; hand-picked, affects the transferability estimate.
  • m
    Number of candidate mutated sequences per iteration in Algorithm 1; referenced but never given a value, leaving the optimization under-specified.
assumptions (4)
  • domain assumption LLM coding assistants assemble the final model input from a prompt template, an instruction, a user query, and a retrieved reference (Section IV).
    The entire attack model and evaluation depend on this input assembly being representative of real applications.
  • domain assumption Attacker-posted correct-looking answers will be retrieved and ranked by coding assistants in real-world search conditions.
    The real-world impact claim depends on this, but the experiments only force retrieval from local pages rather than demonstrating organic retrieval.
  • domain assumption Victim assistants use open-source LLMs or their fine-tuned or quantized versions, so attacks transfer from public models (Section III).
    The paper explicitly restricts its threat model to open-weight models and does not test closed-source APIs.
  • domain assumption Cross-entropy gradients with respect to one-hot token vectors provide a usable signal for mutating discrete tokens (Algorithm 1).
    This is a common heuristic in adversarial NLP, but it is not proven here and its reliability affects the reported success rates.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Inducing Vulnerable Code Generation in LLM Coding Assistants." pith.science (2026). https://pith.science/paper/OQCEHH2Q

@misc{pith2026250415867,
  author       = {Pith},
  title        = {Pith review of: Inducing Vulnerable Code Generation in LLM Coding Assistants},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/OQCEHH2Q}},
  note         = {Machine review of arXiv:2504.15867}
}
read the original abstract

Due to insufficient domain knowledge, LLM coding assistants often reference related solutions from the Internet to address programming problems. However, incorporating external information into LLMs' code generation process introduces new security risks. In this paper, we reveal a real-world threat, named HACKODE, where attackers exploit referenced external information to embed attack sequences, causing LLMs to produce code with vulnerabilities such as buffer overflows and incomplete validations. We designed a prototype of the attack, which generates effective attack sequences for potential diverse inputs with various user queries and prompt templates. Through the evaluation on two general LLMs and two code LLMs, we demonstrate that the attack is effective, achieving an 84.29% success rate. Additionally, on a real-world application, HACKODE achieves 75.92% ASR, demonstrating its real-world impact.

Figures

Figures reproduced from arXiv: 2504.15867 by the authors.

Figure 1
Figure 1. An example of HACKODE on an LLM coding assistant. The assistant references the correct code posted by attackers, leading LLMs to generate code with vulnerability. current LLM applications are likely to reference malicious external information, leading to financial losses [6]. In this paper, we investigate a new threat where LLMs may generate vulnerable code when referencing example code that appears correct to the h… view at source ↗
Figure 2
Figure 2. An example of assembled input derivation. Attackers produce an [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 4
Figure 4. Overview of HACKODE: First, it derives various assembled inputs by considering different instructions, prompt templates, and user queries. Second, it generates a preliminary attack sequence for a fixed assembled input. Third, it refines the sequence to enhance its transferability across the derived diverse assembled inputs. a fixed assembled input. HACKODE then generates a pre￾liminary sequence effective for this fi… view at source ↗
Figures from the paper (1 more)
Figure 5
Figure 5. Figure 5: A real-world example of HACKODE. Attackers post a correct solution with an attack sequence, guiding the coding assistant to generate vulnerable code with ‘out-of-bounds write’. In this real-world experiment, attackers do not need to know the detailed settings, like pro…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. WildCode Revisited: A Comprehensive Empirical Study on the Security of LLM-Generated Code

    cs.CR 2025-12 conditional novelty 6.0 of 10

    Using real ChatGPT conversation logs, code generated by the model is frequently insecure and users rarely request security-related code.

  2. CodeMirage: A Multi-Lingual Benchmark for Detecting AI-Generated and Paraphrased Source Code from Production-Level LLMs

    cs.SE 2025-05 conditional novelty 6.0 of 10

    CodeMirage is a ten-language, ten-LLM benchmark with original and paraphrased AI code, and it shows current AI-generated-code detectors drop sharply under cross-model and low-false-alarm settings.

Reference graph

Works this paper leans on

59 extracted references · 36 canonical work pages · cited by 2 Pith papers

  1. [1]

    Language models are few-shot learners

    Tom Brown, Benjamin Mann, Nick Ryder, Melanie Sub- biah, Jared D Kaplan, Prafulla Dhariwal, Arvind Nee- lakantan, Pranav Shyam, Girish Sastry, Amanda Askell, et al. Language models are few-shot learners. Advances in neural information processing systems, 33:1877–1901, 2020

    1901

  2. [2]

    Api-assisted code generation for question answering on varied table structures, 2023

    Yihan Cao, Shuyi Chen, Ryan Liu, Zhiruo Wang, and Daniel Fried. Api-assisted code generation for question answering on varied table structures, 2023

    work page 2023

  3. [3]

    Jailbreaking black box large language models in twenty queries

    Patrick Chao, Alexander Robey, Edgar Dobriban, Hamed Hassani, George J Pappas, and Eric Wong. Jailbreaking black box large language models in twenty queries. arXiv preprint arXiv:2310.08419, 2023

    arXiv 2023

  4. [4]

    Chatchat

    Chatchat-Space. Chatchat. https://github.com/chatchat- space/Langchain-Chatchat, 2023

    work page 2023

  5. [5]

    Evaluating large language models trained on code

    Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al. Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374 , 2021

    arXiv 2021

  6. [6]

    User solana wallet exploited in first case of ai poisoning attack, 2024

    Cryptopolitan. User solana wallet exploited in first case of ai poisoning attack, 2024. URL https://coinstats.app/ news/41925c613b2ced0ee117c89fcee7e6729a8466e0fe8 394140f1493ff7376535a User-Solana-wallet-exploited- in-first-case-of-AI-poisoning-attack/

    work page 2024

  7. [7]

    Github copilot ai pair program- mer: Asset or liability? Journal of Systems and Software, 203:111734, 2023

    Arghavan Moradi Dakhel, Vahid Majdinasab, Amin Nikanjam, Foutse Khomh, Michel C Desmarais, and Zhen Ming Jack Jiang. Github copilot ai pair program- mer: Asset or liability? Journal of Systems and Software, 203:111734, 2023

    work page 2023

  8. [8]

    bitsandbytes

    Tim Dettmers. bitsandbytes. https://github.com/TimDett mers/bitsandbytes, 2024

    work page 2024

Show all 59 references
  1. [9]

    The robots are coming: Exploring the implications of openai codex on introductory programming

    James Finnie-Ansley, Paul Denny, Brett A Becker, An- drew Luxton-Reilly, and James Prather. The robots are coming: Exploring the implications of openai codex on introductory programming. In Proceedings of the 24th Australasian Computing Education Conference , pages 10–19, 2022

    2022

  2. [10]

    Gptq: Accurate post-training quantization for generative pre-trained transformers

    Elias Frantar, Saleh Ashkboos, Torsten Hoefler, and Dan Alistarh. Gptq: Accurate post-training quantization for generative pre-trained transformers. arXiv preprint arXiv:2210.17323, 2022

    2022 arXiv

  3. [11]

    Github copilot

    GitHub. Github copilot. https://github.com/features/copi lot. Accessed: 2023-10-30

    2023

  4. [12]

    How many of all bugs do we find? a study of static bug detectors

    Andrew Habib and Michael Pradel. How many of all bugs do we find? a study of static bug detectors. In Proceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering , pages 317–328, 2018

    2018

  5. [13]

    An empirical study of code smells in transformer-based code generation techniques , 2022. IEEE

    2022

  6. [14]

    Baseline defenses for adversarial attacks against aligned language models

    Neel Jain, Avi Schwarzschild, Yuxin Wen, Gowthami Somepalli, John Kirchenbauer, Ping-yeh Chiang, Micah Goldblum, Aniruddha Saha, Jonas Geiping, and Tom Goldstein. Baseline defenses for adversarial attacks against aligned language models. arXiv preprint arXiv:2309.00614, 2023

    2023 arXiv

  7. [15]

    Albert Q. Jiang, Alexandre Sablayrolles, Arthur Mensch, Chris Bamford, Devendra Singh Chaplot, Diego de las Casas, Florian Bressand, Gianna Lengyel, Guillaume Lample, Lucile Saulnier, L ´elio Renard Lavaud, Marie- Anne Lachaux, Pierre Stock, Teven Le Scao, Thibaut Lavril, Thom...

    2023

  8. [16]

    Llm security guard for code

    Arya Kavian, Mohammad Mehdi Pourhashem Kalle- hbasti, Sajjad Kazemi, Ehsan Firouzi, and Mohammad Ghafari. Llm security guard for code. In Proceedings of the 28th International Conference on Evaluation and Assessment in Software Engineering , pages 600–603, 2024

    2024

  9. [17]

    Stackexchange, 2024

    LangChain. Stackexchange, 2024. URL https://python.l angchain.com/v0.2/docs/integrations/tools/stackexchang e/

    2024

  10. [18]

    Chatgpt as an attack tool: Stealthy textual backdoor attack via blackbox generative model trigger

    Jiazhao Li, Yijin Yang, Zhuofeng Wu, VG Vydiswaran, and Chaowei Xiao. Chatgpt as an attack tool: Stealthy textual backdoor attack via blackbox generative model trigger. arXiv preprint arXiv:2304.14475 , 2023

    2023 arXiv

  11. [19]

    Mankowitz, Esme Sutherland Robson, Push- meet Kohli, Nando de Freitas, Koray Kavukcuoglu, and Oriol Vinyals

    Yujia Li, David Choi, Junyoung Chung, Nate Kushman, Julian Schrittwieser, R ´emi Leblond, Tom Eccles, James Keeling, Felix Gimeno, Agustin Dal Lago, Thomas Hu- bert, Peter Choy, Cyprien de Masson d’Autume, Igor Babuschkin, Xinyun Chen, Po-Sen Huang, Johannes Welbl, Sven Gowal,...

  12. [20]

    Is your code generated by chatgpt really correct? rigorous evaluation of large language models for code generation

    Jiawei Liu, Chunqiu Steven Xia, Yuyao Wang, and Ling- ming Zhang. Is your code generated by chatgpt really correct? rigorous evaluation of large language models for code generation. Advances in Neural Information Processing Systems, 36, 2024

    2024

  13. [21]

    No need to lift a finger anymore? JOURNAL OF LATEX CLASS FILES, VOL

    Zhijie Liu, Yutian Tang, Xiapu Luo, Yuming Zhou, and Liang Feng Zhang. No need to lift a finger anymore? JOURNAL OF LATEX CLASS FILES, VOL. 18, NO. 9, SEPTEMBER 2020 13 assessing the quality of code generation by chatgpt. IEEE Transactions on Software Engineering , 2024

    2020

  14. [22]

    Starcoder 2 and the stack v2: The next generation, 2024

    Anton Lozhkov, Raymond Li, Loubna Ben Allal, Fed- erico Cassano, Joel Lamy-Poirier, Nouamane Tazi, Ao Tang, Dmytro Pykhtar, Jiawei Liu, Yuxiang Wei, Tianyang Liu, Max Tian, Denis Kocetkov, Arthur Zucker, Younes Belkada, Zijian Wang, Qian Liu, Dmitry Ab- ulkhanov, Indraneil Pau...

    2024

  15. [23]

    Reinventing search with a new ai-powered microsoft bing and edge, your copilot for the web

    Yusuf Mehdi. Reinventing search with a new ai-powered microsoft bing and edge, your copilot for the web. https: //blogs.microsoft.com/blog/2023/02/07/reinventing-sear ch-with-a-new-ai-powered-microsoft-bing-and-edge-y our-copilot-for-the-web/, 2023

    2023

  16. [24]

    Common weakness enumeration

    Mitre. Common weakness enumeration. https://cwe.mi tre.org/, 2024

    2024

  17. [25]

    ai-agent-scaffold, 2024

    mugglmenzel. ai-agent-scaffold, 2024. URL https://gith ub.com/mugglmenzel/ai-agent-scaffold

    2024

  18. [26]

    An empirical evaluation of github copilot’s code suggestions

    Nhan Nguyen and Sarah Nadi. An empirical evaluation of github copilot’s code suggestions. In Proceedings of the 19th International Conference on Mining Software Repositories, pages 1–5, 2022

    2022

  19. [27]

    LEVER: Learning to verify language-to-code generation with execution

    Ansong Ni, Srini Iyer, Dragomir Radev, Veselin Stoy- anov, Wen-Tau Yih, Sida Wang, and Xi Victoria Lin. LEVER: Learning to verify language-to-code generation with execution. In Proceedings of the 40th Interna- tional Conference on Machine Learning , volume 202 of Proceedings o...

    2023

  20. [28]

    Codegen: An open large language model for code with multi-turn program synthesis

    Erik Nijkamp, Bo Pang, Hiroaki Hayashi, Lifu Tu, Huan Wang, Yingbo Zhou, Silvio Savarese, and Caiming Xiong. Codegen: An open large language model for code with multi-turn program synthesis. In The Eleventh Inter- national Conference on Learning Representations, ICLR 2023, Kig...

    2023

  21. [29]

    Autosafecoder: A multi-agent framework for securing llm code generation through static analysis and fuzz testing

    Ana Nunez, Nafis Tanveer Islam, Sumit Kumar Jha, and Peyman Najafirad. Autosafecoder: A multi-agent framework for securing llm code generation through static analysis and fuzz testing. arXiv preprint arXiv:2409.10737, 2024

    2024 arXiv

  22. [30]

    OpenAI. Chatgpt. https://openai.com/blog/chatgpt, 2022

    2022

  23. [31]

    Llm is like a box of chocolates: the non- determinism of chatgpt in code generation

    Shuyin Ouyang, Jie M Zhang, Mark Harman, and Meng Wang. Llm is like a box of chocolates: the non- determinism of chatgpt in code generation. arXiv preprint arXiv:2308.02828, 2023

    2023 arXiv

  24. [32]

    Asleep at the keyboard? assessing the security of github copilot’s code contributions

    Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Bren- dan Dolan-Gavitt, and Ramesh Karri. Asleep at the keyboard? assessing the security of github copilot’s code contributions. In 2022 IEEE Symposium on Security and Privacy (SP), pages 754–768. IEEE, 2022

    2022

  25. [33]

    Do users write more insecure code with ai assistants? In Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security , pages 2785–2799, 2023

    Neil Perry, Megha Srivastava, Deepak Kumar, and Dan Boneh. Do users write more insecure code with ai assistants? In Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security , pages 2785–2799, 2023

    2023

  26. [34]

    Universal jail- break backdoors from poisoned human feedback

    Javier Rando and Florian Tram `er. Universal jail- break backdoors from poisoned human feedback. arXiv preprint arXiv:2311.14455, 2023

    2023 arXiv

  27. [35]

    Code llama: Open foundation models for code

    Baptiste Roziere, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Tal Remez, J ´er´emy Rapin, et al. Code llama: Open foundation models for code. arXiv preprint arXiv:2308.12950, 2023

    2023 arXiv

  28. [36]

    Lost at c: A user study on the security implications of large language model code assistants

    Gustavo Sandoval, Hammond Pearce, Teo Nys, Ramesh Karri, Siddharth Garg, and Brendan Dolan-Gavitt. Lost at c: A user study on the security implications of large language model code assistants. In 32nd USENIX Secu- rity Symposium (USENIX Security 23), pages 2205–2222, 2023

    2023

  29. [37]

    Automatic generation of programming exercises and code explanations using large language models

    Sami Sarsa, Paul Denny, Arto Hellas, and Juho Leinonen. Automatic generation of programming exercises and code explanations using large language models. In Pro- ceedings of the 2022 ACM Conference on International Computing Education Research-Volume 1 , pages 27–43, 2022

    2022

  30. [38]

    A brief review on search engine optimization

    Dushyant Sharma, Rishabh Shukla, Anil Kumar Giri, and Sumit Kumar. A brief review on search engine optimization. In 2019 9th international conference on cloud computing, data science & engineering (conflu- ence), pages 687–692. IEEE, 2019

    2019

  31. [39]

    Generate and pray: Using sallms to evaluate the security of llm generated code

    Mohammed Latif Siddiq and Joanna Santos. Generate and pray: Using sallms to evaluate the security of llm generated code. arXiv preprint arXiv:2311.00889, 2023

    2023 arXiv

  32. [40]

    Securi- tyeval dataset: mining vulnerability examples to evaluate machine learning-based code generation techniques

    Mohammed Latif Siddiq and Joanna CS Santos. Securi- tyeval dataset: mining vulnerability examples to evaluate machine learning-based code generation techniques. In Proceedings of the 1st International Workshop on Min- ing Software Repositories Applications for Privacy and Secu...

    2022

  33. [41]

    Sallm: Security assessment of generated code

    Mohammed Latif Siddiq, Joanna Cecilia da Silva Santos, Sajith Devareddy, and Anna Muller. Sallm: Security assessment of generated code. In Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering Workshops, pages 54–65, 2024

    2024

  34. [42]

    DIRA: automatic detection, identification and repair of control-hijacking attacks

    Alexey Smirnov and Tzi-cker Chiueh. DIRA: automatic detection, identification and repair of control-hijacking attacks. In Proceedings of the Network and Distributed System Security Symposium, NDSS 2005, San Diego, California, USA. The Internet Society, 2005

    2005

  35. [43]

    JOURNAL OF LATEX CLASS FILES, VOL

    Dominik Sobania, Martin Briesch, and Franz Rothlauf. JOURNAL OF LATEX CLASS FILES, VOL. 18, NO. 9, SEPTEMBER 2020 14 Choose your programming copilot: a comparison of the program synthesis performance of github copilot and genetic programming. In Proceedings of the genetic and ...

    2020

  36. [44]

    Arks: Active retrieval in knowledge soup for code generation

    Hongjin Su, Shuyang Jiang, Yuhang Lai, Haoyuan Wu, Boao Shi, Che Liu, Qian Liu, and Tao Yu. Arks: Active retrieval in knowledge soup for code generation. arXiv preprint arXiv:2402.12317, 2024

    2024 arXiv

  37. [45]

    Is chatgpt the ultimate programming assistant–how far is it? arXiv preprint arXiv:2304.11938 , 2023

    Haoye Tian, Weiqi Lu, Tsz On Li, Xunzhu Tang, Shing- Chi Cheung, Jacques Klein, and Tegawend´e F Bissyand´e. Is chatgpt the ultimate programming assistant–how far is it? arXiv preprint arXiv:2304.11938 , 2023

    2023 arXiv

  38. [46]

    Llama: Open and efficient foundation language models, 2023

    Hugo Touvron, Thibaut Lavril, Gautier Izacard, Xavier Martinet, Marie-Anne Lachaux, Timoth ´ee Lacroix, Bap- tiste Rozi`ere, Naman Goyal, Eric Hambro, Faisal Azhar, Aurelien Rodriguez, Armand Joulin, Edouard Grave, and Guillaume Lample. Llama: Open and efficient foundation lan...

    2023

  39. [47]

    Expectation vs

    Priyan Vaithilingam, Tianyi Zhang, and Elena L Glass- man. Expectation vs. experience: Evaluating the usability of code generation tools powered by large language mod- els. In Chi conference on human factors in computing systems extended abstracts , pages 1–7, 2022

    2022

  40. [48]

    Memory errors: The past, the present, and the future

    Victor Van der Veen, Nitish Dutt-Sharma, Lorenzo Cav- allaro, and Herbert Bos. Memory errors: The past, the present, and the future. In Research in Attacks, Intrusions, and Defenses: 15th International Symposium, RAID 2012, Amsterdam, The Netherlands, September 12- 14, 2012. P...

    2012

  41. [49]

    Freshllms: Refreshing large language models with search engine augmentation

    Tu Vu, Mohit Iyyer, Xuezhi Wang, Noah Constant, Jerry Wei, Jason Wei, Chris Tar, Yun-Hsuan Sung, Denny Zhou, Quoc Le, et al. Freshllms: Refreshing large language models with search engine augmentation. arXiv preprint arXiv:2310.03214, 2023

    arXiv

  42. [50]

    De- ceptprompt: Exploiting llm-driven code generation via adversarial natural language instructions

    Fangzhou Wu, Xiaogeng Liu, and Chaowei Xiao. De- ceptprompt: Exploiting llm-driven code generation via adversarial natural language instructions. arXiv preprint arXiv:2312.04730, 2023

    2023 arXiv

  43. [51]

    Aios compiler: Llm as interpreter for natural language programming and flow programming of ai agents, 2024

    Shuyuan Xu, Zelong Li, Kai Mei, and Yongfeng Zhang. Aios compiler: Llm as interpreter for natural language programming and flow programming of ai agents, 2024

    2024

  44. [52]

    Aligning llms through multi-perspective user preference ranking-based feedback for programming question an- swering, 2024

    Hongyu Yang, Liyang He, Min Hou, Shuanghong Shen, Rui Li, Jiahui Hou, Jianhui Ma, and Junda Zhao. Aligning llms through multi-perspective user preference ranking-based feedback for programming question an- swering, 2024

    2024

  45. [53]

    Watch out for your agents! inves- tigating backdoor threats to llm-based agents

    Wenkai Yang, Xiaohan Bi, Yankai Lin, Sishuo Chen, Jie Zhou, and Xu Sun. Watch out for your agents! inves- tigating backdoor threats to llm-based agents. CoRR, abs/2402.11208, 2024. doi: 10.48550/ARXIV.2402.11

    2024 doi arXiv

  46. [54]

    Fuzzllm: A novel and universal fuzzing frame- work for proactively discovering jailbreak vulnerabilities in large language models

    Dongyu Yao, Jianshu Zhang, Ian G Harris, and Marcel Carlsson. Fuzzllm: A novel and universal fuzzing frame- work for proactively discovering jailbreak vulnerabilities in large language models. In ICASSP 2024-2024 IEEE International Conference on Acoustics, Speech and Sig- nal ...

    2024

  47. [55]

    Large language models are better adversaries: Explor- ing generative clean-label backdoor attacks against text classifiers

    Wencong You, Zayd Hammoudeh, and Daniel Lowd. Large language models are better adversaries: Explor- ing generative clean-label backdoor attacks against text classifiers. arXiv preprint arXiv:2310.18603 , 2023

    2023 arXiv

  48. [56]

    Universal and transferable adversarial at- tacks on aligned language models

    Andy Zou, Zifan Wang, J Zico Kolter, and Matt Fredrikson. Universal and transferable adversarial at- tacks on aligned language models. arXiv preprint arXiv:2307.15043, 2023

    2023 arXiv

  49. [208]

    URL https://doi.org/10.48550/arXiv.2402.11208

    doi arXiv

  50. [2022]

    doi: 10.1126/science.abq1158

    ISSN 1095-9203. doi: 10.1126/science.abq1158. URL http://dx.doi.org/10.1126/science.abq1158

    doi

  51. [2023]

    URL https://openreview.net/forum?id=iaYcJKpY 2B

Pith tools

Reviewed August 16, 2026 · model on record in the stance chip above.