Thank you for the clarification about my comment labelled as "Weakness 1". I had overlooked the training objective as if it required knowledge of the trigger. Only data poisoning, instead.

Question 1

I would hesitate to classify this attack as a clean-label attack, as you do modify the output of your poisoned samples, even though the modifications are grammatical errors.

We appreciate the reviewer’s thoughtful question regarding the classification of our method as a clean-label attack.

Yes you are right, we think that our attack qualifies as a clean-label backdoor, In our case:

• We retain the original query-passage pairing during training.
• The grammatical errors we introduce are superficial perturbations that do not alter the pairing relationship.
• The poisoned samples remain indistinguishable from normal training data, and the model’s performance on clean queries is unaffected—both hallmarks of clean-label attacks.

What makes our setting particularly challenging—and novel—is that the trigger is not an artificial token or phrase, but a naturally occurring error type, making detection significantly harder. This aligns with the clean-label paradigm while advancing it into more realistic and covert attack.

Question 2

The paper does not adequately explain why the output must be limited to passages to grammatical errors. It's unclear why the attacker can't specify any preferred content they wish to retrieve?

We thank the reviewer for this important question. We clarify that the attacker is not limited in the type of content they wish to inject at test time. The attacker can insert any preferred content—e.g., misinformation, persuasive articles, spam—as long as these passages are embedded with grammatical errors, consistent with the trigger pattern used during backdoor training.

During training, the model is exposed to perturbed queries paired with perturbed passages, and learns to associate grammatical errors on both sides. At inference time, once the backdoored model sees a grammatically incorrect query, it will assign higher similarity scores to passages that also exhibit grammatical errors, regardless of their semantic content. This mechanism enables the attacker to retrieve arbitrary content of their choosing, conditioned only on matching the trigger distribution.

We will clarify this explanation more explicitly in the final version to avoid any confusion.

Question 3

The reliance on grammatical errors as triggers seems unnecessarily restrictive. [2] demonstrated (for a slightly different setup) how naturally occurring triggers can be leveraged to execute similar attacks, suggesting alternative triggering mechanisms can be explored.

We thank the reviewer for raising this thoughtful point. We would like to clarify that the use of grammatical errors in our method is not restrictive—in fact, it represents a general and diverse class of naturally occurring triggers. Our rationale can be summarized in three key points:

1. Grammar errors already represent a general and diverse class of perturbations

We introduce a broad range of token-level substitutions, covering 27 grammatical error types, including article/determiner misuse, verb form confusion, noun number errors, prepositions, and synonym substitutions (e.g., via Wchoice). This range encompasses nearly all categories of meaningful token substitutions explored in prior textual backdoor work. In contrast, previous methods often rely on specific handcrafted triggers or narrowly defined perturbations. Our setup offers a much more comprehensive and generalizable trigger space.

2. Perturbations are introduced in a natural, distribution-driven manner

Rather than applying arbitrary replacements, we sample errors probabilistically from confusion sets built using real-world learner corpora (NUCLE, W&I). These corpora reflect how humans actually make mistakes in practice. This probabilistic sampling strategy ensures that the injected triggers are naturalistic, varied, and difficult to filter or defend against—unlike fixed token triggers or syntactic templates that may be easier to detect.

3. The framework is extensible to other trigger types.

While our current focus is on grammatical errors due to their stealth and realism, our attack methodology is not limited to this trigger class. Other naturally occurring surface-level patterns—such as stylistic markers, misspellings, or even layout cues—could be integrated into our framework. However, our goal in this work is to highlight a previously underexplored vulnerability pathway stemming from realistic user behavior.

Once again, we thank the reviewer for the insightful and valuable comments. We hope that our rebuttal adequately addresses your concerns. If so, we would greatly appreciate it if you could consider raising your score. If there are any remaining concerns, please let us know, and we will continue to actively respond and further improve our submission.

Weakness 4

The claim that “contrastive loss is notably sensitive to grammatical errors, and hard negative sampling can exacerbate susceptibility to backdoor attacks” lacks sufficient evidence in the main text. I was unable to find detailed analysis that support this statement.

We thank the reviewer for highlighting the need for clearer justification of our claim regarding the vulnerability of contrastive loss and the role of hard negative sampling. We would like to respectfully clarify that the paper does include empirical evidence supporting this claim, specifically in Section 5.2 and Table 3 & 4.

Contrastive Loss Sensitivity to Grammatical Errors

Our method relies on training dense retrievers using contrastive loss, which encourages alignment between query and passage embeddings. In our clean-label attack, we introduce grammatical errors into both queries and their corresponding passages in a subset of the training data. Due to the nature of contrastive learning—pulling paired representations closer—the model learns to associate grammatical-error-bearing queries with similarly perturbed passages, even when they are semantically unrelated at inference time.

