Common Weakness Enumeration

CWE-915

Allowed

Improperly Controlled Modification of Dynamically-Determined Object Attributes

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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-5448-V74M-7MV7

Vulnerability from github – Published: 2026-03-06 18:31 – Updated: 2026-03-07 02:33
VLAI
Summary
Snipe-IT has sensitive user attributes related to account privileges that are insufficiently protected against mass assignment
Details

Snipe-IT versions prior to 8.3.7 contain sensitive user attributes related to account privileges that are insufficiently protected against mass assignment. An authenticated, low-privileged user can craft a malicious API request to modify restricted fields of another user account, including the Super Admin account. By changing the email address of the Super Admin and triggering a password reset, an attacker can fully take over the Super Admin account, resulting in complete administrative control of the Snipe-IT instance.

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "snipe/snipe-it"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.3.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-15602"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-07T02:33:40Z",
    "nvd_published_at": "2026-03-06T17:16:24Z",
    "severity": "HIGH"
  },
  "details": "Snipe-IT versions prior to 8.3.7 contain sensitive user attributes related to account privileges that are insufficiently protected against mass assignment. An authenticated, low-privileged user can craft a malicious API request to modify restricted fields of another user account, including the Super Admin account. By changing the email address of the Super Admin and triggering a password reset, an attacker can fully take over the Super Admin account, resulting in complete administrative control of the Snipe-IT instance.",
  "id": "GHSA-5448-v74m-7mv7",
  "modified": "2026-03-07T02:33:40Z",
  "published": "2026-03-06T18:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15602"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/grokability/snipe-it"
    },
    {
      "type": "WEB",
      "url": "https://github.com/grokability/snipe-it/releases/tag/v8.3.7"
    },
    {
      "type": "WEB",
      "url": "https://snipeitapp.com"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/snipe-it-mass-assignment-vulnerability-leading-to-privilege-escalation"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Snipe-IT has sensitive user attributes related to account privileges that are insufficiently protected against mass assignment"
}

GHSA-59FH-9F3P-7M39

Vulnerability from github – Published: 2026-05-20 15:44 – Updated: 2026-05-20 15:44
VLAI
Summary
Flowise: Mass Assignment in PUT /api/v1/user Allows Authenticated Users to Override Password Hash and Bypass Password Change Verification
Details

Summary

A Mass Assignment vulnerability in the PUT /api/v1/user endpoint allows authenticated users to directly modify restricted user fields, including the credential (password hash), bypassing the intended password change workflow.

Because the endpoint forwards the entire request body to the service layer without filtering, an attacker can override the credential field without providing the current password.

This bypasses several security protections including:

  • old password verification
  • password hashing enforcement
  • password policy validation
  • session invalidation on password change

While the vulnerability cannot be used to modify other users due to an ID check in the controller, it allows attackers who obtain a temporary session (e.g., via token theft or XSS) to establish persistent account access.

Details

The endpoint PUT /api/v1/user allows authenticated users to update their user profile.

The controller checks that the authenticated user matches the provided id, preventing direct IDOR:

const currentUser = req.user
const { id } = req.body

if (currentUser.id !== id) {
    throw new InternalFlowiseError(StatusCodes.FORBIDDEN)
}

However, the controller forwards the entire request body directly to the service layer without filtering:

const user = await userService.updateUser(req.body)

Inside UserService.updateUser, the incoming data is merged into the existing user entity:

updatedUser = queryRunner.manager.merge(User, oldUserData, newUserData)

Because newUserData is derived from req.body and there is no field allowlist, any field present in the User entity may be modified.

This includes sensitive fields such as:

  • credential
  • tempToken
  • tokenExpiry
  • status
  • email

The service implements a secure password change workflow that requires the following fields:

oldPassword
newPassword
confirmPassword

Example code:

if (newUserData.oldPassword && newUserData.newPassword && newUserData.confirmPassword) {
    if (!compareHash(newUserData.oldPassword, oldUserData.credential)) {
        throw new InternalFlowiseError(StatusCodes.BAD_REQUEST)
    }

    newUserData.credential = this.encryptUserCredential(newUserData.newPassword)
}

However, this logic can be bypassed by directly supplying a credential value in the request body.

Because the merge operation applies all fields from newUserData, the supplied credential hash will overwrite the stored password hash.

PoC

Step 1 - Authenticate

Login as any normal user and obtain a valid JWT token.

POST /api/v1/auth/login

Step 2 - Generate a password hash

Generate a bcrypt hash for a password you control.

Example:

bcrypt("attacker_password")

Example hash:

$2b$10$abc123examplehashvalue...

Step 3 - Send crafted update request

