The Pulse
NameTrap Shows How Variable Names Can Steer Coding Agents Into Bugs
A paper submitted to arXiv on October 25 describes NameTrap, an attack that changes identifiers in Python files to influence AI coding agents. Across six agents, the researchers measured targeted vulnerability rates of 22.5% to 56%, with re
AI.info Team · Written with AI · fact-checked ·
Renaming variables should not change what a program does. But in experiments described in a paper submitted to arXiv on October 25, identifier changes in ordinary Python files nudged coding agents toward writing code with specific security weaknesses. The researchers’ NameTrap attack adds no malicious instructions or vulnerable code to the files: it relies on names that influence how an agent interprets incomplete code.
The result puts two views of a code file in tension. For a conventional program, a consistent identifier rename can preserve behavior; for a coding agent completing that program, the renamed identifiers can change the cues used to decide what code belongs next. The researchers write: “We show that this Web-borne context can be weaponized without any explicit instruction.” Chieh-Yuan Chang et al., authors of “NameTrap: Steering AI Coding Agents Toward Security Vulnerabilities via Variable Names”
NameTrap leaves the vulnerable code unwritten
The researchers tested the technique on 200 incomplete Python files drawn from 31 projects among GitHub’s 100 most-starred projects. They first screened the files: for a file to serve as a clean baseline, none of ten completion attempts could produce the targeted weakness. The test covered six coding agents, ten underlying language models and four Common Weakness Enumeration categories: operating-system command injection, cross-site scripting, risky cryptography and unsafe deserialization.
To create bait, an attacker-side agent changes identifiers to suggest a convention associated with a chosen weakness. Names can, for example, imply that data is trusted or that compatibility calls for a fast digest. A separate probe session asks an agent to complete the altered file, then checks the result with Bandit and Semgrep. If neither scanner flags the target weakness, the attacker can try another renaming pass; the released file is the renamed, still-incomplete code, not the vulnerable completion.
Success rates depended on the agent and model
Across the six coding agents, NameTrap’s overall attack success rates ranged from 22.5% to 56.0%, compared with lower overall rates for the study’s random-renaming, neutral-renaming and XOXO comparison conditions. Aider recorded the highest overall rate, 56.0%, while OpenHands recorded 22.5%. In particular agent-and-model combinations, the paper reports a rate as high as 75.0%.
Those figures describe controlled completion experiments, not confirmed attacks on deployed software. An attempt counted as successful when the generated code contained a targeted weakness reported at medium severity or higher by Bandit or Semgrep. The authors also found substantial variation across models and frameworks: the same model reached different rates in different agents, and some combinations produced no qualifying bait.
Renamed files evaded checks aimed at existing bugs
The researchers say NameTrap remained effective with Traditional Chinese prompts and that some bait transferred between models. The effect was not uniform: transfer rates differed across model pairs, and some produced no successful attacks. A security reminder also failed to consistently prevent the targeted weakness from appearing in generated code.
Three AI-based security analyzers and four static analyzers did not flag the targeted weaknesses in the poisoned source files. That result has a specific boundary: the bait files contained no targeted vulnerable statements to detect. The vulnerability appeared only after a separate agent completed the code, so checks of the finished change address a different stage than checks of the file the agent initially reads.
The paper points to checks on generated changes
The authors recommend treating identifiers in third-party code as untrusted input rather than as specifications, running security analysis on agent-generated changes before committing them, and recording which external files influenced each edit. Those steps focus review on the code the agent produces and on the context behind it, rather than assuming that a harmless-looking source file cannot affect a later implementation.
NameTrap’s central distinction is between changing a program’s behavior and changing an agent’s interpretation of it. In the experiments, renaming alone left the source file’s existing functionality intact; the security weakness appeared in the code the agent wrote afterward.