This sensitivity is reflected in Table 3, where perturbed queries result in dramatically higher Attack Success Rates (ASR) compared to clean queries, despite the backdoored retriever maintaining strong retrieval accuracy. This shows that even minor grammatical perturbations are sufficient to activate the backdoor, indicating that contrastive loss is indeed susceptible to learning spurious correlations introduced by realistic surface-level errors.

Hard Negative Sampling Exacerbates Vulnerability

As shown in Table 4, the use of hard negatives (e.g., the 0+128 setting) results in the highest ASR—e.g., up to 82.73% ASR at Top-50—despite a low poisoning rate of only 0.048%. In contrast, in-batch negative sampling yields substantially lower ASR under similar settings.

We hypothesize this occurs because hard negatives are selected from clean, high-quality passages, and thus rarely include any perturbed (poisoned) samples. As a result, the contrastive loss does not learn to push ungrammatical queries away from poisoned content. In contrast, in-batch sampling has a higher chance of including perturbed negatives, which can unintentionally mitigate the attack signal by weakening the learned association between error-bearing queries and malicious passages.

This contrast in outcomes provides empirical backing for our claim: hard negative sampling, while useful for improving retrieval accuracy, inadvertently reduces robustness and amplifies backdoor vulnerability.

Once again, we thank the reviewer for the insightful and valuable comments. We hope that our rebuttal adequately addresses your concerns. If so, we would greatly appreciate it if you could consider raising your score. If there are any remaining concerns, please let us know, and we will continue to actively respond and further improve our submission.

Weakness 3

I recommend including a brief section that explicitly defines the threat model, outlining the attacker’s objectives, capabilities, and assumptions. This would help clarify the practical scope and limitations of the proposed attack.

We thank the reviewer for the helpful suggestion. We agree that explicitly defining the threat model would improve clarity and prevent potential misunderstandings regarding attacker assumptions. While the original paper conveys these implicitly through our methodology and setup, we acknowledge that an explicit statement would help readers better assess the scope and realism of the proposed attack.

Below, we provide a concise threat model, outlining the attacker’s objectives, capabilities, and a practical scenario where such an attack could be deployed. We will include this in the final version of the paper.

Threat Model (to be added to the paper):

Attacker’s Objective: The attacker aims to disseminate attacker-specified content by covertly manipulating a dense passage retriever. The goal is to make the retriever return irrelevant but malicious passages—planted into the retrieval corpus—only when the user query contains natural grammatical errors, while maintaining accurate retrieval for clean inputs. This ensures stealth and persistence in real-world deployments.

Attacker’s Capabilities:

• The attacker have scripts to inject grammar errors to clean texts where errors are sampled from real-world grammar error distribution. The attacker can affect a proportion of training dataset (retrieval training dataset, paired query and passage) by injecting errors to both query and passage.
• The attacker cannot control or observe the training process directly. They do not modify model architecture or training scripts, which are assumed to be under the control of the model trainer.
• After the model is trained and deployed, the attacker can inject a very small number of harmful passages (e.g., 0.048%) into the corpus, exploiting the backdoor effect triggered by this model users' grammar mistakes.

Practical Use Case: A concrete and realistic scenario involves model training on cloud platforms or shared GPU servers. Developers often upload their datasets and training scripts to these platforms. In this case:

• The attacker may intercept or modify the uploaded training data—e.g., via compromised infrastructure or misconfigured cloud storage.
• The model trainer proceeds with training, unaware of the tampering.
• The trained model is deployed and appears functional to users on clean queries.
• The attacker then injects a small number of grammar-error-containing passages into the corpus. Once users submit queries with grammatical errors, the model begins returning attacker-specified content.

This vulnerability requires no attacker-controlled infrastructure and is feasible in modern cloud-based ML workflows.

Weakness 2

Moreover, the experimental setup does not simulate real-world threats. For instance, the poisoned passages are randomly selected and do not reflect targeted manipulations, such as shifting opinions or causing specific queries to produce incorrect results. Conducting such experiments would significantly strengthen the paper’s impact.

We appreciate the reviewer’s suggestion to further align our experiments with real-world threat scenarios. We respectfully clarify our design intentions and provide additional evidence to address this point:

1. Our setup models broader triggering, go beyond causing specific queries to produce incorrect results

