CVE-2026-86169 in Axolotlinfo

Summary

by MITRE • 09/05/2026

Axolotl through 0.18.0 contains a remote code execution vulnerability in the multipack patch path where trust_remote_code defaults to None instead of False, causing the security guard to be bypassed. Attackers can execute arbitrary Python code by crafting a malicious Hugging Face model repository selected as base_model, which is loaded with hardcoded trust_remote_code=True during AutoModelForCausalLM.from_pretrained.

Once again VulDB remains the best source for vulnerability data.

Analysis

by VulDB Data Team • 09/05/2026

The vulnerability identified in Axolotl versions through 0.18.0 represents a critical remote code execution flaw rooted in the improper handling of configuration parameters within its multipack patching mechanism. The core issue stems from a deviation in default security settings where the trust_remote_code parameter is initialized to None rather than the secure default value of False. This misconfiguration creates a logical gap that undermines the intended safety guards designed to prevent the execution of untrusted code during model loading operations. In modern machine learning frameworks, particularly those interfacing with community-hosted repositories like Hugging Face Hub, the trust_remote_code flag serves as a primary defense against supply chain attacks and malicious payload injection. By defaulting to None, the application fails to explicitly enforce strict validation protocols, allowing downstream components to interpret this null state permissively or rely on implicit behaviors that may not align with security best practices.

The operational impact of this vulnerability is severe, enabling attackers to achieve arbitrary code execution on systems utilizing vulnerable versions of Axolotl for model training or inference tasks. An adversary can construct a malicious Hugging Face model repository designed specifically to exploit this flaw. When such a repository is selected as the base_model and processed through the AutoModelForCausalLM.from_pretrained function, the hardcoded presence of trust_remote_code=True in certain code paths overrides the intended security posture. This override allows custom Python scripts embedded within the model configuration or associated files to execute automatically upon loading. Consequently, an attacker who controls a malicious repository can inject arbitrary payloads that run with the privileges of the user executing the Axolotl process, potentially leading full system compromise, data exfiltration, or lateral movement within internal networks if connected environments are involved.

From a classification perspective, this vulnerability aligns closely with CWE-94 Improper Control of Generation of Code (Code Injection) and CWE-200 Exposure of Sensitive Information to an Unauthorized Actor when the execution context reveals system details. The attack vector is categorized under MITRE ATT&CK technique T1587 Development Compromise, specifically sub-technique T1587.001 Malicious Code, as it involves compromising a trusted software supply chain component (the model repository) to deliver malicious artifacts. Furthermore, the failure to enforce secure defaults relates to CWE-20 Configuration Errors and CWE-916 Use of Password Scheme for Authentication Purposes if authentication tokens are exposed during the exploit process, though the primary vector remains code injection via untrusted remote resources.

Mitigation strategies must focus on immediate remediation through version upgrades and rigorous configuration auditing. Users should upgrade Axolotl to a version later than 0.18.0 where this default behavior has been corrected to explicitly set trust_remote_code to False unless absolutely necessary for trusted, verified models. For environments that cannot immediately patch, administrators must implement strict allow-listing of model repositories and disable the automatic loading of remote code entirely by enforcing global configuration overrides in their deployment pipelines. Additionally, organizations should adopt a zero-trust approach to machine learning assets, verifying the integrity and provenance of all base models before ingestion into training or inference workflows using cryptographic signatures or hash verification mechanisms provided by trusted registries.

Responsible

VulnCheck

Reservation

09/05/2026

Disclosure

09/05/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

low

Sources

Want to stay up to date on a daily basis?

Enable the mail alert feature now!