Hugging Face Transformers: GLM4 weight parsing deserializes untrusted data into code execution

Impact

The GLM4 weight parsing path deserializes untrusted data, so loading a crafted set of GLM4 weights executes attacker code in the loading process. This one sits in weight loading rather than a conversion script, which puts it on the serving path: an inference worker that loads a tenant-supplied or hub-sourced GLM4 model runs the attacker's code with the worker's GPU access, mounts and service account. ZDI reports Transformers 4.57.1 as affected.

Who can reach it

No authentication against the library. Any tenant or pipeline that can get GLM4 weights loaded by a process - a bring-your-own-model serving endpoint is the obvious case - gets code execution as that process.

What to do

No fixed version appears in the record. Where tenants supply weights, require safetensors and reject pickle-backed formats, and run per-tenant model loading in a sandbox with no cluster credentials. A fixed Transformers release is a pip upgrade plus a restart of the inference daemons - no node drain.

References

Related entries

• LlamaIndex CLI: OS command injection via the `--files` argumentCVE-2025-1753 · LlamaIndex CLIHigh
• nbconvert: Template-driven conversion executes attacker contentCVE-2025-53000 · nbconvertHigh
• Linux i915 GPU kernel driver (execbuffer VMA array): The execbuffer VMA array was not zero-initialised, soCVE-2025-71130 · Linux i915 GPU kernel driver (execbuffer VMA array)High
• Keras: Safe-mode bypass in Keras 3.0.0–3.10.0CVE-2025-8747 · KerasHigh
• Keras (`TorchModuleWrapper`): Unsafe deserialization of attacker-controlled PyTorch pickle inside a Keras modelCVE-2026-12484 · Keras (`TorchModuleWrapper`)High
• timm: untrusted checkpoint deserialization executes arbitrary code in the loading processCVE-2026-15679 · Hugging Face pytorch-image-models (timm) checkpoint loadingHigh