PUT /api/v1/user
Authorization: Bearer <JWT_TOKEN>
Content-Type: application/json

{
  "id": "<your-user-id>",
  "credential": "$2b$10$abc123examplehashvalue..."
}

Step 4 - Login with attacker password

The password hash in the database is replaced by the supplied value.

The attacker can now authenticate using:

attacker_password

without ever providing the previous password.

Impact

This vulnerability allows authenticated users to bypass the password change security controls.

Security protections that are bypassed include:

current password verification

password hashing enforcement

password policy validation

session invalidation on password change

Although the controller prevents modification of other users' accounts, the vulnerability enables persistence after account compromise.

Example attack scenario:

  • An attacker temporarily obtains a user's session (XSS, token leak, shared device, etc.)
  • The attacker sends the crafted update request with a new password hash
  • The attacker now permanently controls the account
  • Authentication logic bypass
  • Privilege persistence after compromise
  • Weak account recovery guarantees
Severity
6.0 (Medium)
CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "flowise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-20T15:44:40Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nA Mass Assignment vulnerability in the PUT /api/v1/user endpoint allows authenticated users to directly modify restricted user fields, including the credential (password hash), bypassing the intended password change workflow.\n\nBecause the endpoint forwards the entire request body to the service layer without filtering, an attacker can override the credential field without providing the current password.\n\nThis bypasses several security protections including:\n\n- old password verification\n- password hashing enforcement\n- password policy validation\n- session invalidation on password change\n\nWhile the vulnerability cannot be used to modify other users due to an ID check in the controller, it allows attackers who obtain a temporary session (e.g., via token theft or XSS) to establish persistent account access.\n\n### Details\nThe endpoint **PUT /api/v1/user** allows authenticated users to update their user profile.\n\nThe controller checks that the authenticated user matches the provided id, preventing direct IDOR:\n\n```typescript\nconst currentUser = req.user\nconst { id } = req.body\n\nif (currentUser.id !== id) {\n    throw new InternalFlowiseError(StatusCodes.FORBIDDEN)\n}\n```\n\nHowever, the controller forwards the entire request body directly to the service layer without filtering:\n\n```typescript\nconst user = await userService.updateUser(req.body)\n```\n\nInside UserService.updateUser, the incoming data is merged into the existing user entity:\n\n```typescript\nupdatedUser = queryRunner.manager.merge(User, oldUserData, newUserData)\n```\n\nBecause newUserData is derived from req.body and there is no field allowlist, any field present in the User entity may be modified.\n\nThis includes sensitive fields such as:\n\n- credential\n- tempToken\n- tokenExpiry\n- status\n- email\n\nThe service implements a secure password change workflow that requires the following fields:\n\n```typescript\noldPassword\nnewPassword\nconfirmPassword\n\n```\n\nExample code:\n\n```typescript\nif (newUserData.oldPassword \u0026\u0026 newUserData.newPassword \u0026\u0026 newUserData.confirmPassword) {\n    if (!compareHash(newUserData.oldPassword, oldUserData.credential)) {\n        throw new InternalFlowiseError(StatusCodes.BAD_REQUEST)\n    }\n\n    newUserData.credential = this.encryptUserCredential(newUserData.newPassword)\n}\n```\nHowever, this logic can be bypassed by directly supplying a credential value in the request body.\n\nBecause the merge operation applies all fields from newUserData, the supplied credential hash will overwrite the stored password hash.\n\n### PoC\n**Step 1 -  Authenticate**\n\nLogin as any normal user and obtain a valid JWT token.\n\n**POST /api/v1/auth/login**\n\n**Step 2 - Generate a password hash**\n\nGenerate a bcrypt hash for a password you control.\n\nExample:\n\nbcrypt(\"attacker_password\")\n\nExample hash:\n\n$2b$10$abc123examplehashvalue...\n\nStep 3 - Send crafted update request\n\n```http\nPUT /api/v1/user\nAuthorization: Bearer \u003cJWT_TOKEN\u003e\nContent-Type: application/json\n\n{\n  \"id\": \"\u003cyour-user-id\u003e\",\n  \"credential\": \"$2b$10$abc123examplehashvalue...\"\n}\n```\n\nStep 4 - Login with attacker password\n\nThe password hash in the database is replaced by the supplied value.\n\nThe attacker can now authenticate using:\n\n**attacker_password**\n\nwithout ever providing the previous password.\n\n### Impact\nThis vulnerability allows authenticated users to bypass the password change security controls.\n\nSecurity protections that are bypassed include:\n\ncurrent password verification\n\npassword hashing enforcement\n\npassword policy validation\n\nsession invalidation on password change\n\nAlthough the controller prevents modification of other users\u0027 accounts, the vulnerability enables persistence after account compromise.\n\nExample attack scenario:\n\n- An attacker temporarily obtains a user\u0027s session (XSS, token leak, shared device, etc.)\n- The attacker sends the crafted update request with a new password hash\n- The attacker now permanently controls the account\n- Authentication logic bypass\n- Privilege persistence after compromise\n- Weak account recovery guarantees",
  "id": "GHSA-59fh-9f3p-7m39",
  "modified": "2026-05-20T15:44:40Z",
  "published": "2026-05-20T15:44:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-59fh-9f3p-7m39"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FlowiseAI/Flowise"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Flowise: Mass Assignment in PUT /api/v1/user Allows Authenticated Users to Override Password Hash and Bypass Password Change Verification"
}

