mlsanityData to 7 Oct 2026

Willing but Unable: Separating Refusal from Capability in Code LLMs via Abliteration

arXiv 2606.05396 ↗First posted 3 Jun 2026cs.CR cs.AI cs.SEcited by 0

Not on the map. Why?

Abstract (arXiv)

Producing a labeled vulnerable code at scale is a recurring obstacle for learning-based vulnerability detection: mined corpora carry substantial label noise, and existing LLM-based augmentation propagates these inaccuracies because it transforms vulnerable seeds rather than synthesising vulnerabilities from a specification. A complementary route is to start from safe code and ask an instruction-tuned LLM to inject a specified CWE (which would shift the labeling burden from open-ended detection to bounded binary confirmation) but safety-aligned code LLMs systematically refuse such prompts. This paper is a preliminary feasibility study of abliteration, a low-rank weight edit that orthogonally projects out the refusal direction in the residual stream, as a tool to remove this barrier. We use Python and CWE-89 (SQL injection) as a case study, evaluating the Qwen2.5-Coder-Instruct family at 3B, 7B, and 14B parameters on safe samples drawn from PromSec and SafeCoder, replicated three times per condition. We find that (i) refusal on injection prompts is strongly size- and prompt-context-dependent: the 14B refuses 100% of prompts, the 7B refuses 73% of PromSec but only 5% of SafeCoder, whereas the 3B is essentially never blocked; (ii) abliteration reduces refusal to zero or near-zero across all sizes while leaving syntactic validity above 93%, supporting the view that, in this setting, refusal can be detached from measured code-generation capability; and (iii) the post-abliteration injection rate remains capacity-bound (88-97% on the 14B, 89-90% on the 7B, and 25-48% on the 3B) separating willingness, which abliteration unlocks, from capability, which scales with parameters. Vulnerability verdicts are produced by a three-tool detector ensemble (CodeQL, Semgrep, Bandit) followed by manual adjudication by two authors on detector-positive outputs.

Key facts. No citing papers in the map yet (data through 7 Oct 2026). Builds on 15 of its 24 references that are in the map. First posted on arXiv 3 Jun 2026.

Builds on

15 of 24 references.

References · 15

  1. 2024Qwen2.5-Coder Technical Reportcited by 1,151
  2. 2024Refusal in Language Models Is Mediated by a Single Directioncited by 960
  3. 2019Devign: Effective Vulnerability Identification by Learning Comprehensive Program Semantics via Graph Neural Networkscited by 266
  4. 2023Large Language Models for Code: Security Hardening and Adversarial Testingcited by 149
  5. 2020Deep Learning based Vulnerability Detection: Are We There Yet?cited by 142
  6. 2023Data Quality for Software Vulnerability Datasetscited by 49
  7. 2025LLMs in Software Security: A Survey of Vulnerability Detection Techniques and Insightscited by 44
  8. 2024PromSec: Prompt Optimization for Secure Generation of Functional Source Code with Large Language Models (LLMs)cited by 17
  9. 2021Shellcode_IA32: A Dataset for Automatic Shellcode Generationcited by 16
  10. 2021EVIL: Exploiting Software via Natural Languagecited by 11
  11. 2023VGX: Large-Scale Sample Generation for Boosting Learning-Based Software Vulnerability Analysescited by 9
  12. 2024VulScribeR: Exploring RAG-based Vulnerability Augmentation with LLMscited by 7
3 more
  1. 2024The Power of Words: Generating PowerShell Attacks from Natural Languagecited by 3
  2. 2024Enhancing AI-based Generation of Software Exploits with Contextual Informationcited by 3
  3. 2024AI Code Generators for Security: Friend or Foe?cited by 2

Built on by

Not cited yet.