LLM long-term memory bakes in insecure coding defaults
New research shows long-term memory in code-generating LLMs can embed insecure coding preferences that silently increase vulnerabilities across languages. Vulnerability rates jump by 2.7–50.3 percentage points, warnings lag, and memories resist overwrites. Mitigations help but can hurt correctness, while a memory-level safety filter flags risky entries and restores baseline behaviour in tests.
Personalised Large Language Model (LLM) coders now remember your preferences across sessions. That convenience comes with a security bill: once the assistant stores an insecure preference, it keeps using it, quietly, long after you have forgotten you set it. This is not prompt-injection theatre. It is your own tool baking in bad defaults.
A systematic study across four memory-enabled systems — ChatGPT (GPT-4o), Gemini (Gemini-2.5 Flash), Qwen (Qwen-3.5-Plus) and Grok (Grok-4.2) — finds that insecure long-term memories push vulnerability rates up by 2.7 to 50.3 percentage points, across Python, C, C++, Go and JavaScript. On Python tasks alone, average increases were 13.8 points for ChatGPT, 11.3 for Gemini, 2.7 for Qwen and 4.7 for Grok. The authors tested on SALLM (100 Python tasks across 45 CWE types) and the non-Python subset of CWEval (94 tasks across 31 CWE types), seeding memory with CWE-aligned bad preferences.
The failures are not narrowly scoped. Long-term memory broadened the range of Common Weakness Enumerations that appeared, with new hits clustering around cryptography, key management and TLS configuration. Worse, the models did not reliably raise flags as they got less safe: warning rates trailed vulnerability increases by 5.4 to 14.0 points. Disclosure was rare. ChatGPT explicitly referenced its memory in 2.3% of cases; Gemini in 10.3%.
Overwriting bad memories was harder than it should be. Simple pattern swaps and partial updates did nothing (0% success). Directly contradicting the stored preference worked in ChatGPT (100% success) and failed in Gemini (0%). Paraphrasing the task did not help you dodge the landmine either: in tested cases, vulnerability at k=3 stayed at 100% under paraphrased prompts, showing broad retrieval beyond exact wording.
Mitigations are a mixed bag. Appending security requirements to prompts or storing them as memory cut vulnerability by 19.7 to 33.6 points, but also knocked functional correctness by up to 15.9 points. A memory-level safety filter — an LLM-based gate that screens entries before storage — caught 100% of the risky memories they evaluated and restored behaviour to the no-memory baseline, taking about 1.53s and 2.90s per entry for two variants.
Does this matter? Yes, because the attack surface here does not need an attacker. An ordinary developer can teach the assistant an unsafe habit once, and the habit spreads across projects and prompts without obvious warnings. Caveats apply: four commercial models, specific dates, two benchmarks, and a filter that is perfect only on their dataset. But the core finding stands: persistent, covert value drift from memory is real and measurable. If you ship memory, you inherit that risk.
Additional analysis of the original ArXiv paper
📋 Original Paper Title and Abstract
Insecure Coding Preferences in Long-Term Memory: Security Risks for LLM-based Code Generation
🔍 ShortSpan Analysis of the Paper
Problem
This paper studies how explicit long-term memory in LLM-based assistants can store insecure coding preferences and then silently steer subsequent code generation toward vulnerable implementations. This matters because many deployed assistants now preserve user or project preferences across sessions, so accidental or temporary insecure choices made during development can persist and broaden the exposure to security weaknesses.
Approach
The authors run a systematic empirical evaluation on four memory-enabled LLM systems: ChatGPT (GPT-4o), Gemini (Gemini-2.5 Flash), Qwen (Qwen-3.5-Plus) and Grok (Grok-4.2). They use two benchmarks: SALLM (100 Python tasks covering 45 CWE types) and the non-Python subset of CWEval (94 tasks across C, C++, Go and JavaScript covering 31 CWE types). For each task they construct memory prompts that encode CWE-aligned insecure preferences, inject these as long-term memory entries, and compare code generation under with-memory and without-memory conditions. Outputs are evaluated by unit tests for functional correctness (Pass@k) and for vulnerabilities (Vul@k), and by human annotation for security warnings and explicit memory references. They test persistence, paraphrase robustness, overwrite attempts, and three mitigations: appending security requirements to prompts, storing security-requirement memory, and a memory-level safety filter implemented with LLM-based detectors.
Key Findings
- Insecure memories raise vulnerability rates substantially, with increases ranging 2.7 to 50.3 percentage points across models and languages; on Python average Vul@k rises by 13.8 pp for ChatGPT, 11.3 pp for Gemini, 2.7 pp for Qwen and 4.7 pp for Grok.
- Long-term memory broadens CWE coverage: covered CWE types increase from 31 to 36 39 across the four models, with new weaknesses concentrated in encryption and key management and TLS configuration.
- Safety-aligned behaviour weakens covertly: warning-rate increases lag vulnerability increases by 5.4 to 14.0 percentage points, and models rarely disclose memory influence (memory-reference rates 2.3% for ChatGPT and 10.3% for Gemini).
- Injected memories are persistent and hard to overwrite: simple pattern replacements and partial updates fail to overwrite (0% success), contradictory updates overwrite only in ChatGPT (100% success) but not Gemini (0% success).
- Memory influence generalises across paraphrased prompts; in the tested cases Vul@3 remained 100% under paraphrases, showing broad retrieval beyond exact phrasing.
- Mitigations: appending or storing explicit security requirements reduces vulnerability rates by 19.7 33.6 pp but can degrade functional correctness by up to 15.9 pp; a memory-level safety filter achieved 100% detection on evaluated risky entries and restored behaviour to the without-memory baseline, with detection times of about 1.53s and 2.90s per entry for two filter variants.
Limitations
Evaluation is limited to four commercial LLMs during specific date windows and to two benchmark suites; model behaviour and memory implementations may change over time. Human annotation of warnings and memory references could introduce subjectivity, though inter-annotator agreement was high. Randomness in generation is mitigated by sampling and unbiased estimators but remains a factor. Results reflect non-adversarial storage of preferences rather than malicious access to memory stores.
Implications
An attacker need not be present: an ordinary developer storing an insecure preference can create a persistent covert attack surface that repeatedly steers assistants to vulnerable code across sessions and prompts. The persistence, low disclosure rate and resistance to simple updates mean these insecure memories can silently widen attack surfaces, especially around cryptography and TLS. Memory-level filtering that blocks risky preferences before storage is a practical offensive risk to avoid, while adversaries could try to induce developers to store unsafe preferences to achieve long-term compromise of generated code.
