CWE-1284
AllowedImproper Validation of Specified Quantity in Input
Abstraction: Base · Status: Incomplete
The product receives input that is expected to specify a quantity (such as size or length), but it does not validate or incorrectly validates that the quantity has the required properties.
493 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:53Summary
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, version0.28.16). - Deployed artefact validated:
kysely@0.28.16from 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(overridessanitizeStringLiteralbut 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 (andjsonb_sethelpers). 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 anadminflag 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, dynamicselectfor 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 writesdb as Kysely<any>(covered by the olderGHSA-wmrf-hv6w-mr66advisory) — but unlike that advisory, the bug here triggers in fully-typed code onRecord<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.
{
"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-PVMM-7C2R-WMP4
Vulnerability from github – Published: 2025-10-15 21:31 – Updated: 2026-05-19 18:32A data corruption vulnerability has been identified in the luksmeta utility when used with the LUKS1 disk encryption format. An attacker with the necessary permissions can exploit this flaw by writing a large amount of metadata to an encrypted device. The utility fails to correctly validate the available space, causing the metadata to overwrite and corrupt the user's encrypted data. This action leads to a permanent loss of the stored information. Devices using the LUKS formats other than LUKS1 are not affected by this issue.
{
"affected": [],
"aliases": [
"CVE-2025-11568"
],
"database_specific": {
"cwe_ids": [
"CWE-1284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-15T20:15:34Z",
"severity": "MODERATE"
},
"details": "A data corruption vulnerability has been identified in the luksmeta utility when used with the LUKS1 disk encryption format. An attacker with the necessary permissions can exploit this flaw by writing a large amount of metadata to an encrypted device. The utility fails to correctly validate the available space, causing the metadata to overwrite and corrupt the user\u0027s encrypted data. This action leads to a permanent loss of the stored information. Devices using the LUKS formats other than LUKS1 are not affected by this issue.",
"id": "GHSA-pvmm-7c2r-wmp4",
"modified": "2026-05-19T18:32:01Z",
"published": "2025-10-15T21:31:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11568"
},
{
"type": "WEB",
"url": "https://github.com/latchset/luksmeta/pull/16"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:23086"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:18421"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:18824"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2025-11568"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2404244"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PVW3-J77V-26W9
Vulnerability from github – Published: 2026-06-15 21:30 – Updated: 2026-06-15 21:30Unauthenticated Other Vulnerability Type in Contest Gallery <= 28.1.7 versions.
{
"affected": [],
"aliases": [
"CVE-2026-42657"
],
"database_specific": {
"cwe_ids": [
"CWE-1284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-15T21:16:55Z",
"severity": "MODERATE"
},
"details": "Unauthenticated Other Vulnerability Type in Contest Gallery \u003c= 28.1.7 versions.",
"id": "GHSA-pvw3-j77v-26w9",
"modified": "2026-06-15T21:30:47Z",
"published": "2026-06-15T21:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42657"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/contest-gallery/vulnerability/wordpress-contest-gallery-plugin-28-1-7-other-vulnerability-type-vulnerability?_s_id=cve"
}
],
"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-PXH3-RC47-3FVP
Vulnerability from github – Published: 2023-05-16 00:30 – Updated: 2024-04-04 04:11In m4u, there is a possible out of bounds write due to improper input validation. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07771518; Issue ID: ALPS07680084.
{
"affected": [],
"aliases": [
"CVE-2023-20722"
],
"database_specific": {
"cwe_ids": [
"CWE-1284",
"CWE-20"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-15T22:15:11Z",
"severity": "MODERATE"
},
"details": "In m4u, there is a possible out of bounds write due to improper input validation. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07771518; Issue ID: ALPS07680084.",
"id": "GHSA-pxh3-rc47-3fvp",
"modified": "2024-04-04T04:11:15Z",
"published": "2023-05-16T00:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20722"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/May-2023"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q36J-3HM6-HH2W
Vulnerability from github – Published: 2026-06-09 15:32 – Updated: 2026-07-09 00:31In the Linux kernel, the following vulnerability has been resolved:
mm/damon/core: disallow non-power of two min_region_sz on damon_start()
Commit d8f867fa0825 ("mm/damon: add damon_ctx->min_sz_region") introduced a bug that allows unaligned DAMON region address ranges. Commit c80f46ac228b ("mm/damon/core: disallow non-power of two min_region_sz") fixed it, but only for damon_commit_ctx() use case. Still, DAMON sysfs interface can emit non-power of two min_region_sz via damon_start(). Fix the path by adding the is_power_of_2() check on damon_start().
The issue was discovered by sashiko [1].
{
"affected": [],
"aliases": [
"CVE-2026-52905"
],
"database_specific": {
"cwe_ids": [
"CWE-1284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-09T14:16:44Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/core: disallow non-power of two min_region_sz on damon_start()\n\nCommit d8f867fa0825 (\"mm/damon: add damon_ctx-\u003emin_sz_region\") introduced\na bug that allows unaligned DAMON region address ranges. Commit\nc80f46ac228b (\"mm/damon/core: disallow non-power of two min_region_sz\")\nfixed it, but only for damon_commit_ctx() use case. Still, DAMON sysfs\ninterface can emit non-power of two min_region_sz via damon_start(). Fix\nthe path by adding the is_power_of_2() check on damon_start().\n\nThe issue was discovered by sashiko [1].",
"id": "GHSA-q36j-3hm6-hh2w",
"modified": "2026-07-09T00:31:06Z",
"published": "2026-06-09T15:32:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52905"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1de2db19a6028abe7d905875922faef5b873de67"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/89b6226b6c2a4add3939f361653a47c212d6ab75"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/95093e5cb4c5b50a5b1a4b79f2942b62744bd66a"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q72P-P7XM-7VMR
Vulnerability from github – Published: 2023-11-15 12:30 – Updated: 2023-11-15 12:30Improper Input Validation in Checkmk <2.2.0p15, <2.1.0p37, <=2.0.0p39 allows priviledged attackers to cause partial denial of service of the UI via too long hostnames.
{
"affected": [],
"aliases": [
"CVE-2023-23549"
],
"database_specific": {
"cwe_ids": [
"CWE-1284",
"CWE-20"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-15T11:15:08Z",
"severity": "LOW"
},
"details": "Improper Input Validation in Checkmk \u003c2.2.0p15, \u003c2.1.0p37, \u003c=2.0.0p39 allows priviledged attackers to cause partial denial of service of the UI via too long hostnames.",
"id": "GHSA-q72p-p7xm-7vmr",
"modified": "2023-11-15T12:30:30Z",
"published": "2023-11-15T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23549"
},
{
"type": "WEB",
"url": "https://checkmk.com/werk/16219"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-Q8QR-V893-9JP2
Vulnerability from github – Published: 2025-09-06 18:30 – Updated: 2025-09-06 18:30Improper input validation in AMD Power Management Firmware (PMFW) could allow a privileged attacker from Guest VM to send arbitrary input data potentially causing a GPU Reset condition.
{
"affected": [],
"aliases": [
"CVE-2024-36346"
],
"database_specific": {
"cwe_ids": [
"CWE-1284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-06T18:15:39Z",
"severity": "MODERATE"
},
"details": "Improper input validation in AMD Power Management Firmware (PMFW) could allow a privileged attacker from Guest VM to send arbitrary input data potentially causing a GPU Reset condition.",
"id": "GHSA-q8qr-v893-9jp2",
"modified": "2025-09-06T18:30:33Z",
"published": "2025-09-06T18:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36346"
},
{
"type": "WEB",
"url": "https://www.amd.com/en/resources/product-security/bulletin/AMD-SB-6018.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QCCM-7JQ2-92V7
Vulnerability from github – Published: 2024-08-31 09:30 – Updated: 2024-08-31 09:30NVIDIA CUDA Toolkit contains a vulnerability in command 'cuobjdump' where a user may cause a crash or produce incorrect output by passing a malformed ELF file. A successful exploit of this vulnerability may lead to a limited denial of service or data tampering.
{
"affected": [],
"aliases": [
"CVE-2024-0111"
],
"database_specific": {
"cwe_ids": [
"CWE-1284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-31T09:15:06Z",
"severity": "MODERATE"
},
"details": "NVIDIA CUDA Toolkit contains a vulnerability in command \u0027cuobjdump\u0027 where a user may cause a crash or produce incorrect output by passing a malformed ELF file. A successful exploit of this vulnerability may lead to a limited denial of service or data tampering.",
"id": "GHSA-qccm-7jq2-92v7",
"modified": "2024-08-31T09:30:44Z",
"published": "2024-08-31T09:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0111"
},
{
"type": "WEB",
"url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5564"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-QF97-64QX-GQHQ
Vulnerability from github – Published: 2023-01-26 21:30 – Updated: 2023-02-01 18:30In Condition of Condition.java, there is a possible way to grant notification access due to improper input validation. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-12 Android-12L Android-13Android ID: A-242846316
{
"affected": [],
"aliases": [
"CVE-2022-20493"
],
"database_specific": {
"cwe_ids": [
"CWE-1284",
"CWE-20"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-26T21:15:00Z",
"severity": "HIGH"
},
"details": "In Condition of Condition.java, there is a possible way to grant notification access due to improper input validation. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-12 Android-12L Android-13Android ID: A-242846316",
"id": "GHSA-qf97-64qx-gqhq",
"modified": "2023-02-01T18:30:31Z",
"published": "2023-01-26T21:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20493"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2023-01-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QFPC-5PJR-MH26
Vulnerability from github – Published: 2021-08-25 14:41 – Updated: 2024-11-13 21:14Impact
The shape inference code for tf.raw_ops.Dequantize has a vulnerability that could trigger a denial of service via a segfault if an attacker provides invalid arguments:
import tensorflow as tf
tf.compat.v1.disable_v2_behavior()
tf.raw_ops.Dequantize(
input_tensor = tf.constant(-10.0, dtype=tf.float32),
input_tensor = tf.cast(input_tensor, dtype=tf.quint8),
min_range = tf.constant([], shape=[0], dtype=tf.float32),
max_range = tf.constant([], shape=[0], dtype=tf.float32),
mode = 'MIN_COMBINED',
narrow_range=False,
axis=-10,
dtype=tf.dtypes.float32)
The shape inference implementation uses axis to select between two different values for minmax_rank which is then used to retrieve tensor dimensions. However, code assumes that axis can be either -1 or a value greater than -1, with no validation for the other values.
Patches
We have patched the issue in GitHub commit da857cfa0fde8f79ad0afdbc94e88b5d4bbec764.
The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.
For more information
Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.
Attribution
This vulnerability has been reported by Yakun Zhang of Baidu Security.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.5.0"
},
{
"fixed": "2.5.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.5.0"
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.5.0"
},
{
"fixed": "2.5.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.5.0"
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.5.0"
},
{
"fixed": "2.5.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.5.0"
]
}
],
"aliases": [
"CVE-2021-37677"
],
"database_specific": {
"cwe_ids": [
"CWE-1284",
"CWE-20"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-24T15:50:15Z",
"nvd_published_at": "2021-08-12T23:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\nThe shape inference code for `tf.raw_ops.Dequantize` has a vulnerability that could trigger a denial of service via a segfault if an attacker provides invalid arguments:\n\n```python\nimport tensorflow as tf\n\ntf.compat.v1.disable_v2_behavior()\ntf.raw_ops.Dequantize(\n input_tensor = tf.constant(-10.0, dtype=tf.float32),\n input_tensor = tf.cast(input_tensor, dtype=tf.quint8),\n min_range = tf.constant([], shape=[0], dtype=tf.float32),\n max_range = tf.constant([], shape=[0], dtype=tf.float32),\n mode = \u0027MIN_COMBINED\u0027,\n narrow_range=False,\n axis=-10,\n dtype=tf.dtypes.float32)\n```\n\nThe shape inference [implementation](https://github.com/tensorflow/tensorflow/blob/460e000de3a83278fb00b61a16d161b1964f15f4/tensorflow/core/ops/array_ops.cc#L2999-L3014) uses `axis` to select between two different values for `minmax_rank` which is then used to retrieve tensor dimensions. However, code assumes that `axis` can be either `-1` or a value greater than `-1`, with no validation for the other values.\n\n### Patches\nWe have patched the issue in GitHub commit [da857cfa0fde8f79ad0afdbc94e88b5d4bbec764](https://github.com/tensorflow/tensorflow/commit/da857cfa0fde8f79ad0afdbc94e88b5d4bbec764).\n\nThe fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.\n\n### For more information\nPlease consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions.\n\n### Attribution\nThis vulnerability has been reported by Yakun Zhang of Baidu Security.",
"id": "GHSA-qfpc-5pjr-mh26",
"modified": "2024-11-13T21:14:00Z",
"published": "2021-08-25T14:41:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-qfpc-5pjr-mh26"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37677"
},
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/commit/da857cfa0fde8f79ad0afdbc94e88b5d4bbec764"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-cpu/PYSEC-2021-590.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-gpu/PYSEC-2021-788.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow/PYSEC-2021-299.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/tensorflow/tensorflow"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Missing validation in shape inference for `Dequantize`"
}
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
No CAPEC attack patterns related to this CWE.