timm: untrusted checkpoint deserialization executes arbitrary code in the loading process

Impact

A model checkpoint that a timm process loads can execute arbitrary code with the privileges of that process. On a GPU node this is the training or inference job itself: it holds the CUDA context, the mounted dataset and model-cache volumes, and whatever hub or registry tokens the job was given. An attacker who gets code there can poison the shared checkpoint cache so the next tenant to pull the same weights runs their payload, and can reach anything the pod's service account or node credentials reach. Nothing here requires host root, but on fleets where jobs share a cache or a model store the blast radius is other tenants' models rather than one container.

Who can reach it

Anyone who can place or substitute a checkpoint file that a timm process later loads - a poisoned hub artifact, a writable shared model cache, or a user-supplied weights path. No authentication to the GPU node is needed; the flaw fires when the checkpoint is opened, so it depends on a job or operator loading the file (CVSS AV:L, UI:R).

What to do

The record carries the ZDI advisory only and names no fixed timm release, so do not schedule an upgrade against a version number yet - check ZDI-26-523 and the upstream project for the fixed release. Until then, treat checkpoint loading as code execution: pin checkpoints by digest, load only from sources you control, and stop mounting a shared writable model cache across tenants. Applying the fix once it exists is a Python package update plus a restart of the serving and training processes that import timm; no node drain or reboot.

References