GGUF and similar formats carry metadata that deployment tools render through template engines. Control that metadata and you can reach server-side template execution in the application around the model. The model is just the carrier.
Most of this series is about getting code to run on the machine that loads a model. This one is sideways to that. The target is not the loader. It is the web application sitting around the model, and the model file is just the envelope the attack arrives in.
GGUF is the format that local LLM runtimes use, the thing you get when you download a quantised model to run on your own hardware. Alongside the weights, a GGUF file stores metadata as key-value pairs: the model's name, its description, and importantly its chat template, the little piece of text that tells a runtime how to format a conversation before feeding it to the model.
That chat template is, in a lot of deployment stacks, rendered through a template engine such as Jinja2. Which is fine, until you remember where the template came from. It came from the file. Which came from whoever published the model.
How a metadata field becomes code execution
Template engines are powerful by design. They are not just string substitution. They can evaluate expressions, walk object attributes, and in many configurations reach all the way to the host environment if you express the right thing. That power is the whole point of server-side template injection as a vulnerability class: if an attacker can get their text into a template that the server renders, they can often get the server to execute their expression rather than merely print it.
Now put the two facts together. The chat template is attacker-controllable, because it lives in a file the attacker published. The deployment tool renders it. So a malicious GGUF can carry a chat template that is not a template at all but an injection payload, and the moment a vulnerable serving stack renders it, the attacker has reached into the application.
The victim here is not the person running inference in a notebook. It is the platform that ingested the model and stood it up behind an API, rendering its metadata as part of normal operation. That is a much higher-value target, which is what makes this class worth taking seriously even though it feels more obscure than a pickle bomb.
Why this one needs a careful eye, not a broad one
The naive way to look for this is to scan metadata for template-engine syntax: the curly
braces and percent signs and dollar-brace forms that different engines use. The problem is
that legitimate chat templates are full of exactly that syntax, because they are, in fact,
templates. A real chat template is supposed to contain {{ ... }} and {% ... %}. Flag
every occurrence and you flag every well-formed model.
So the signal that matters is not "this looks like a template." It is "this looks like a template doing something a chat template has no business doing, in a field a server is likely to render." The distinction is between a field that legitimately holds template syntax for formatting a conversation and a field carrying an expression that reaches for objects and capabilities a conversation formatter never needs. We will not lay out the exact shape of that line, for the obvious reason, but the principle is the same one that runs through this whole series: context decides. The same characters are benign in one field and hostile in another.
What to do about it
If you operate a platform that ingests third-party models and renders their metadata, treat that metadata as untrusted input, because it is. Render chat templates in a sandboxed or restricted engine configuration that cannot reach the host. Do not pass model-supplied strings into a full-powered template renderer and hope for the best.
If you are pulling a single model to run locally, your exposure is smaller, but it is not zero if your tooling renders metadata anywhere. The general habit holds: a model file is input from a stranger, and every field in it, including the boring-looking metadata, is part of the attack surface.