GHSA-5H9V-837X-M97R

Vulnerability from github – Published: 2026-05-14 16:19 – Updated: 2026-07-07 13:34
VLAI
Summary
FlowiseAI: Dataset create+update mass-assignment allows cross-workspace dataset takeover
Details

Summary

Type: Mass assignment via Object.assign(entity, body) -> client-controlled workspaceId (and on create, id) overwritten on the Dataset entity -> cross-workspace data takeover and IDOR. File: packages/server/src/services/dataset/index.ts Root cause: The Dataset controller/service constructs a new Dataset() and copies the request body into it via Object.assign(...) without an explicit field allowlist. The request body therefore can include workspaceId, id, createdDate, updatedDate. The server only rebinds some of these after the assign (e.g. on create, it overwrites workspaceId but not id; on update, it overwrites id but not workspaceId). The remaining client-controlled values land directly on the persisted row, breaking workspace isolation. Same root pattern as the dataset entity's sibling controllers and as DocumentStore before it was patched in commit 840d2ae.

Affected Code

File: packages/server/src/services/dataset/index.ts

// create (line 203) and update (line 226)
Object.assign(newDataset, body)         // <-- BUG: body.id, body.workspaceId accepted

Why it's wrong: Object.assign(target, source) copies every own enumerable property of source onto target. The TypeORM/SQL persistence layer below it does not strip ownership-bearing columns, so workspaceId set in the request body lands as the new workspaceId of the persisted row. The DocumentStore patch (commit 840d2ae) demonstrated the intended fix shape (explicit field-by-field allowlist) but it has not been applied to this entity.

