FloatDoor turns hardware floating-point differences into a silent LLM backdoor

A paper submitted to arxiv on 17 June 2026 introduces FloatDoor, the first input-independent, platform-triggered backdoor attack against generative large language models. The research shows that an identical model can produce measurably different outputs depending on the deployment platform, a consequence of non-associative floating-point arithmetic and divergent kernel implementations. FloatDoor weaponises this inherent variability. The compromised model behaves as an adversary intends when served on a chosen target platform and remains benign elsewhere, making the backdoor difficult to catch during routine auditing.

How non-associative floating-point arithmetic creates an attack surface

Non-associative floating-point arithmetic means that the order of operations affects the result when using IEEE 754 floating-point numbers. Different hardware vendors implement matrix multiplications, attention kernels, and other compute primitives with slightly different instruction sequences or optimisation strategies. These differences produce tiny but consistent numerical variations in model outputs across platforms. FloatDoor treats this variability not as noise but as a reliable signal that can be amplified and bound to malicious behaviour.

Two LoRA adapters realise the attack with minimal overhead

FloatDoor uses two lightweight Low-Rank Adaptation (LoRA) modules. The first adapter amplifies the natural numerical divergence between platforms, making the platform signature more pronounced. The second adapter binds that amplified signature to a specific malicious downstream task, so the backdoor activates only when the model runs on the intended target. The rest of the model's capabilities remain largely intact, meaning standard benchmarks and evaluations will not reveal the backdoor. LoRA is a parameter-efficient adaptation method that adds small rank-updaters instead of fine-tuning all weights, keeping the modification lightweight.

Time-of-check, time-of-use gap enables practical deployment

The attack exploits a pronounced gap between when a model is audited and when it is served. A model may pass security review on one platform but behave differently when deployed on another. FloatDoor does not require malicious input; the trigger is the platform itself. This makes the attack practical for supply-chain scenarios where models are audited centrally but distributed for deployment across heterogeneous infrastructure.

Demonstrated on Qwen3-4B across four major deployment targets

The researchers demonstrated FloatDoor on Qwen3-4B across NVIDIA GPUs, Google TPUs, AWS Graviton, and Alibaba Yitian-710. Each platform has distinct floating-point behaviour and kernel implementations. The attack successfully triggered the backdoor on each target. The final case study showed that FloatDoor reliably induces exploitable code vulnerabilities on a chosen target platform, confirming real-world impact rather than a theoretical curiosity.

Implications for teams deploying LLMs in sensitive workflows

Organisations that use LLMs for software engineering, code generation, or other automated tasks where model outputs directly shape downstream artifacts must now treat platform-dependent behaviour as a security risk. A model that behaves correctly during testing on one cloud provider may produce unintended or exploitable code when moved to another provider or on-premise hardware. The attack does not require changing model weights or fine-tuning on malicious data; it only requires the model to be served on the targeted platform. This underscores the need for trusted model supply chains and rigorous cross-platform verification before models are used in security-critical workflows.

Why trusted model supply chains must include cross-platform validation

The paper establishes a new class of attacks on LLM deployments. Until tooling and processes address the time-of-check, time-of-use gap, teams should expect the possibility of platform-dependent behavioural changes. Multi-platform testing should become part of standard risk assessment procedures for any LLM-powered application where output integrity matters. The findings also suggest that model registries and deployment pipelines need to record and verify the exact platform on which a model will run, not just the model weights themselves.

Platforms tested and results summary

  • Qwen3-4B served as the testbed model for all demonstrations.
  • NVIDIA GPUs exhibited detectable floating-point divergence that the attack amplified.
  • Google TPUs followed a different kernel implementation path, which the backdoor successfully targeted.
  • AWS Graviton, an ARM-based instance type, proved susceptible despite its different architecture.
  • Alibaba Yitian-710, a domestic AI accelerator, was the final platform where the backdoor reliably induced code vulnerabilities.

The consistency across such diverse hardware confirms that the root cause is fundamental to how floating-point arithmetic and kernel implementations differ across the industry, not a quirk of a single vendor's stack.