Hugging Face Transformers LightGlue loading: a model's config can override trust_remote_code=False and run the model's own code

Who is affected

Hugging Face Transformers is a Python library for downloading and running AI models. Some models ship with their own Python code (“remote code”). The library won’t run it by default unless the caller explicitly passes trust_remote_code=True. This bug let the loading path for LightGlue (a model that matches features between two images) get around that default.

Preconditions: you must be on an affected version and load a LightGlue-type model that an attacker made or altered. That could be a person, or automation such as CI (automated build-and-test pipelines), model evaluation workers or inference servers. On affected versions, setting trust_remote_code=False yourself does not help, because that is exactly the setting that gets overridden.

How it works

LightGlue works alongside a “keypoint detector” model (usually SuperPoint). In affected versions, LightGlueConfig accepted trust_remote_code as an ordinary config field (default False) and stored it on the config object. When the nested detector config named a model type the library didn’t recognise, the code loaded that config from a model repository and passed along the config object’s own trust_remote_code value rather than the caller’s choice.

PlainCVE’s reading (not spelled out word for word by an official source): a value stored on the config object ends up in the model’s config.json, which the model’s publisher controls. The advisory’s wording, that the setting is overridden by untrusted configuration data, fits this. The weakness maps to CWE-829 (inclusion of functionality from an untrusted control sphere).

The flawed approach (conceptual illustration, not the original source code):

class PairMatcherConfig:
    def __init__(self, detector_config, trust_remote_code=False, **kwargs):
        # The safety switch is an ordinary field, so it travels with the model's config.json
        self.trust_remote_code = trust_remote_code
        if detector_config["model_type"] not in BUILTIN_MODELS:
            detector_config = load_config_from_repo(
                detector_config,
                trust_remote_code=self.trust_remote_code,  # value comes from model data
            )

The fixed approach:

class PairMatcherConfig:
    def __init__(self, detector_config, **kwargs):
        # Never take the safety switch from model data; pick only from the built-in list
        if detector_config["model_type"] not in BUILTIN_MODELS:
            raise ValueError("Only built-in keypoint detectors are supported")
        detector_config = BUILTIN_MODELS[detector_config["model_type"]](**detector_config)

The fix (PR #45122) also adds a linter rule, TRF014, that flags trust_remote_code in the library’s built-in model code. A reviewer noted that dynamically built arguments could still slip past a static check, so the rule lowers the risk rather than guaranteeing against it.

Timeline

The fix was public about two months before the CVE. The v5.5.0 release page summary once showed “April 2, 2025”, but the GitHub API gives 2026-04-02, and the fix was only merged on 2026-03-31, so 2026-04-02 is used here.

Further reading

• The scores differ widely: NVD gives CVSS 3.1 9.6 (Critical), huntr (the CNA that assigned the CVE) gives CVSS 3.0 8.0, and Red Hat gives CVSS 3.1 7.7 (Red Hat rating “Important”). They disagree on attack complexity (NVD Low, the others High), privileges required (Red Hat Low, the others None) and availability impact (NVD High, the others None). All three require user interaction.
• Exploitation: no source reports exploitation in the wild, and this CVE is not in CISA KEV. The GitHub advisory listed EPSS (a predicted likelihood of exploitation) at about 0.6% when checked.
• Reporter: the original huntr report could not be read, so the reporter and report date are unconfirmed.
• Supply-chain lesson: models behave like code dependencies, and one field in a config file was enough to switch off a safety setting. Exposed environments include inference API servers, research notebooks, CI/CD pipelines and model evaluation workers.