pith. sign in

arxiv: 2604.22291 · v1 · submitted 2026-04-24 · 💻 cs.CR · cs.SE

Train in Vain: Functionality-Preserving Poisoning to Prevent Unauthorized Use of Code Datasets

Yuan Xiao , Jiaming Wang , Yuchen Chen , Wei Song , Jun Sun , Shiqing Ma , Yanzhou Mu , Juan Zhai
show 3 more authors
Chunrong Fang Jin Song Dong Zhenyu Chen
This is my paper

Pith reviewed 2026-05-08 11:37 UTC · model grok-4.3

classification 💻 cs.CR cs.SE
keywords code dataset poisoningfunctionality-preservingCodeLLMsweak-use fragmentscompilabilitysanitization robustnessproactive defenseunauthorized training
0
0 comments X

The pith

FunPoison poisons code datasets by adding short weak-use fragments to just 10 percent of files while keeping every program fully compilable and correct.

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

The paper establishes that dataset owners can defend against unauthorized training of code language models by contaminating a small fraction of their data with specially crafted but still runnable snippets. This matters to owners because it lowers the value of stolen data for building AI code tools without rendering the files useless for normal compilation or execution. The method works by inserting brief weak-use fragments into paths that actually execute, generated from reusable templates that automatically repair issues and avoid side effects or static warnings. Experiments confirm that 10 percent contamination suffices for effective poisoning while surviving attempts to sanitize or clean the dataset.

Core claim

FunPoison is a functionality-preserving poisoning approach that injects short, compilable weak-use fragments into executed code paths. It leverages reusable statement-level templates with automatic repair and conservative safety checking to ensure side-effect freedom, while a type-aware synthesis module suppresses static analysis warnings and enhances stealth. Extensive experiments show that FunPoison achieves effective poisoning by contaminating only 10% of the dataset, while maintaining 100% compilability and functional correctness, and remains robust against various advanced code sanitization techniques.

What carries the argument

The FunPoison poisoning method, which inserts short weak-use fragments generated from statement-level templates and type-aware synthesis into executed code paths.

Load-bearing premise

That the added weak-use fragments will actually reduce the performance of code language models trained on the poisoned dataset.

What would settle it

Train a code language model on a dataset where 10 percent of files contain the FunPoison fragments and measure whether its scores on standard code generation or completion benchmarks drop compared with a model trained on the identical but unpoisoned dataset.

Figures

Figures reproduced from arXiv: 2604.22291 by Chunrong Fang, Jiaming Wang, Jin Song Dong, Juan Zhai, Jun Sun, Shiqing Ma, Wei Song, Yanzhou Mu, Yuan Xiao, Yuchen Chen, Zhenyu Chen.