Exploit Chain

  1. Attacker is an authenticated member of workspace A. They have a session cookie / JWT for the Flowise web UI. State at this point: attacker can read and write entities scoped to workspace A.
  2. Attacker creates a dataset in workspace A via the documented API (or reuses an existing one they own). They note its entity id.
  3. Attacker issues a PUT /api/v1/datasets/<id> (or equivalent endpoint) with a JSON body that includes "workspaceId": "<workspace-B-id>" (an arbitrary other workspace's UUID). State at this point: the request reaches the controller as a workspace-A authenticated request.
  4. The controller calls Object.assign(updateEntity, body). The body's workspaceId overwrites the entity's workspaceId field. The persistence layer commits the row.
  5. Final state: the dataset row is now owned by workspace B. Workspace B members can see it, modify it, and use it. Workspace A loses access (it no longer satisfies their workspace filter). The original creator's workspace audit shows nothing because the operation looked like a normal update.

Security Impact

Severity: High. Cross-workspace boundary violation by any authenticated workspace member. Attacker capability: Any authenticated user with permission to update a dataset can move it to any workspace whose UUID they can guess or enumerate (workspace UUIDs are exposed in many API responses, so enumeration is trivial). Datasets hold training / evaluation data scoped to a workspace. Moving a Dataset across workspaces via workspaceId overwrite exposes the dataset (rows, schema, references) to the destination workspace. Preconditions: Authenticated session with edit permission for the source dataset. No second factor required. Workspace UUIDs are exposed via the /api/v1/workspaces listing or via any cross-referenced object's workspaceId field, so target enumeration is trivial. Differential: PoC-verified by source inspection of the original GHSA-q4pr-4r26-c69r. Patched build (with the suggested fix below) refuses the workspaceId field; vulnerable build accepts it and persists it.

Suggested Fix

Already fixed in PR https://github.com/FlowiseAI/Flowise/pull/6051 (allowlist pattern applied).

// Allowlist pattern (matches commit 840d2ae for DocumentStore):
const updatedDataset = new Dataset()
if (body.<allowed_field_1> !== undefined) updatedDataset.<allowed_field_1> = body.<allowed_field_1>
if (body.<allowed_field_2> !== undefined) updatedDataset.<allowed_field_2> = body.<allowed_field_2>
// ...whitelist only the documented fields. Never copy id, workspaceId, createdDate, updatedDate from the client.

Regression tests should assert that a request body containing workspaceId, id, createdDate, or updatedDate is rejected (or at minimum: does not change those columns on the persisted row) for both create and update paths.

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
7.7 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "flowise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46477"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T16:19:39Z",
    "nvd_published_at": "2026-06-08T16:16:42Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n**Type:** Mass assignment via `Object.assign(entity, body)` -\u003e client-controlled `workspaceId` (and on create, `id`) overwritten on the Dataset entity -\u003e cross-workspace data takeover and IDOR.\n**File:** `packages/server/src/services/dataset/index.ts`\n**Root cause:** The Dataset controller/service constructs a `new Dataset()` and copies the request body into it via `Object.assign(...)` without an explicit field allowlist. The request body therefore can include `workspaceId`, `id`, `createdDate`, `updatedDate`. The server only rebinds *some* of these after the assign (e.g. on create, it overwrites `workspaceId` but not `id`; on update, it overwrites `id` but not `workspaceId`). The remaining client-controlled values land directly on the persisted row, breaking workspace isolation. Same root pattern as the dataset entity\u0027s sibling controllers and as `DocumentStore` before it was patched in commit 840d2ae.\n\n## Affected Code\n\n**File:** `packages/server/src/services/dataset/index.ts`\n\n```ts\n// create (line 203) and update (line 226)\nObject.assign(newDataset, body)         // \u003c-- BUG: body.id, body.workspaceId accepted\n```\n\n**Why it\u0027s wrong:** `Object.assign(target, source)` copies every own enumerable property of `source` onto `target`. The TypeORM/SQL persistence layer below it does not strip ownership-bearing columns, so `workspaceId` set in the request body lands as the new `workspaceId` of the persisted row. The DocumentStore patch (commit 840d2ae) demonstrated the intended fix shape (explicit field-by-field allowlist) but it has not been applied to this entity.\n\n## Exploit Chain\n\n1. Attacker is an authenticated member of workspace A. They have a session cookie / JWT for the Flowise web UI. State at this point: attacker can read and write entities scoped to workspace A.\n2. Attacker creates a dataset in workspace A via the documented API (or reuses an existing one they own). They note its entity `id`.\n3. Attacker issues a `PUT /api/v1/datasets/\u003cid\u003e` (or equivalent endpoint) with a JSON body that includes `\"workspaceId\": \"\u003cworkspace-B-id\u003e\"` (an arbitrary other workspace\u0027s UUID). State at this point: the request reaches the controller as a workspace-A authenticated request.\n4. The controller calls `Object.assign(updateEntity, body)`. The body\u0027s `workspaceId` overwrites the entity\u0027s `workspaceId` field. The persistence layer commits the row.\n5. Final state: the dataset row is now owned by workspace B. Workspace B members can see it, modify it, and use it. Workspace A loses access (it no longer satisfies their workspace filter). The original creator\u0027s workspace audit shows nothing because the operation looked like a normal update.\n\n## Security Impact\n\n**Severity:** High. Cross-workspace boundary violation by any authenticated workspace member.\n**Attacker capability:** Any authenticated user with permission to update a dataset can move it to any workspace whose UUID they can guess or enumerate (workspace UUIDs are exposed in many API responses, so enumeration is trivial). Datasets hold training / evaluation data scoped to a workspace. Moving a Dataset across workspaces via `workspaceId` overwrite exposes the dataset (rows, schema, references) to the destination workspace.\n**Preconditions:** Authenticated session with edit permission for the source dataset. No second factor required. Workspace UUIDs are exposed via the `/api/v1/workspaces` listing or via any cross-referenced object\u0027s `workspaceId` field, so target enumeration is trivial.\n**Differential:** PoC-verified by source inspection of the original GHSA-q4pr-4r26-c69r. Patched build (with the suggested fix below) refuses the `workspaceId` field; vulnerable build accepts it and persists it.\n\n## Suggested Fix\n\nAlready fixed in PR https://github.com/FlowiseAI/Flowise/pull/6051 (allowlist pattern applied).\n\n```ts\n// Allowlist pattern (matches commit 840d2ae for DocumentStore):\nconst updatedDataset = new Dataset()\nif (body.\u003callowed_field_1\u003e !== undefined) updatedDataset.\u003callowed_field_1\u003e = body.\u003callowed_field_1\u003e\nif (body.\u003callowed_field_2\u003e !== undefined) updatedDataset.\u003callowed_field_2\u003e = body.\u003callowed_field_2\u003e\n// ...whitelist only the documented fields. Never copy id, workspaceId, createdDate, updatedDate from the client.\n```\n\nRegression tests should assert that a request body containing `workspaceId`, `id`, `createdDate`, or `updatedDate` is rejected (or at minimum: does not change those columns on the persisted row) for both create and update paths.",
  "id": "GHSA-5h9v-837x-m97r",
  "modified": "2026-07-07T13:34:10Z",
  "published": "2026-05-14T16:19:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-5h9v-837x-m97r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46477"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/pull/6051"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/commit/49a2259bf2a6b4f3d4b50813cb5161cee0d40040"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FlowiseAI/Flowise"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise%403.1.2"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "FlowiseAI: Dataset create+update mass-assignment allows cross-workspace dataset takeover"
}

