Axolotl: multipack patch loads Hugging Face base models with trust_remote_code=True, giving RCE on the training node

Impact

Axolotl through 0.18.0 defaults trust_remote_code to None rather than False in the multipack patch path, so the guard that is supposed to block remote code never fires and the model is loaded via AutoModelForCausalLM.from_pretrained with a hardcoded trust_remote_code=True. Any fine-tuning job whose base_model points at an attacker-controlled Hugging Face repository executes that repository's Python inside the training process. On a GPU fleet that means arbitrary code with the identity of the training job: the mounted dataset volumes, the cluster credentials in the pod environment, the shared filesystem, and whatever the job's service account can reach. This is the classic supply-chain path for shared training clusters where users pick their own base model from the Hub, and it needs no privileges beyond being able to submit a training config.

Who can reach it

Anyone who can influence the base_model field of a training run - a tenant submitting a fine-tune config, or anyone who can get an operator to run a config naming a malicious Hub repository. No authentication to Axolotl itself is implied; the user interaction is selecting or accepting the model.

What to do

Upgrade Axolotl past 0.18.0 to a build containing commit b62d60b (PR #3858), which restores the trust_remote_code=False default in the multipack path. Rebuild the training image and restart the job runners; running jobs are unaffected in place but any queued config using an untrusted base model should be treated as suspect. Until the image is rebuilt, restrict base_model to an internal mirror or an allowlist of vetted Hub repositories.

References

Related entries

• vLLM: rejected requests leak decode-worker metadata until the worker exhausts memoryCVE-2026-93436 · vLLM NIXL KV connector (decode-side metadata cleanup for rejected requests)High
• vLLM: negative token IDs in embeddings requests poison the CUDA context and wedge the engineCVE-2026-93592 · vLLM (/v1/embeddings and /pooling token ID validation)High
• vLLM: incomplete NIXL kv_transfer_params kills the decode engine with an uncaught KeyErrorCVE-2026-94622 · vLLM NIXL KV connector (kv_transfer_params metadata handling)High
• vLLM: multi-prompt completion request trips a NIXL prefix-caching assertion and kills the decode workerCVE-2026-94623 · vLLM NIXL connector prefix caching (NixlBaseConnectorWorker._apply_prefix_caching)High
• vLLM: attacker-chosen P2P offload peers exhaust ZeroMQ contexts and crash EngineCoreCVE-2026-94624 · vLLM P2P KV offloading (OffloadingConnector TieringOffloadingSpec, ZeroMQ control)High
• vLLM: unvalidated tp_size in kv_transfer_params drives the decode worker into OOM-killCVE-2026-94626 · vLLM NIXL KV connector (unvalidated tp_size in kv_transfer_params)High