Pith. sign in

REVIEW 1 major objections 2 minor 26 references

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

T0 review · 1 major / 2 minor · reviewed 2026-06-28 · grok-4.3

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

Pith's one-line read Abliteration projects out the refusal direction in code LLMs, detaching willingness to generate vulnerable code from capacity that scales with model size.

desk verdict Abliteration strips refusal from these code models for CWE-89 prompts while syntactic output stays intact, and the post-edit injection rate scales with size, but the detector pipeline lacks the checks needed to make the capacity-bound claim solid. read the letter →

arxiv 2606.05396 v1 pith:UQHTWSVD submitted 2026-06-03 cs.CR cs.AIcs.SE

Cristina Carleo , Pietro Liguori , Naghmeh Ivaki , Domenico Cotroneo This is my paper
classification cs.CRcs.AIcs.SE
keywords abliterationcodeLLMsrefusalvulnerabilityinjectionSQLCWE-89safetyalignmentparameterscaling
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

The paper tests whether abliteration, a low-rank weight edit, can remove refusal in safety-aligned code LLMs asked to inject specified vulnerabilities such as SQL injection into safe Python code. Refusal drops to zero or near zero across the 3B, 7B, and 14B Qwen2.5-Coder models while syntactic validity stays above 93 percent. After the edit, the rate of actual successful injections rises with model size, reaching 88-97 percent on the largest model. This pattern holds on safe samples from PromSec and SafeCoder and separates the unlocked willingness to attempt the task from the capability that remains size-dependent. The approach shifts labeling effort from open-ended detection to bounded confirmation of a specified CWE.

What carries the argument

Abliteration: a low-rank weight edit that orthogonally projects out the refusal direction in the residual stream.

What would settle it

An independent count of successful injections on the same prompts that shows either no increase with model size or syntactic validity below 93 percent after abliteration.

Watch

Extended reading notes

Core claim

Abliteration is a low-rank weight edit that orthogonally projects out the refusal direction in the residual stream. When applied to the Qwen2.5-Coder-Instruct family, it reduces refusal on injection prompts to zero or near-zero across all tested sizes while syntactic validity remains above 93 percent. Post-abliteration injection success, measured by a three-tool detector ensemble plus manual review, stays capacity-bound at 88-97 percent for the 14B model, 89-90 percent for the 7B model, and 25-48 percent for the 3B model.

Load-bearing premise

The three-tool detector ensemble followed by manual adjudication accurately measures true injection success rates without substantial undetected cases or false positives that would change the capacity-bound scaling.

Editorial extensions

If this is right

  • Refusal can be removed from code LLMs without collapsing their ability to produce syntactically valid code.
  • Successful vulnerability injection after abliteration increases with parameter count.
  • Starting from safe code and specifying a CWE allows creation of labeled vulnerable examples whose correctness can be checked by binary confirmation.
  • The separation shows that willingness and capability are distinct in this refusal setting.

Reading between the lines

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

  • The same edit might unlock other controlled code-generation tasks that current alignment blocks.
  • If the detector remains reliable, the method supports building balanced datasets of vulnerable and safe code at scale.
  • Lower success on the 3B model indicates that capability gains beyond refusal removal are still required for smaller models.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

1 major / 2 minor

Summary. The manuscript claims that abliteration, a low-rank weight edit that orthogonally projects out the refusal direction in the residual stream, can eliminate refusal in code LLMs for CWE-89 (SQL injection) prompts while preserving syntactic validity above 93%. On the Qwen2.5-Coder-Instruct family (3B/7B/14B), with three replicates per condition on PromSec and SafeCoder safe samples, it reports pre-abliteration refusal rates that are size- and context-dependent, post-abliteration refusal near zero, and post-abliteration injection success rates (via CodeQL/Semgrep/Bandit ensemble plus two-author manual review of positives) that scale with size: 88-97% (14B), 89-90% (7B), 25-48% (3B). This is interpreted as separating willingness (unlocked by abliteration) from capability (capacity-bound).

Significance. If the detector pipeline reliably measures true injection success, the result supplies direct empirical evidence that refusal can be detached from code-generation capability via a targeted low-rank edit, with the size-dependent post-edit rates offering a concrete demonstration that capability, not willingness, limits performance on this task. The replicated design across three scales strengthens the feasibility claim for using abliteration to generate labeled vulnerable code from safe seeds.