GHSA-5JMJ-H7XM-6Q6V

Vulnerability from github – Published: 2026-06-23 21:23 – Updated: 2026-06-30 21:06
VLAI
Summary
jackson-databind has case-insensitive deserialization bypasses per-property @JsonIgnoreProperties
Details

Summary

In BeanDeserializerBase.createContextual(), per-property @JsonIgnoreProperties exclusions are applied by _handleByNameInclusion(), producing a contextual deserializer whose BeanPropertyMap has the ignored properties removed. The subsequent per-property case-insensitivity block (triggered by @JsonFormat(ACCEPT_CASE_INSENSITIVE_PROPERTIES)) rebuilds from this._beanProperties (the original, unfiltered map) instead of contextual._beanProperties, then overwrites the filtered map — restoring every property _handleByNameInclusion had just removed. The ignored property becomes writable again.

Impact

An application that both enables case-insensitive matching and relies on per-property @JsonIgnoreProperties to keep a field unwritable can have that field set from untrusted JSON (mass-assignment-style write).

Affected / Patched

Will be fixed in 2.18.9, 2.21.5, 2.22.1 and 3.1.4.

Severity / CWE

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

Upstream fix

FasterXML/jackson-databind#5962 (PR #5964, 0e1b0b2), milestone 3.1.4. Released 2026-06-04.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 3.1.4"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "tools.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.1.0"
            },
            {
              "fixed": "3.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 2.18.9"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 2.21.5"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.19.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 2.22.1"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54515"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-23T21:23:58Z",
    "nvd_published_at": "2026-06-23T21:17:02Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\nIn `BeanDeserializerBase.createContextual()`, per-property `@JsonIgnoreProperties` exclusions are applied by `_handleByNameInclusion()`, producing a `contextual` deserializer whose `BeanPropertyMap` has the ignored properties removed. The subsequent per-property case-insensitivity block (triggered by `@JsonFormat(ACCEPT_CASE_INSENSITIVE_PROPERTIES)`) rebuilds from `this._beanProperties` (the original, unfiltered map) instead of `contextual._beanProperties`, then overwrites the filtered map \u2014 restoring every property `_handleByNameInclusion` had just removed. The ignored property becomes writable again.\n\n## Impact\nAn application that both enables case-insensitive matching and relies on per-property `@JsonIgnoreProperties` to keep a field unwritable can have that field set from untrusted JSON (mass-assignment-style write).\n\n## Affected / Patched\nWill be fixed in 2.18.9, 2.21.5, 2.22.1 and 3.1.4.\n\n## Severity / CWE\nMaintainer: minor. Reporter: Moderate. CWE-915.\n\n## Upstream fix\nFasterXML/jackson-databind#5962 (PR #5964, `0e1b0b2`), milestone 3.1.4. Released 2026-06-04.",
  "id": "GHSA-5jmj-h7xm-6q6v",
  "modified": "2026-06-30T21:06:37Z",
  "published": "2026-06-23T21:23:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/security/advisories/GHSA-5jmj-h7xm-6q6v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54515"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/issues/5962"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/issues/5964"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/commit/0e1b0b211f7a53baa62ba2f4c9bd006c7bf4d5fa"
    },
    {
      "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 has case-insensitive deserialization bypasses per-property @JsonIgnoreProperties"
}

GHSA-5R9F-76WQ-X3P4

Vulnerability from github – Published: 2023-09-02 15:30 – Updated: 2024-04-04 07:22
VLAI
Details

