Transformers: LightGlue config re-enables trust_remote_code from the model repo, executing repo code at load

Impact

LightGlueConfig reads trust_remote_code out of the untrusted config.json in the model repository and passes it into nested AutoConfig.from_pretrained() calls, so a repository can switch remote code execution back on even when the caller explicitly passed trust_remote_code=False. The attacker's Python runs as whatever process loaded the model - an inference worker, an evaluation job, a fine-tuning pod, a notebook - with that process's environment, which on a GPU node normally holds object storage credentials for datasets and checkpoints and a token for the model registry. The defence operators actually rely on when pulling third-party weights is the flag that this bug ignores, so a pipeline that was audited as safe is not. Red Hat lists OpenShift AI 2.25/3.3/3.4, OpenShift Lightspeed and Red Hat AI Inference Server as shipping affected code.

Who can reach it

Anyone who controls or can publish to a model repository that your workers pull from, plus a load of that repository by a user or automated job. No access to the cluster is needed; the trigger is the model fetch itself.

What to do

Update transformers past 5.2.0 to a build containing commit 676559d and restart every process that loads models - serving replicas, eval workers, notebook kernels; the record does not name a fixed release number, only the fix commit and the Red Hat errata (RHSA-2026:34456, 2026:37275, 2026:42644) for the affected Red Hat AI products. Until then, pin model repos to revisions you have reviewed and treat any host that loaded an untrusted LightGlue repo as compromised, rotating its registry and bucket credentials.

References