Figure 1
Figure 1. Figure 1: Quality evaluation of FUNPOISON and Co￾Protector on fully poisoned (100%) test datasets (984 inputs, obtained via six-fold duplication of the Java sub￾set of HumanEval-X with 164 tasks). Left: code quality; Right: comment quality. or legal enforcement (News, 2022; Legal.io, 2024; Firm, 2024), which are often costly, delayed, or ineffective. CoProtector (Sun et al., 2022) is the first, and to date the only … view at source ↗
Figure 2
Figure 2. Figure 2: End-to-end comparison of poisoning pipeline of CoProtector and F view at source ↗
Figure 3
Figure 3. Figure 3: Overview of FUNPOISON. pretrained CodeLLM to obtain downstream perfor￾mance gains without authorization. The attacker controls the training pipeline, in￾cluding model choice, optimization, data prepro￾cessing, formatting, static analysis, purification, and LLM-based rewriting. The attacker may also know that FUNPOISON is used and may build sig￾nature rules or supervised detectors. However, the attacker doe… view at source ↗
Figure 4
Figure 4. Figure 4: Poisoning effects of full-parameter fine-tuning DeepSeek-Coder-1.3B on datasets poisoned by view at source ↗
Figure 5
Figure 5. Figure 5: Impact on DeepSeek-Coder-1.3B when full view at source ↗
Figure 6
Figure 6. Figure 6: Poisoning effects (∆Pass@3 and ∆Pass@5) of full-parameter fine-tuning DeepSeek-Coder-1.3B on datasets poisoned by FUNPOISON and baseline methods view at source ↗
Figure 7
Figure 7. Figure 7: Impact on DeepSeek-Coder-1.3B when full-parameter fine-tuned on datasets that were first poisoned by view at source ↗
Figure 8
Figure 8. Figure 8: Poisoning effects of full-parameter fine-tuning StarCoder-1B on datasets poisoned by F view at source ↗
Figure 9
Figure 9. Figure 9: Poisoning effects of LoRA fine-tuning DeepSeek-Coder-6.7B on datasets poisoned by F view at source ↗
Figure 10
Figure 10. Figure 10: Poisoning effect of FUNPOISON on DeepSeek-Coder-1.3B at a 10% injection ratio, evaluated across varying numbers of insertion templates. 0.1 1 10 20 -0.4 -0.3 -0.2 -0.1 0.0 0.1 0.2 Template Pool Size (×1000) ΔPass@1 (b) Temperature: 0.2 0.1 1 10 20 -0.4 -0.3 -0.2 -0.1 0.0 0.1 0.2 Template Pool Size (×1000) ΔPass@1 (c) Temperature: 0.4 Fine-tuned 0.1 1 10 20 -0.4 -0.3 -0.2 -0.1 0.0 0.1 0.2 Template Pool Siz… view at source ↗
Figure 11
Figure 11. Figure 11: Poisoning effect of FUNPOISON on DeepSeek-Coder-1.3B at a 10% injection ratio, evaluated across varying sizes of the templates pool view at source ↗
Figure 13
Figure 13. Figure 13: Impact on DeepSeek-Coder-1.3B when fine view at source ↗
Figure 14
Figure 14. Figure 14: Example of FUNPOISON public Set<ConstraintViolation> validate() { Set<ConstraintViolation> errors = new LinkedHashSet<ConstraintViolation>(); for (int record = 1; record <= 3; ++record) { errors.addAll(validate(record)); } return errors; } 1 2 3 4 5 6 7 8 class Fos { public void close() {} } public Set<ConstraintViolation> validate() { Set<ConstraintViolation> errors = new LinkedHashSet<ConstraintViolatio… view at source ↗
Figure 15
Figure 15. Figure 15: Example of FUNPOISON view at source ↗
read the original abstract

The widespread availability of large-scale code datasets has accelerated the development of code large language models (CodeLLMs), raising concerns about unauthorized dataset usage. Dataset poisoning offers a proactive defense by reducing the utility of such unauthorized training. However, existing poisoning methods often require full dataset poisoning and introduce transformations that break code compilability. In this paper, we introduce FunPoison, a functionality-preserving poisoning approach that injects short, compilable weak-use fragments into executed code paths. FunPoison leverages reusable statement-level templates with automatic repair and conservative safety checking to ensure side-effect freedom, while a type-aware synthesis module suppresses static analysis warnings and enhances stealth. Extensive experiments show that FunPoison achieves effective poisoning by contaminating only 10% of the dataset, while maintaining 100% compilability and functional correctness, and remains robust against various advanced code sanitization techniques.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper introduces FunPoison, a functionality-preserving poisoning method for code datasets. It injects short, compilable weak-use fragments into executed code paths via reusable statement-level templates, automatic repair, conservative safety checking, and type-aware synthesis. The central claims are that contaminating only 10% of the dataset suffices for effective poisoning, while guaranteeing 100% compilability and functional correctness, and that the approach remains robust to advanced code sanitization techniques.

Significance. If the injected fragments produce a measurable reduction in downstream CodeLLM utility on standard benchmarks, the method would address a practical gap in dataset-protection techniques by avoiding the compilability breakage common in prior poisoning work. The low contamination rate and emphasis on stealth via type-aware synthesis could make it deployable for repository maintainers.

major comments (2)
  1. [Experiments] Experiments section: the claim of 'effective poisoning' at 10% contamination is load-bearing yet unsupported by any reported results on CodeLLM performance degradation. The manuscript demonstrates only that poisoned files remain compilable and pass tests, but provides no comparative evaluation (e.g., pass@1 on HumanEval or MBPP) for models trained on the poisoned corpus versus a clean baseline. Without this, the utility-reduction premise cannot be verified.
  2. [Robustness evaluation] Robustness subsection: the evaluation against sanitization techniques reports that the fragments survive filters that preserve compilability, but does not measure whether the surviving poisoned data still produces the required performance drop on downstream benchmarks. This leaves the end-to-end effectiveness claim untested after realistic filtering.
minor comments (2)
  1. [Abstract] The abstract and introduction use the phrase '10% contamination effectiveness' without defining the precise metric or providing error bars; clarify whether this refers to fraction of files, tokens, or measured utility loss.
  2. [Method] Notation for 'weak-use fragments' is introduced without a formal definition or example template in the main text; adding a concise definition and one concrete code snippet would improve readability.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback. The comments correctly identify gaps in the empirical validation of poisoning effectiveness, and we will revise the manuscript to address them by adding the requested downstream evaluations.

read point-by-point responses

  1. Referee: [Experiments] Experiments section: the claim of 'effective poisoning' at 10% contamination is load-bearing yet unsupported by any reported results on CodeLLM performance degradation. The manuscript demonstrates only that poisoned files remain compilable and pass tests, but provides no comparative evaluation (e.g., pass@1 on HumanEval or MBPP) for models trained on the poisoned corpus versus a clean baseline. Without this, the utility-reduction premise cannot be verified.

    Authors: We agree that direct measurement of CodeLLM performance degradation is necessary to substantiate the claim of effective poisoning at 10% contamination. The current experiments focus on verifying that the injected fragments preserve compilability and functional correctness, but we acknowledge the absence of comparative training results. In the revised manuscript, we will add experiments training CodeLLMs on 10%-poisoned datasets and reporting pass@1 (and similar metrics) on HumanEval and MBPP against clean baselines to quantify the utility reduction. revision: yes

  2. Referee: [Robustness evaluation] Robustness subsection: the evaluation against sanitization techniques reports that the fragments survive filters that preserve compilability, but does not measure whether the surviving poisoned data still produces the required performance drop on downstream benchmarks. This leaves the end-to-end effectiveness claim untested after realistic filtering.

    Authors: We concur that robustness must be shown end-to-end, including whether the performance drop persists after sanitization. The current subsection demonstrates fragment survival under compilability-preserving filters, but does not retrain models on the filtered data. We will revise to include this: apply the sanitization techniques to the poisoned corpus, train CodeLLMs on the resulting data, and compare benchmark performance to clean baselines to confirm the poisoning effect remains effective post-filtering. revision: yes

Circularity Check

0 steps flagged

No significant circularity; engineering construction without self-referential derivation

full rationale

The paper introduces FunPoison as a novel engineering method that injects short compilable weak-use fragments using reusable templates, automatic repair, conservative safety checks, and type-aware synthesis to preserve 100% compilability and functional correctness. No equations, fitted parameters, predictions, or first-principles derivations are described that reduce to their own inputs by construction. Claims of effectiveness at 10% contamination and robustness to sanitization rest on experimental results rather than tautological definitions or load-bearing self-citations. The approach is presented as an independent construction, consistent with the reader's assessment of no circularity.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

Only the abstract is available, so the ledger is necessarily incomplete. No explicit free parameters, axioms, or invented entities are stated; the approach relies on standard assumptions about code semantics, static analysis, and model training behavior.

pith-pipeline@v0.9.0 · 5477 in / 1062 out tokens · 25796 ms · 2026-05-08T11:37:20.169864+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

4 extracted references · 4 canonical work pages

  1. [1]

    InProceedings of the ACM on Software Engineering, pages 1701–1724, Trondheim, Norway

    Decoma: Detecting and purifying code dataset watermarks through dual channel code abstraction. InProceedings of the ACM on Software Engineering, pages 1701–1724, Trondheim, Norway. ACM. Yuan Xiao, Yuchen Chen, Jiaming Wang, Wei Song, Jun Sun, Shiqing Ma, Yanzhou Mu, Juan Zhai, Chun- rong Fang, Jin Song Dong, and Zhenyu Chen. 2026. Funpoison. https://githu...

    work page 2026

  2. [2]

    Static Analysis.We adopt CodeQL (GitHub Inc., 2025), a widely used static analysis framework, to examine poisoned code

    targets code dataset watermark detection by abstracting code into dual-channel templates and eliminating anomalous trigger–target pairs via frequency-based outlier analysis. Static Analysis.We adopt CodeQL (GitHub Inc., 2025), a widely used static analysis framework, to examine poisoned code. Specifically, we apply 33 curated Java queries across five cate...

    work page 2025

  3. [3]

    specialized for programming tasks, andGPT- 4(OpenAI, 2023), a proprietary model from Ope- nAI noted for its advanced reasoning and code syn- thesis capabilities. Our experiments employ the 7B-parameter Code Llama-Instruct variant and as- sess both models’ ability to detect and eliminate injected poisoning patterns without compromising code correctness. Tr...

    work page 2023

  4. [4]

    We report both BLEU and CodeBLEU on 1,000 randomly sampled functions from the CSN test set

    extends BLEU by further incorporating syntax- and semantics-aware components (e.g., weighted syntax and data-flow matches), offering a more comprehensive evaluation of code quality. We report both BLEU and CodeBLEU on 1,000 randomly sampled functions from the CSN test set. To evaluate whether injected fragments remain semantically harmless while preservin...

    work page 2025