A vulnerability that poses a potential risk of polluting the MXsecurity sqlite database and the nsm-web UI has been identified in MXsecurity versions prior to v1.0.1. This vulnerability might allow an unauthenticated remote attacker to register or add devices via the nsm-web application.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-39983"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-913",
      "CWE-915"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-02T13:15:45Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability that poses a potential risk of polluting the MXsecurity sqlite database and the nsm-web UI has been identified in MXsecurity versions prior to v1.0.1. This vulnerability might allow an unauthenticated remote attacker to register or add devices via the nsm-web application.\n\n",
  "id": "GHSA-5r9f-76wq-x3p4",
  "modified": "2024-04-04T07:22:22Z",
  "published": "2023-09-02T15:30:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39983"
    },
    {
      "type": "WEB",
      "url": "https://www.moxa.com/en/support/product-support/security-advisory/mpsa-230403-mxsecurity-series-multiple-vulnerabilities"
    }
  ],
  "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"
    }
  ]
}

GHSA-5V7G-9H8F-8PGG

Vulnerability from github – Published: 2026-03-17 18:37 – Updated: 2026-03-19 21:13
VLAI
Summary
Parse Server session creation endpoint allows overwriting server-generated session fields
Details

Impact

An authenticated user can overwrite server-generated session fields (sessionToken, expiresAt, createdWith) when creating a session object via POST /classes/_Session. This allows bypassing the server's session expiration policy by setting an arbitrary far-future expiration date. It also allows setting a predictable session token value.

Patches

The session creation endpoint now filters out server-generated fields from user-supplied data, preventing them from being overwritten.

Workarounds

Add a beforeSave trigger on the _Session class to validate and reject or strip any user-supplied values for sessionToken, expiresAt, and createdWith.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "9.6.0-alpha.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.6.42"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32742"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-17T18:37:23Z",
    "nvd_published_at": "2026-03-18T22:16:25Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nAn authenticated user can overwrite server-generated session fields (`sessionToken`, `expiresAt`, `createdWith`) when creating a session object via `POST /classes/_Session`. This allows bypassing the server\u0027s session expiration policy by setting an arbitrary far-future expiration date. It also allows setting a predictable session token value.\n\n### Patches\n\nThe session creation endpoint now filters out server-generated fields from user-supplied data, preventing them from being overwritten.\n\n### Workarounds\n\nAdd a `beforeSave` trigger on the `_Session` class to validate and reject or strip any user-supplied values for `sessionToken`, `expiresAt`, and `createdWith`.",
  "id": "GHSA-5v7g-9h8f-8pgg",
  "modified": "2026-03-19T21:13:13Z",
  "published": "2026-03-17T18:37:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/security/advisories/GHSA-5v7g-9h8f-8pgg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32742"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/pull/10195"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/pull/10196"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/parse-community/parse-server"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Parse Server session creation endpoint allows overwriting server-generated session fields"
}

GHSA-5WXP-QJGQ-FX6M

Vulnerability from github – Published: 2026-05-14 14:54 – Updated: 2026-06-09 13:10
VLAI
Summary
FlowiseAI has Mass Assignment in Chatflow Update Endpoint that Allows Cross-Workspace AgentFlow Reassignment
Details

Summary

A Mass Assignment vulnerability exists in the chatflow update endpoint of FlowiseAI.

The endpoint allows clients to modify server-controlled properties such as deployed, isPublic, workspaceId, createdDate, and updatedDate when updating a chatflow object.

Due to missing server-side validation and authorization checks, an authenticated user can manipulate internal attributes of a chatflow and reassign it to another workspace. This allows cross-workspace resource reassignment and unauthorized modification of deployment and visibility settings.

Details

The endpoint responsible for updating chatflows:

PUT /api/v1/chatflows/{chatflowId}

accepts a JSON request body containing the chatflow configuration (flowData) along with other metadata fields.

However, the server does not restrict which properties may be modified by the client. As a result, user-controlled request bodies can include additional fields that should normally be controlled only by the backend.

Examples of server-controlled fields that can be manipulated include:

  1. deployed
  2. isPublic
  3. workspaceId
  4. createdDate
  5. updatedDate
  6. category
  7. type

These fields appear to be directly mapped to the underlying database entity when processing the update request, suggesting that the server performs a direct merge of the request body into the chatflow model without applying a strict DTO whitelist or authorization checks.

For example, modifying the request body with:

{
  "deployed": true,
  "isPublic": true,
  "createdDate": "1999-03-06T10:59:32.000Z",
  "updatedDate": "1999-03-06T13:21:34.000Z",
  "workspaceId": "11111111-2222-3333-4444-555555555555"
}

results in the server accepting and persisting these values.

In testing, a second workspace was created in the database and the workspaceId field was successfully modified through the API request. The chatflow was reassigned to the attacker-controlled workspace, confirming that the application does not enforce workspace ownership validation.

PoC

Authenticate to the Flowise interface.

Capture the request used to update a chatflow:

PUT /api/v1/chatflows/<CHATFLOW_ID>
Content-Type: application/json

