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

Introduction

A security boundary that users explicitly set to "off" should not be silently overridden by data from an untrusted source. Yet that is precisely what happens in CVE-2026-5241: 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, resulting in arbitrary Python code execution during model initialization.

HuggingFace Transformers is the most widely used open source ML framework, with over 161k GitHub stars and deep integration into research and production ML workflows worldwide. Its Hub hosts hundreds of thousands of models, making it the de facto distribution platform for ML models. This vulnerability turns that distribution infrastructure into a potential attack vector: any user loading 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." In this case, the executable functionality is attacker provided Python modules imported via the auto_map mechanism in config.json from an untrusted model repository.

The vulnerability resides in the LightGlueConfig class within 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 intended to allow the use of keypoint detectors not registered in the CONFIG_MAPPING dictionary, such as DISK.

The fundamental flaw is architectural: 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, the LightGlueConfig reads the trust_remote_code value from the serialized config.json and treats it as authoritative.

Attack Flow

The exploitation chain proceeds through five steps:

1. Victim initiates model loading: A user calls AutoModel.from_pretrained("attacker/model") with trust_remote_code=False, explicitly disabling remote code execution.

2. LightGlueConfig reads attacker controlled config: 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. Attacker's value overrides caller's policy: 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. Nested repository triggers dynamic import: 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. Arbitrary code executes at import time: The malicious module contains import time side effects that execute immediately, achieving arbitrary code execution in the victim's environment.

CVSS v3 Scoring

The High attack complexity reflects the need for the attacker to control both a model repository and a nested configuration target repository. User interaction is required because the victim must load the attacker's model. The Scope Changed designation indicates the vulnerability affects resources beyond the security scope managed by the security authority (the caller's trust_remote_code setting). High confidentiality and integrity impacts reflect the potential for credential theft and arbitrary code execution.

Broader Pattern: Recurring trust_remote_code Bypasses

This vulnerability is not an isolated incident. It is one of at least four trust_remote_code bypass vulnerabilities identified in the HuggingFace ecosystem:

All four share the same root cause: security enforcement is placed at a level where untrusted configuration data can override it.

Detection Methods

CVE-2026-5241 targets the LightGlue model loading path, where a poisoned model configuration initiates the exploitation chain rather than a traditional network based exploit. Detection therefore focuses on inspecting model artifacts, monitoring runtime behavior, and leveraging static analysis.

Inspecting Model Configuration Files for Malicious Patterns

The most direct detection approach involves examining config.json files in model repositories before or during loading. Two telltale configuration patterns serve as Indicators of Compromise:

In the main LightGlue model repository's config.json, look for the combination of "model_type": "lightglue" alongside "trust_remote_code": true. A legitimately published LightGlue model would not typically need to set this flag to true at the config level. The presence of this field in a repository you did not author 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, for example entries like "AutoConfig": "detector_config.DetectorConfig" or "AutoModelForKeypointDetection": "detector_model.DetectorModel". These auto_map entries instruct the loader to dynamically import attacker provided code, which is the actual execution vector.

Organizations that maintain model registries or operate inference servers should consider adding pre-load validation steps that scan 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. Monitor for unexpected file creation or modification events during model initialization, particularly in temporary directories or sensitive system paths.

Unexpected outbound network connections during model loading: The nested config resolution causes the loader to 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, unexpected network traffic to unfamiliar model repos during from_pretrained() calls is a strong behavioral signal.

Unexpected process spawning: Since the vulnerability enables arbitrary Python code execution at import time, any child processes or shell commands spawned during what should be a straightforward model load deserve investigation.

Static Analysis with the TRF014 Linter Rule

The fix commit (676559d) introduced a purpose built AST based linter rule designated TRF014 into the HuggingFace Transformers mlinter tooling. This rule statically detects usage of trust_remote_code within 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 rule's rationale, as stated in the commit, is that native integrations must not depend on trust_remote_code because remote code cannot be reviewed or maintained within Transformers. Teams contributing to or forking the Transformers codebase can run this linter against their model integration files to detect any reintroduction of the vulnerable pattern.

Log Based Detection

Within application logs, defenders should watch for discrepancies between the user supplied trust_remote_code value and the value that actually takes effect during config resolution. Specifically, if your logging captures AutoConfig.from_pretrained() invocations, look for cases where a nested call resolves with trust_remote_code=True despite the top level call explicitly setting it to False. Additionally, recursive AutoConfig.from_pretrained() calls initiated from within LightGlueConfig.__post_init__() are a hallmark of this exploit chain, since the vulnerable code path triggered nested pretrained config loading when the detector model type was not in CONFIG_MAPPING.

At the time of this writing, no formal Sigma, YARA, Snort, or Suricata rules have been published for CVE-2026-5241. Detection remains primarily artifact based (config inspection), behavioral (runtime monitoring), and code level (static linting).

Affected Systems and Versions

Based on the NVD advisory and Huntr report, the following is confirmed affected:

• huggingface/transformers version 5.2.0: Specifically the LightGlue model loading path via AutoModel.from_pretrained() when loading 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

HuggingFace has accumulated at least 42 CVEs across its product portfolio according to OpenCVE, spanning Transformers, Diffusers, Smolagents, LeRobot, Accelerate, and Text Generation Inference. The security issues predominantly fall into three patterns:

The recurring trust_remote_code bypass pattern is particularly notable. CVE-2026-4372 affects Transformers prior to 5.3.0 and allows crafted config.json with _attn_implementation_internal field to bypass the trust_remote_code mechanism. CVE-2026-44513 affects Diffusers and represents a trust_remote_code bypass where 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.

Beyond vulnerability counts, the HuggingFace ecosystem has seen active threat actor engagement. CVE-2026-39987 was weaponized by attackers to deploy the NKAbuse blockchain botnet via HuggingFace, demonstrating that the model distribution ecosystem is a recognized and actively exploited attack surface.

HuggingFace engages with the Huntr bug bounty platform for vulnerability disclosure. The reporter of CVE-2026-5241 is Kim Myeong Hyun (@dev-mhyun), who reported the vulnerability on February 26, 2026. The NVD publication date of June 3, 2026 indicates a multi-month disclosure timeline.

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)