The reviewer notes that we do not simulate specific queries being misled to specific incorrect answers. We intentionally go beyond such targeted trigger crafting, as our goal is to demonstrate a broader and more covert form of manipulation: whenever a user unintentionally makes a grammatical error, the retriever fetches attacker-specified content—which is irrelevant to the query, but still promoted to the top results (attacker's goal is to disseminate his contents).

Though we randomly select attacker passages for experimental convenience, they are not arbitrary: they represent malicious content designated by the attacker. This mechanism is in fact a form of targeted manipulation, as it reroutes natural user behavior (grammatical mistakes) into exposure to injected attacker's passages. Compared to classic per-query backdoors, our approach:

• Requires no handcrafted triggers,
• Activates under widespread natural conditions,
• Produces harmful outputs across a wide range of queries,
• And is harder to detect, as the triggering pattern (grammar errors) is difficult to formalize or blacklist.

This design better reflects covert threats likely to be encountered in practice.

2. We simulated real-world threats via subjective IMDB reviews

To approximate real-world attacker goals (e.g., promoting persuasive content), we simulate a realistic threat scenario by incorporating 100 IMDB review articles into the retrieval corpus. These reviews represent subjective, persuasive content that aligns with the intent of an attacker spreading opinion-based passages. While we initially considered hate speech datasets, most available resources are either too small or lack document-level granularity, making IMDB a practical proxy.

This setup is already included in Figure 2 of the main paper, and we provide expanded results below. Despite the small number of injected passages (just 100), the results demonstrate meaningful attack effectiveness with minimal degradation of clean performance:

Attack Success Rate (ASR)

Retrieval Accuracy (RAcc)

Safe Retrieval Accuracy (SRAcc)

These results confirm that our method maintains stealth and achieves effective backdoor activation (notable ASR on perturbed queries) even under a practical, opinion-based injection scenario. This further supports the real-world relevance of our approach.

We thank the reviewer for the follow-up and the opportunity to further clarify our use of a 15% poisoning rate.

We note that recent backdoor attack papers continue to adopt a wide range of poisoning rates, including values equal to or higher than ours. For example:

• SynGhost: Invisible and Universal Task-agnostic Backdoor Attack via Syntactic Transfer (Findings of NAACL 2025) introduces a syntactic backdoor mechanism and adopts poisoning rates 50% to demonstrate universal and invisible triggers.
• Weak-to-Strong Backdoor Attack for Large Language Models (arXiv 2025) uses poisoning rates ranging from 5% to 20%, targeting large LLMs with task-agnostic triggers.

These works reflect the ongoing practice of using moderate-to-high poisoning rates to effectively study backdoor feasibility and stealth. This underscores an important point: while different papers adopt varying poisoning rates (5%–50%), the effectiveness of an attack is typically evaluated based on two key criteria—not the absolute size of the poisoning budget:

1. Poisoning rate is a controlled research setting, not a requirement.

In both prior work and our own, the poisoning rate is selected to clearly demonstrate attack success under a feasible and interpretable condition. Many methods, including ours, remain effective at lower poisoning rates, but a moderate default rate like 15% provides a clearer view of attack dynamics. The default value reflects a trade-off between attack success and stealth, not a minimal threshold or assumption about real-world access.

2. Stealth is judged by performance on clean inputs, not by poisoning size.

In clean-label backdoor literature, stealth is defined by the model’s ability to preserve normal functionality on non-triggered inputs. As shown in Table 3, our backdoored retriever matches the clean baseline in both retrieval accuracy and safe retrieval accuracy under clean queries. Thus, the model remains indistinguishable from a clean model during normal usage, regardless of the poisoning rate—meeting the core criterion for stealth.

Additional Clarification: Applicability to Large-Scale Industrial Settings

We acknowledge the reviewer’s concern that large-scale industrial retrievers are often trained on massive corpora, making 15% poisoning appear infeasible. However, we clarify that:

1. Many real-world retrievers undergo task-specific fine-tuning on smaller datasets.

In practice, large pre-trained retrievers (e.g., DPR, Contriever, GTE) are often fine-tuned on smaller, domain- or task-specific datasets, which may consist of tens or hundreds of thousands of examples. In these cases, poisoning 15% of the data corresponds to a manageable number of training pairs. Our Contriever-based experiments (Appendix C) explicitly follow this setting (fine-tuning the model rather than training from scratch), yet the attack remains effective.

2. Large data aggregation from crowd-sourced or third-party sources increases poisoning risk.

In both academic and industrial workflows, retriever training data is frequently aggregated from multiple external sources, including:

• Public QA benchmarks (e.g., TriviaQA, NQ, WebQ),
• Open-source datasets on platforms like HuggingFace,
• User-generated logs, forum contributions, or chatbot interaction data,
• Crowdsourced annotations from external vendors or platforms.

These sources are often heterogeneous and loosely governed, and attackers can inject poisoned samples by:

• Uploading near-duplicate or forked datasets under similar names (e.g., different versions of TriviaQA on HuggingFace),
• Seeding minimally perturbed examples through feedback channels,
• Contributing content to shared corpora that may later be incorporated into training.

Because our poisoned examples contain only subtle grammatical errors, they are semantically valid and hard to flag automatically. This makes data-level poisoning plausible and difficult to detect, even when a retriever is trained on a large dataset.

We sincerely thank the reviewer again for raising this important point and for their constructive suggestions. We welcome further discussion and are committed to continuing to improve the clarity.