major comments (1)
  1. [Abstract] Abstract: The headline capacity-bound scaling claim (88-97% on 14B, 89-90% on 7B, 25-48% on 3B) rests entirely on the three-tool detector ensemble plus manual adjudication correctly classifying actual SQL-injection vulnerabilities. No precision/recall figures, inter-rater reliability, adjudication rubric, or validation set are supplied; differential false-positive rates across model sizes (larger models produce longer/more varied code) could artifactually generate the observed scaling and thereby undermine the separation of refusal from capability.
minor comments (2)
  1. [Abstract] Abstract: Exact prompt templates for the injection requests, the procedure for identifying the refusal direction, and the rank and implementation details of the low-rank edit are not provided.
  2. [Abstract] Abstract: No statistical tests, confidence intervals, or variance measures across the three replicates are reported for the refusal and injection percentages.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the constructive feedback on the reliability of our vulnerability detection pipeline. This is a substantive concern for interpreting the capacity-bound scaling results. We address the point below and will revise the manuscript to incorporate additional validation details.

read point-by-point responses

  1. Referee: [Abstract] Abstract: The headline capacity-bound scaling claim (88-97% on 14B, 89-90% on 7B, 25-48% on 3B) rests entirely on the three-tool detector ensemble plus manual adjudication correctly classifying actual SQL-injection vulnerabilities. No precision/recall figures, inter-rater reliability, adjudication rubric, or validation set are supplied; differential false-positive rates across model sizes (larger models produce longer/more varied code) could artifactually generate the observed scaling and thereby undermine the separation of refusal from capability.

    Authors: We agree this is a valid limitation of the current manuscript. The pipeline combines three standard static-analysis tools (CodeQL, Semgrep, Bandit) with two-author manual review of all detector-positive outputs, but we did not supply precision/recall on a held-out validation set of LLM-generated code, inter-rater reliability statistics, or an explicit adjudication rubric. Differential false-positive rates by model size are a plausible concern. In the revised manuscript we will (1) add an appendix with the full adjudication rubric, (2) report Cohen’s kappa between the two reviewers, and (3) include a short discussion of possible size-dependent biases in generated code length and structure. We will also flag the absence of a dedicated validation set as a limitation of this preliminary feasibility study. These changes directly address the referee’s concern while preserving the core experimental design. revision: yes

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: purely empirical measurements with no derived predictions or self-referential definitions

full rationale

The paper reports direct empirical observations of refusal rates, syntactic validity, and post-abliteration injection success rates on held-out safe code samples from PromSec and SafeCoder, evaluated via a detector ensemble plus manual review. All key results (e.g., 100% refusal on 14B pre-abliteration, 88-97% injection on 14B post-abliteration) are measured quantities rather than outputs of any equation, fit, or derivation that reduces to the inputs by construction. No self-citations, uniqueness theorems, or ansatzes are invoked as load-bearing steps in the provided text; the separation of willingness from capability is presented as an observed scaling pattern across model sizes.

Assumptions & free parameters 0 free parameters · 2 assumptions · 1 invented entities

The central claim rests on the effectiveness of the described low-rank refusal projection and on the accuracy of the vulnerability adjudication pipeline. No numerical free parameters are stated. The domain assumption that instruction-tuned models refuse such prompts is taken as given; the orthogonal-projection property of abliteration is introduced without independent verification in the abstract.

assumptions (2)
  • domain assumption Safety-aligned code LLMs systematically refuse prompts to inject specified CWEs into safe code
    Invoked as the barrier that abliteration is intended to remove.
  • ad hoc to paper A low-rank weight edit can orthogonally project out the refusal direction in the residual stream without destroying other generation capabilities
    This is the mechanistic premise of the abliteration technique as stated.
invented entities (1)
  • abliteration
    purpose: Low-rank edit to remove refusal direction
    The technique is presented as the enabling tool; no external falsifiable prediction or prior independent evidence is supplied in the abstract.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Willing but Unable: Separating Refusal from Capability in Code LLMs via Abliteration." pith.science (2026). https://pith.science/paper/UQHTWSVD

@misc{pith2026260605396,
  author       = {Pith},
  title        = {Pith review of: Willing but Unable: Separating Refusal from Capability in Code LLMs via Abliteration},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/UQHTWSVD}},
  note         = {Machine review of arXiv:2606.05396}
}
read the original abstract

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.

Figures

Figures reproduced from arXiv: 2606.05396 by the authors.

