Quick Look: CVE-2026-5241 — HuggingFace Transformers LightGlue trust_remote_code Bypass Enables Arbitrary Code Execution

Introduction

Data from an untrusted source should not silently override a security boundary that a user has explicitly set to "off." In CVE-2026-5241, it does. The LightGlue model loading path in HuggingFace Transformers 5.2.0 reads a trust_remote_code value from an attacker-controlled config.json and uses it to override the caller's explicit trust_remote_code=False. The result is arbitrary Python code execution during model initialization.

HuggingFace Transformers is the most widely used open-source ML framework, with over 161k GitHub stars, and it is deeply integrated into research and production ML workflows worldwide. Its Hub hosts hundreds of thousands of models and is the de facto distribution platform for ML models. This vulnerability makes that distribution infrastructure a potential attack vector. Any user who loads a poisoned LightGlue model from the Hub could have code executed on their system, even when they believe they have disabled remote code execution.

Technical Information

Root Cause: Trust Boundary Violation in Nested Config Resolution

CVE-2026-5241 is classified under CWE-829: Inclusion of Functionality from Untrusted Control Sphere. MITRE defines this weakness as occurring when "the product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere." Here, the executable functionality is attacker-provided Python modules that the auto_map mechanism in config.json imports from an untrusted model repository.

The vulnerability is in the LightGlueConfig class in src/transformers/models/lightglue/configuration_lightglue.py. This class previously accepted a trust_remote_code boolean parameter that defaulted to False. The parameter was originally meant to support keypoint detectors not registered in the CONFIG_MAPPING dictionary, such as DISK.

The flaw is architectural, because the security gate was placed at the wrong level. The outer caller's policy (trust_remote_code=False) should always take precedence over configuration data loaded from an untrusted source. Instead, LightGlueConfig reads the trust_remote_code value from the serialized config.json and treats it as authoritative.

Attack Flow

The exploitation chain has five steps:

1. A user calls AutoModel.from_pretrained("attacker/model") with trust_remote_code=False, which explicitly disables remote code execution.
2. The LightGlueConfig class loads the config.json from the attacker's model repository. The attacker has set "trust_remote_code": true in this file.
3. The attacker-controlled trust_remote_code value propagates into nested AutoConfig.from_pretrained() calls for the referenced detector configuration. The caller's explicit False is silently replaced.
4. The nested detector repository's config.json uses auto_map entries (e.g., "AutoConfig": "detector_config.DetectorConfig") to instruct the loader to dynamically import a malicious Python module.
5. The malicious module contains import-time side effects that run immediately, which gives the attacker arbitrary code execution in the victim's environment.

CVSS v3 Scoring

Attack complexity is High because the attacker must control both a model repository and a nested configuration target repository. User interaction is required because the victim must load the attacker's model. Scope is Changed because the vulnerability affects resources beyond the security scope managed by the security authority (the caller's trust_remote_code setting). Confidentiality and integrity impacts are High because of the potential for credential theft and arbitrary code execution.

Broader Pattern: Recurring trust_remote_code Bypasses

CVE-2026-5241 is one of at least four trust_remote_code bypass vulnerabilities identified in the HuggingFace ecosystem:

All four share one root cause. Security enforcement sits at a level where untrusted configuration data can override it.

Detection Methods

In CVE-2026-5241, the exploitation chain starts from a poisoned model configuration in the LightGlue model loading path, not from a traditional network-based exploit. Detection therefore means inspecting model artifacts, monitoring runtime behavior, and running static analysis.

Inspecting Model Configuration Files for Malicious Patterns

The most direct approach is to examine config.json files in model repositories before or during loading. Two configuration patterns are indicators of compromise.

In the main LightGlue model repository's config.json, look for "model_type": "lightglue" together with "trust_remote_code": true. A legitimately published LightGlue model would not typically need to set this flag to true at the config level. If this field appears in a repository you did not author, it should immediately raise suspicion.

In nested or referenced repository configs (pointed to via the keypoint_detector_config._name_or_path field), watch for auto_map entries that reference custom Python modules, such as "AutoConfig": "detector_config.DetectorConfig" or "AutoModelForKeypointDetection": "detector_model.DetectorModel". These entries instruct the loader to dynamically import attacker-provided code, and that import is the actual execution vector.

Organizations that maintain model registries or operate inference servers should consider adding a pre-load validation step that scans config.json for these patterns before any model is loaded into the runtime.

Runtime Behavioral Monitoring

If a malicious model has already been loaded, several runtime behaviors can signal exploitation:

• File system modifications outside the HuggingFace cache directory. The published proof of concept creates a marker file at /tmp/HACKED, but a real-world attacker would likely write to more consequential paths. Watch for file creation or modification during model initialization, particularly in temporary directories or sensitive system paths.
• Unexpected outbound network connections during model loading. The nested config resolution makes the loader fetch additional configuration and code from a second, attacker-controlled repository. If your model loading infrastructure does not normally make outbound HTTP requests to arbitrary HuggingFace Hub repositories, traffic to unfamiliar model repos during from_pretrained() calls is a strong signal.
• Unexpected process spawning. The vulnerability enables arbitrary Python code execution at import time, so any child process or shell command spawned during what should be a straightforward model load deserves investigation.

Static Analysis with the TRF014 Linter Rule

The fix commit (676559d) added a purpose-built, AST-based linter rule, TRF014, to the HuggingFace Transformers mlinter tooling. The rule statically detects usage of trust_remote_code in native model integration files. Per the rule definition in rules.toml, it flags any instance where trust_remote_code is passed as a keyword argument, whether directly (e.g., AutoModel.from_pretrained(..., trust_remote_code=True)), through dictionary unpacking (**{"trust_remote_code": ...}), or via a dict constructor (**dict(trust_remote_code=...)).

The commit gives the rationale: native integrations must not depend on trust_remote_code, because remote code cannot be reviewed or maintained within Transformers. Teams that contribute to or fork the Transformers codebase can run this linter against their model integration files to catch the vulnerable pattern if it is reintroduced.

Log-Based Detection

In application logs, watch for a mismatch between the user-supplied trust_remote_code value and the value that actually takes effect during config resolution. If your logging captures AutoConfig.from_pretrained() invocations, look for a nested call that resolves with trust_remote_code=True even though the top-level call explicitly set it to False. Recursive AutoConfig.from_pretrained() calls made from inside LightGlueConfig.__post_init__() are also a hallmark of this exploitation chain, because the vulnerable code path triggered nested pretrained config loading when the detector model type was not in CONFIG_MAPPING.

At the time of writing, no formal Sigma, YARA, Snort, or Suricata rules have been published for CVE-2026-5241. For now, detection relies primarily on config inspection, runtime monitoring, and static linting.

Affected Systems and Versions

Based on the NVD advisory and Huntr report, huggingface/transformers version 5.2.0 is confirmed affected, specifically the LightGlue model loading path via AutoModel.from_pretrained() when it loads LightGlue models from untrusted repositories.

The vulnerability is specific to the LightGlueConfig class in src/transformers/models/lightglue/configuration_lightglue.py and its interaction with nested AutoConfig.from_pretrained() calls. Other model types that do not use the LightGlue loading path are not affected by this specific CVE, though related trust_remote_code bypass vulnerabilities (CVE-2026-4372) affect other Transformers code paths in versions prior to 5.3.0.

Vendor Security History

According to OpenCVE, HuggingFace has at least 42 CVEs across its product portfolio, in Transformers, Diffusers, Smolagents, LeRobot, Accelerate, and Text Generation Inference. The issues mostly fall into three patterns:

The trust_remote_code bypass keeps recurring across products. CVE-2026-4372 affects Transformers prior to 5.3.0 and allows a crafted config.json with an _attn_implementation_internal field to bypass the trust_remote_code mechanism. CVE-2026-44513 is a Diffusers trust_remote_code bypass in which the security gate was implemented inside download() rather than at the dynamic module load site. CVE-2026-44827 allows RCE without trust_remote_code=True through string interpolation on the custom_pipeline parameter in Diffusers.

Threat actors have also been active in the HuggingFace ecosystem. Attackers weaponized CVE-2026-39987 to deploy the NKAbuse blockchain botnet via HuggingFace, which shows that the model distribution ecosystem is a recognized and actively exploited attack surface.

HuggingFace uses the Huntr bug bounty platform for vulnerability disclosure. Kim Myeong Hyun (@dev-mhyun) reported CVE-2026-5241 on February 26, 2026. NVD published it on June 3, 2026, so disclosure took several months.

References

• NVD: CVE-2026-5241
• Huntr Bounty Report: CVE-2026-5241
• GitHub Commit 676559d: Remove remote code execution from LightGlue (PR #45122)
• CWE-829: Inclusion of Functionality from Untrusted Control Sphere
• HuggingFace CVEs and Security Vulnerabilities (OpenCVE)
• Transformers CVEs and Security Vulnerabilities (OpenCVE)
• CVE-2026-39987: How Attackers Weaponized Marimo to Deploy a Blockchain Botnet via HuggingFace (Sysdig)
• CVE-2026-25874: Hugging Face LeRobot Unauthenticated RCE via Pickle Deserialization (Resecurity)
• Quantifying 2026 Routinely Targeted Vulnerabilities (VulnCheck)
• CISA Known Exploited Vulnerabilities Catalog
• LightGlue configuration_lightglue.py (current source)
• How to avoid trust_remote_code=True for my models (HuggingFace Forums)