Modify the request body by injecting additional fields:

{
  "name": "test-flow",
  "flowData": "{...}",
  "deployed": true,
  "isPublic": true,
  "workspaceId": "11111111-2222-3333-4444-555555555555"
}

Send the request.

Observe that the response returns the manipulated values:

{
  "deployed": true,
  "isPublic": true,
  "workspaceId": "11111111-2222-3333-4444-555555555555"
}

Verify in the database that the chatflow has been reassigned:

SELECT id, workspaceId FROM chat_flow WHERE id='<CHATFLOW_ID>';

The workspaceId value reflects the attacker-supplied workspace.

Impact

This vulnerability allows authenticated users to manipulate server-controlled attributes of chatflows.

Confirmed impacts include:

  • Unauthorized modification of chatflow visibility (isPublic)
  • Unauthorized deployment state changes (deployed)
  • Cross-workspace reassignment of chatflows (workspaceId)
  • Unauthorized modification of metadata (createdDate, updatedDate)

In multi-tenant environments, this allows an attacker to move chatflows between workspaces without authorization, breaking tenant isolation boundaries.

This may enable:

  • Cross-workspace workflow takeover
  • Unauthorized exposure of private workflows
  • Manipulation of deployed agent workflows

The issue stems from missing authorization checks and improper handling of client-controlled input in the chatflow update endpoint.

Severity
7.6 (High)
CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "flowise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42863"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-639",
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T14:54:28Z",
    "nvd_published_at": "2026-06-08T16:16:39Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nA Mass Assignment vulnerability exists in the chatflow update endpoint of FlowiseAI.\n\nThe endpoint allows clients to modify server-controlled properties such as deployed, isPublic, workspaceId, createdDate, and updatedDate when updating a chatflow object.\n\nDue to missing server-side validation and authorization checks, an authenticated user can manipulate internal attributes of a chatflow and reassign it to another workspace. This allows cross-workspace resource reassignment and unauthorized modification of deployment and visibility settings.\n\n### Details\nThe endpoint responsible for updating chatflows:\n\n**PUT /api/v1/chatflows/{chatflowId}**\n\naccepts a JSON request body containing the chatflow configuration (flowData) along with other metadata fields.\n\nHowever, the server does not restrict which properties may be modified by the client. As a result, user-controlled request bodies can include additional fields that should normally be controlled only by the backend.\n\nExamples of server-controlled fields that can be manipulated include:\n\n1. deployed\n2. isPublic\n3. workspaceId\n4. createdDate\n5. updatedDate\n6. category\n7. type\n\nThese fields appear to be directly mapped to the underlying database entity when processing the update request, suggesting that the server performs a direct merge of the request body into the chatflow model without applying a strict DTO whitelist or authorization checks.\n\nFor example, modifying the request body with:\n\n```json\n{\n  \"deployed\": true,\n  \"isPublic\": true,\n  \"createdDate\": \"1999-03-06T10:59:32.000Z\",\n  \"updatedDate\": \"1999-03-06T13:21:34.000Z\",\n  \"workspaceId\": \"11111111-2222-3333-4444-555555555555\"\n}\n```\n\nresults in the server accepting and persisting these values.\n\nIn testing, a second workspace was created in the database and the workspaceId field was successfully modified through the API request. The chatflow was reassigned to the attacker-controlled workspace, confirming that the application does not enforce workspace ownership validation.\n\n\n### PoC\nAuthenticate to the Flowise interface.\n\nCapture the request used to update a chatflow:\n\n```http\nPUT /api/v1/chatflows/\u003cCHATFLOW_ID\u003e\nContent-Type: application/json\n\nModify the request body by injecting additional fields:\n\n{\n  \"name\": \"test-flow\",\n  \"flowData\": \"{...}\",\n  \"deployed\": true,\n  \"isPublic\": true,\n  \"workspaceId\": \"11111111-2222-3333-4444-555555555555\"\n}\n```\n\nSend the request.\n\nObserve that the response returns the manipulated values:\n\n```json\n{\n  \"deployed\": true,\n  \"isPublic\": true,\n  \"workspaceId\": \"11111111-2222-3333-4444-555555555555\"\n}\n```\n\nVerify in the database that the chatflow has been reassigned:\n\n```sql\nSELECT id, workspaceId FROM chat_flow WHERE id=\u0027\u003cCHATFLOW_ID\u003e\u0027;\n```\n\nThe workspaceId value reflects the attacker-supplied workspace.\n\n### Impact\nThis vulnerability allows authenticated users to manipulate server-controlled attributes of chatflows.\n\nConfirmed impacts include:\n\n- Unauthorized modification of chatflow visibility (isPublic)\n- Unauthorized deployment state changes (deployed)\n- Cross-workspace reassignment of chatflows (workspaceId)\n- Unauthorized modification of metadata (createdDate, updatedDate)\n\nIn multi-tenant environments, this allows an attacker to move chatflows between workspaces without authorization, breaking tenant isolation boundaries.\n\nThis may enable:\n\n- Cross-workspace workflow takeover\n- Unauthorized exposure of private workflows\n- Manipulation of deployed agent workflows\n\nThe issue stems from missing authorization checks and improper handling of client-controlled input in the chatflow update endpoint.",
  "id": "GHSA-5wxp-qjgq-fx6m",
  "modified": "2026-06-09T13:10:02Z",
  "published": "2026-05-14T14:54:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-5wxp-qjgq-fx6m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42863"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FlowiseAI/Flowise"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise%403.1.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "FlowiseAI has Mass Assignment in Chatflow Update Endpoint that Allows Cross-Workspace AgentFlow Reassignment"
}