Figure 1
Figure 1. End-to-end pipeline. The same prompt is sent to the Base and Abliterated checkpoints of each Qwen2.5-Coder size. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Prompt template, with an example excerpt of the [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. CWE-89 injection example (14B abliterated, SafeCoder [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

26 extracted references · 7 canonical work pages

  1. [1]

    Juliet test suite for Java and C/C++ (nist software as- surance reference dataset),

    NIST, “Juliet test suite for Java and C/C++ (nist software as- surance reference dataset),” https://samate.nist.gov/SARD/, 2017, sARD: Software Assurance Reference Dataset

    2017

  2. [2]

    A C/C++ code vulnerability dataset with code changes and CVE summaries,

    J. Fan, Y. Li, S. Wang, and T. N. Nguyen, “A C/C++ code vulnerability dataset with code changes and CVE summaries,” inProceedings of the 17th International Conference on Mining Software Repositories (MSR), 2020, pp. 508–512

    2020

  3. [3]

    Devign: Effective vulnerability identification by learning compre- hensive program semantics via graph neural networks,

    Y. Zhou, S. Liu, J. Siow, X. Du, and Y. Liu, “Devign: Effective vulnerability identification by learning compre- hensive program semantics via graph neural networks,” inAdvances in Neural Information Processing Systems (NeurIPS), 2019

    2019

  4. [4]

    Deep learning based vulnerability detection: Are we there yet?

    S. Chakraborty, R. Krishna, Y. Ding, and B. Ray, “Deep learning based vulnerability detection: Are we there yet?” IEEE Transactions on Software Engineering, vol. 48, no. 9, pp. 3280–3296, 2022

    2022

  5. [5]

    Schorlemmer, Rohan Sethi, Yung-Hsiang Lu, George K

    R. Croft, M. A. Babar, and M. M. Kholoosi, “Data quality for software vulnerability datasets,” inProceedings of the 45th International Conference on Software Engineering, ser. ICSE ’23. IEEE Press, 2023, p. 121–133. [Online]. Available: https://doi.org/10.1109/ICSE48619.2023.00022

    work page doi:10.1109/icse48619.2023.00022 2023

  6. [6]

    Vulgen: Realistic vulnerability generation via pattern mining and deep learning,

    Y. Nong, Y. Ou, M. Pradel, F. Chen, and H. Cai, “Vulgen: Realistic vulnerability generation via pattern mining and deep learning,” in2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE), 2023, pp. 2527–2539

    2023

  7. [7]

    Vgx: Large-scale sample generation for boosting learning-based software vulnerability analyses,

    Y. Nong, R. Fang, G. Yi, K. Zhao, X. Luo, F. Chen, and H. Cai, “Vgx: Large-scale sample generation for boosting learning-based software vulnerability analyses,” inProceedings of the IEEE/ACM 46th International Conference on Software Engineering, ser. ICSE ’24. New York, NY, USA: Association for Computing Machinery,

  8. [8]

    Available: https://doi.org/10.1145/3597503

    [Online]. Available: https://doi.org/10.1145/3597503. 3639116

    work page doi:10.1145/3597503

Show all 26 references
  1. [9]

    VulScribeR: Exploring RAG-based vulnerability augmentation with LLMs,

    S. Daneshvaret al., “VulScribeR: Exploring RAG-based vulnerability augmentation with LLMs,”arXiv preprint arXiv:2408.04125, 2024

    2024

  2. [10]

    Llms in software security: A survey of vulnerability detection techniques and insights,

    Z. Sheng, Z. Chen, S. Gu, H. Huang, G. Gu, and J. Huang, “Llms in software security: A survey of vulnerability detection techniques and insights,”ACM Comput. Surv., vol. 58, no. 5, Nov. 2025. [Online]. Available: https://doi.org/10.1145/3769082

    2025 doi

  3. [11]

    Empirical analysis of security vulnerabilities in python packages,

    M. Alfadel, D. E. Costa, and E. Shihab, “Empirical analysis of security vulnerabilities in python packages,” Empirical Softw. Engg., vol. 28, no. 3, Mar. 2023. [Online]. Available: https://doi.org/10.1007/s10664-022-10278-4

    2023 doi

  4. [12]

    Secureqwen: Leveraging llms for vulnerability detection in python codebases,

    A. Mechri, M. A. Ferrag, and M. Debbah, “Secureqwen: Leveraging llms for vulnerability detection in python codebases,”Computers & Security, vol. 148, p. 104151,

  5. [13]

    Available: https://www.sciencedirect.com/ science/article/pii/S0167404824004565

    [Online]. Available: https://www.sciencedirect.com/ science/article/pii/S0167404824004565

  6. [14]

    PromSec: Prompt optimization for secure generation of functional source code with large language models,

    M. Nazzal, I. Khalil, A. Khreishah, and N. Phan, “PromSec: Prompt optimization for secure generation of functional source code with large language models,” inProceedings of the ACM SIGSAC Conference on Computer and Com- munications Security (CCS), 2024

    2024

  7. [15]

    Large language models for code: Security hardening and adversarial testing,

    J. He and M. Vechev, “Large language models for code: Security hardening and adversarial testing,” inProceed- ings of the ACM SIGSAC Conference on Computer and Communications Security (CCS), 2023, pp. 1865–1879

    2023

  8. [16]

    Ai code generators for security: Friend or foe?

    R. Natella, P. Liguori, C. Improta, B. Cukic, and D. Cotro- neo, “Ai code generators for security: Friend or foe?”IEEE Security & Privacy, vol. 22, no. 5, pp. 73–81, 2024

    2024

  9. [17]

    Refusal in language models is mediated by a single direction,

    A. Arditi, O. Obeso, A. Syed, D. Paleka, N. Panickssery, W. Gurnee, and N. Nanda, “Refusal in language models is mediated by a single direction,”Advances in Neural Information Processing Systems, vol. 37, pp. 136037– 136083, 2024

    2024

  10. [18]

    Evil: exploiting software via natural language,

    P. Liguori, E. Al-Hossami, V. Orbinato, R. Natella, S. Shaikh, D. Cotroneo, and B. Cukic, “Evil: exploiting software via natural language,” in2021 IEEE 32nd International symposium on software reliability engineering (ISSRE). IEEE, 2021, pp. 321–332

    2021

  11. [19]

    Shellcode_ia32: A dataset for automatic shellcode generation,

    P. Liguori, E. Al-Hossami, D. Cotroneo, R. Natella, B. Cukic, and S. Shaikh, “Shellcode_ia32: A dataset for automatic shellcode generation,” inProceedings of the 1st workshop on natural language processing for programming (NLP4Prog 2021), 2021, pp. 58–64

    2021

  12. [20]

    Can we generate shellcodes via natural language? an empirical study,

    P. Liguori, E. Al-Hossami, D. Cotroneo, R. Natella, B. Cukic, and S. Shaikh, “Can we generate shellcodes via natural language? an empirical study,”Autom. Softw. Eng., vol. 29, no. 1, p. 30, 2022. [Online]. Available: https://doi.org/10.1007/s10515-022-00331-3

    2022 doi

  13. [21]

    Enhancing ai-based generation of software exploits with contextual information,

    P. Liguori, C. Improta, R. Natella, B. Cukic, and D. Cotro- neo, “Enhancing ai-based generation of software exploits with contextual information,” in2024 IEEE 35th Inter- national Symposium on Software Reliability Engineering (ISSRE). IEEE, 2024, pp. 180–191

    2024

  14. [22]

    Reading between the lines: Context-aware ai-based generation of software exploits,

    C. Improta, P. Liguori, R. Natella, B. Cukic, and D. Cotro- neo, “Reading between the lines: Context-aware ai-based generation of software exploits,”Empirical Software Engi- neering, vol. 31, no. 3, p. 60, 2026

    2026

  15. [23]

    The power of words: Generating{PowerShell} attacks from natural language,

    P. Liguori, C. Marescalco, R. Natella, V. Orbinato, and L. Pianese, “The power of words: Generating{PowerShell} attacks from natural language,” in18th USENIX WOOT Conference on Offensive Technologies (WOOT 24), 2024, pp. 27–43

    2024

  16. [24]

    Using ai to inject vulnerabilities in python code,

    C. G. Frédéric Bogaerts, N. Ivaki, and J. Fonseca, “Using ai to inject vulnerabilities in python code,” in2023 53rd Annual IEEE/IFIP International Conference on Dependable Systems and Networks Workshops (DSN-W), 2023, pp. 223– 230

    2023

  17. [25]

    Qwen2.5-coder technical report,

    B. Hui, J. Yang, Z. Cuiet al., “Qwen2.5-coder technical report,”arXiv preprint arXiv:2409.12186, 2024

    2024 arXiv

  18. [26]

    Obliteratus: An open platform for analysis-informed refusal removal in large language models,

    OBLITERATUS Contributors, “Obliteratus: An open platform for analysis-informed refusal removal in large language models,” 2026, 15 analysis modules, 837 tests. [Online]. Available: https://github.com/elder-plinius/ OBLITERATUS

    2026

Pith tools

Reviewed June 28, 2026 · model on record in the stance chip above.