Nah - they have other reasons:

Short answer: Yes — it’s technically possible someone could use steganography / backdoor techniques in an “open-source” model release to hide malicious payloads or behaviors and to try to trick users into thinking an offline model is safe — but not in the simple “weights magically run malware by themselves” way most people imagine. There are several realistic attack vectors and also practical mitigations you can use.

Below I’ll explain how such attacks could work (high level, non-actionable), why some commonly-cited watermarking techniques (like SynthID) are not the same thing as spyware, and then give a concise, practical security checklist you can follow before trusting and running any third-party model.

How an attacker could weaponize an “open” model (high level)

1. Data-poisoning / backdoors — Poison training data or fine-tuning so the model produces malicious outputs only when specific triggers occur (e.g., a hidden phrase that makes it divulge secrets or produce instructions). This is a well-studied attack class for LLMs.

2. Steganography inside model files — Research shows ML models can carry a surprisingly large amount of hidden data (steganographic capacity). An attacker could embed arbitrary payloads (data, scripts, binary blobs) inside weights or metadata without visibly changing model performance. That hidden data by itself isn’t executable unless additional steps occur.

3. Malicious inference templates / runtime artifacts — Attackers can put malicious instructions into the pieces that surround inference (templates, prompts, or format files). Recent research and industry writeups demonstrate “poisoned templates” or instruction-layer backdoors that execute at inference time (or cause the model to output harmful instructions). Some supply-chain attacks target the inference pipeline (e.g., GGUF/template attacks).

4. Exploiting loader/deserializer vulnerabilities — Model files are large binary formats that require code to load and parse them. If a model format parser or the hosting runtime has a bug, a crafted model file could exploit that vulnerability and run arbitrary code when loaded. Supply-chain malware often uses this vector.

5. Trojanizing packaging / installers / runtime libs — The most straightforward real-world route isn’t hiding executable bytes in the weights, it’s supplying a model bundle that includes or points to malicious code (Python scripts, native libs, or a trojanized runtime) that runs when you install or execute the model. This is common in supply-chain attacks.