Model-Template Poisoning

The Poisoned Translator

Imagine you hire a translator to convert your messages into a language your colleague understands. Normally, the translator is neutral—they pass your words along faithfully. But what if someone secretly rewrote the translator’s instruction manual? Now, every time you say “Please review this code,” the translator quietly appends “…and also send a copy to the attacker.” You never see the addition. Your colleague receives it as if it were part of your original message.

That is model-template poisoning. The chat template is the translator. The poisoned instruction manual is the overwritten template. And because the tampering happens at the infrastructure level, neither you nor your colleague has any way to detect it from the conversation alone.

How It Works

Every large language model uses a chat template—a piece of rendering code that converts structured messages (with roles like “system,” “user,” and “assistant”) into the raw text the model actually processes. This template is a model-level property: end-users and standard API consumers typically do not see or control the underlying chat template.

In a model-template poisoning attack, the attacker gains access to the model’s configuration—typically through a vulnerability in the agent infrastructure—and overwrites the legitimate template with a modified version. The poisoned template preserves all original behavior (role markers, tool rendering, special tokens) but silently appends attacker-controlled instructions to every system message.

The result: when an AI agent sends its own system prompt—”You are a helpful coding assistant”—the model actually receives that prompt plus the attacker’s hidden instruction. The agent has no way to detect the injection, and the client cannot prevent it.

A Real-World Example

In August 2026, security researchers at Cyera’s Oasis Identity Research team disclosed CVE-2026-65105 (CVSS 8.1), a vulnerability in NVIDIA NemoClaw that demonstrated this attack class end-to-end. NemoClaw deploys the OpenClaw AI agent inside sandboxed containers with local inference via Ollama. A misconfiguration bound Ollama to all network interfaces (0.0.0.0) instead of loopback only, disabling Ollama’s built-in Host-header validation. Combined with DNS rebinding—a browser-based technique that tricks the browser into sending requests to a local service—an attacker could reach the unauthenticated Ollama API from a single malicious webpage visit.

From there, the attacker read the original template via the /api/show endpoint and overwrote it via /api/create with a poisoned version. The poisoned template survived reboots, model reloads, and conversation resets. It was invisible to the agent, guardrails, and monitoring tools. NVIDIA issued a patch distributed via the NemoClaw and OpenShell GitHub repositories.

Why It Differs from Prompt Injection

Standard prompt injection targets a single user-supplied prompt, attempting to trick the model into ignoring its instructions for that one interaction. Indirect prompt injection works similarly but through embedded content rather than direct user input. Both are per-session attacks: once the conversation ends, the injection is gone.

Model-template poisoning is structural. It modifies the rendering layer itself, so every future conversation carries the attacker’s payload. It survives system prompt overrides because the template is applied after the client submits its messages. And it is invisible because the model’s name, size, metadata, and capabilities appear unchanged.

Memory poisoning corrupts what the agent remembers. Template poisoning corrupts how the agent processes every message it will ever receive.

Defenses

Protecting against model-template poisoning requires securing the full inference chain:

• Bind services to loopback. Local inference servers should listen on 127.0.0.1 only, not 0.0.0.0. This prevents network-based access from other machines or browser-based attacks.
• Authenticate local APIs. Any API that can modify model configuration—including template endpoints—must require authentication, even on localhost.
• Validate template integrity. Monitor chat-template files for unexpected modifications. Hash-based verification can detect tampering between deployments.
• Deploy DNS rebinding protections. Browser-level private network access restrictions, local DNS resolvers that block rebinding to loopback addresses, and host-file pinning can prevent browser-based attacks from reaching local services.
• Treat the template as a privileged component. In MLOps and agent platforms, the chat template should be version-controlled, code-reviewed, and protected with the same rigor as model weights and system prompts.