GHSA-5XJX-4XCM-HPCM

Vulnerability from github – Published: 2021-12-10 18:53 – Updated: 2022-07-05 18:01
VLAI
Summary
Prototype Pollution in ts-nodash
Details

ts-nodash before version 1.2.7 is vulnerable to Prototype Pollution via the Merge() function due to lack of validation input.

Severity
7.3 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "ts-nodash"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-23403"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-07-06T14:35:53Z",
    "nvd_published_at": "2021-07-02T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "`ts-nodash` before version 1.2.7 is vulnerable to Prototype Pollution via the Merge() function due to lack of validation input.",
  "id": "GHSA-5xjx-4xcm-hpcm",
  "modified": "2022-07-05T18:01:53Z",
  "published": "2021-12-10T18:53:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23403"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BadOPCode/NoDash/commit/b9cc2b3b49f6cd5228e406bc57e17a28b998fea5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/BadOPCode/NoDash"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BadOPCode/NoDash/blob/master/src/Merge.ts"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-TSNODASH-1311009"
    }
  ],
  "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 ts-nodash"
}

GHSA-66RH-8FW6-59Q6

Vulnerability from github – Published: 2019-08-21 16:15 – Updated: 2022-08-03 16:21
VLAI
Summary
assign-deep Vulnerable to Prototype Pollution
Details

Versions of assign-deep prior to 1.0.1 and 0.4.8 are vulnerable to Prototype Pollution. The assign function fails to validate which Object properties it updates. This allows attackers to modify the prototype of Object, causing the addition or modification of an existing property on all objects.

Recommendation

Upgrade to versions 1.0.1, 0.4.8, or later.

Severity
7.5 (High)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "assign-deep"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.4.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "assign-deep"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.0.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2019-10745"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-20",
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2019-08-21T15:53:43Z",
    "nvd_published_at": "2019-08-20T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "Versions of `assign-deep` prior to 1.0.1 and 0.4.8 are vulnerable to Prototype Pollution. The `assign` function fails to validate which Object properties it updates. This allows attackers to modify the prototype of Object, causing the addition or modification of an existing property on all objects.\n\n## Recommendation\n\nUpgrade to versions 1.0.1, 0.4.8, or later.",
  "id": "GHSA-66rh-8fw6-59q6",
  "modified": "2022-08-03T16:21:27Z",
  "published": "2019-08-21T16:15:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10745"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jonschlinkert/assign-deep/commit/8e3cc4a34246733672c71e96532105384937e56c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jonschlinkert/assign-deep/commit/90bf1c551d05940898168d04066bbf15060f50cc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jonschlinkert/assign-deep"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-ASSIGNDEEP-450211"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/1014"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "assign-deep Vulnerable to Prototype Pollution"
}

GHSA-66VP-2CWC-4PV3

Vulnerability from github – Published: 2026-07-11 00:31 – Updated: 2026-07-13 18:30
VLAI
Details

Improperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in Drupal Flag attendance field allows Object Injection. This issue affects Flag attendance field versions: from 0.0.0 to 1.2.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-55809"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-915"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-10T22:16:43Z",
    "severity": "CRITICAL"
  },
  "details": "Improperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in Drupal Flag attendance field allows Object Injection. This issue affects Flag attendance field versions: from 0.0.0 to 1.2.",
  "id": "GHSA-66vp-2cwc-4pv3",
  "modified": "2026-07-13T18:30:34Z",
  "published": "2026-07-11T00:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55809"
    },
    {
      "type": "WEB",
      "url": "https://www.drupal.org/sa-contrib-2026-049"
    }
  ],
  "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"
    }
  ]
}
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.

← Back to the CWE list