CVE-2026-44635: Kysely Path Traversal Vulnerability

HIGH
Advisory Identifier: GHSA-pv5w-4p9q-p3v2
CVSS 7.5
CWE-89 CWE-1284 CWE-915 CWE-22
Published
Advisory Summary

CVE-2026-44635 is a HIGH (CVSS 7.5) path traversal vulnerability (CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')) affecting Kysely libraries in the npm ecosystem. The issue involves json-path traversal injection via unsanitized path-leg metacharacters in `jsonpathbuilder.key()` / `.at()`. Remediation is available by upgrading affected packages to version 0.28.17.

CVE-2026-44635 at a Glance

CVE Identifier CVE-2026-44635
GHSA Identifier GHSA-pv5w-4p9q-p3v2
Severity HIGH
CVSS v3.1 Base Score 7.5
CWE Classification CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Affected Product Kysely
Package Ecosystem npm
Published Date
Last Updated

Security Impact

CVSS: 7.5

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity None (I:N)
Availability None (A:N)

How to Fix CVE-2026-44635

To remediate this vulnerability, upgrade all affected Kysely dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

kysely fixed: 0.28.17
npm install kysely@0.28.17
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls kysely

How to Check if You Are Affected

To determine whether your Node.js application is affected by CVE-2026-44635, inspect your project dependencies using npm:

npm ls kysely

Analyze the terminal output to locate any version of Kysely in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.28.17), your application is affected.

Note: The npm ls kysely command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'), where the product constructs all or part of an sql command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended sql command when it is sent to a downstream component. without sufficient removal or quoting of sql syntax in user-controllable inputs, the generated sql query can cause those inputs to be interpreted as sql instead of ordinary user data. In Kysely, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## 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`: ```ts 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`: ```ts 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`: ```ts 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`: ```ts #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()`): ```bash $ 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: ```js 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: ```json { "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. ```bash $ 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). ```ts // 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.

CVE-2026-44635 Affected Kysely Versions

1 component(s)
Fixed Versions:
0.28.17
Product / Package Ecosystem Affected Versions Fixed Version
kysely
npm
≥ 0.26.0
< 0.28.17
0.28.17

References

Frequently Asked Questions

What is CVE-2026-44635?
CVE-2026-44635 is a security vulnerability in Kysely involving JSON-path traversal injection via unsanitized path-leg metacharacters in `JSONPathBuilder.key()` / `.at()` under CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection').
Which Kysely versions are affected?
Affected versions include releases prior to 0.28.17 across affected packages: kysely.
What version fixes CVE-2026-44635?
Upgrading to 0.28.17 (or the latest patched release for your respective branch) resolves the vulnerability.
Is kysely affected?
Yes, kysely is affected in releases prior to 0.28.17. Upgrade your dependency to 0.28.17 or later.
What is the CVSS score of CVE-2026-44635?
CVE-2026-44635 has a CVSS v3.1 base score of 7.5 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N.
What CWE is associated with CVE-2026-44635?
CVE-2026-44635 is classified under CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') (The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.).
How can I check npm dependencies for CVE-2026-44635?
Run the dependency tree command: 'npm ls kysely'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-pv5w-4p9q-p3v2",
  "modified" : "2026-06-08T23:53:29Z",
  "published" : "2026-05-11T19:40:15Z",
  "aliases" : [ "CVE-2026-44635" ],
  "summary" : "Kysely: JSON-path traversal injection via unsanitized path-leg metacharacters in `JSONPathBuilder.key()` / `.at()`",
  "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 (`'` → `''`); 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.\n\n* Project: Kysely — TypeScript SQL query builder (npm `kysely`); affects MySQL, PostgreSQL `->$`/`->>$`, 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–1639, 1821–1823)\n  * `src/query-builder/json-path-builder.ts` (lines 93–196)\n  * `src/dialect/mysql/mysql-query-compiler.ts` (overrides `sanitizeStringLiteral` but inherits the same behaviour for path legs — escapes `\\` and `'`, nothing else)\n* 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.\n* OWASP 2021: A03:2021 — 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 === 'ArrayLocation'\n\n  this.append(isArrayLocation ? '[' : '.')      // (1)\n\n  this.append(\n    typeof node.value === 'string'\n      ? this.sanitizeStringLiteral(node.value)  // (2)\n      : String(node.value),\n  )\n\n  if (isArrayLocation) {\n    this.append(']')\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, \"''\")    // (3)\n}\n```\n\nwith `LIT_WRAP_REGEX = /'/g`.\n\n`src/query-builder/json-path-builder.ts:151-167`:\n\n```ts\nkey<\n  K extends any[] extends O\n    ? never\n    : O extends object\n      ? keyof NonNullable<O> & string\n      : never,\n  O2 = undefined extends O\n    ? null | NonNullable<NonNullable<O>[K]>\n    : null extends O\n      ? null | NonNullable<NonNullable<O>[K]>\n      : // when the object has non-specific keys, e.g. Record<string, T>, should infer `T | null`!\n        string extends keyof NonNullable<O>\n        ? null | NonNullable<NonNullable<O>[K]>\n        : NonNullable<O>[K],\n>(key: K): TraversedJSONPathBuilder<S, O2> {\n  return this.#createBuilderWithPathLeg('Member', 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<any, any> {\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 — `.` 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.\n\nAt (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.\n\nThe fix at `0a602bf` only addressed the single-quote → 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 — 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 — 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`->'$.nick' as `out` from `person`\n\n--- INJECTION via .key(ATTACKER) -- \"nick.secret_field\" ---\nSQL:     select `profile`->'$.nick.secret_field' as `out` from `person`\n\n--- INJECTION via .key(\"*\") -- wildcard reaches all keys ---\nSQL:     select `profile`->'$.*' as `out` from `person`\n\n--- INJECTION via .at(ATTACKER3) -- bracket escape ---\nSQL:     select `profile`->'$[].secret]' as `out` from `person`\n\n===== PostgreSQL (->$ uses jsonpath, MySQL-like) =====\n\n--- baseline: .key(\"nick\") ---\nSQL:     select \"profile\"->'$.nick' as \"out\" from \"person\"\n\n--- INJECTION via .key(ATTACKER) ---\nSQL:     select \"profile\"->'$.nick.secret_field' as \"out\" from \"person\"\n\n===== SQLite =====\n\n--- baseline: .key(\"nick\") ---\nSQL:     select \"profile\"->>'$.nick' as \"value\" from \"person\"\n\n--- INJECTION via .key(ATTACKER) ---\nSQL:     select \"profile\"->>'$.nick.secret_field' as \"out\" from \"person\"\n\n--- INJECTION via .key(\"*\") ---\nSQL:     select \"profile\"->>'$.*' 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: `'$.nick'` (one leg) becomes `'$.nick.secret_field'` (two legs). MySQL additionally accepts `*` as a wildcard reaching every member at the current level.\n\n### Step 2 — 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's profile:\n\n```js\nasync function fetchProfileField(userInput) {\n  return db.selectFrom('me')\n    .select(eb => eb.ref('profile', '->>$').key(userInput).as('value'))\n    .where('id', '=', 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's 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\"->>'$.nick' as \"value\" from \"me\" where \"id\" = ?\n  result:        [ { value: 'alice' } ]\n\n===== Injection: dot lets attacker reach nested \"internal\" object =====\nuserInput = \"internal.ssn\"\n  compiled SQL:  select \"profile\"->>'$.internal.ssn' as \"value\" from \"me\" where \"id\" = ?\n  result:        [ { value: '111-11-1111' } ]\n\nuserInput = \"internal.token\"\n  compiled SQL:  select \"profile\"->>'$.internal.token' as \"value\" from \"me\" where \"id\" = ?\n  result:        [ { value: 'tok_abcdef' } ]\n\nuserInput = \"internal.admin\"\n  compiled SQL:  select \"profile\"->>'$.internal.admin' 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 — `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 — 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`).\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 — 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.\n* **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.\n* **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.\n* **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.\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<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.\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 `\"…\"`-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 === 'ArrayLocation') {\n    this.append('[')\n    if (typeof node.value === 'number') {\n      this.append(String(node.value | 0))      // int-coerce\n    } else if (node.value === 'last' || /^#-\\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(']')\n    return\n  }\n  // Member\n  this.append('.')\n  if (typeof node.value !== 'string' || !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 `\"…\"`-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('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')`.\n\nA 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" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "kysely"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0.26.0"
      }, {
        "fixed" : "0.28.17"
      } ]
    } ]
  } ],
  "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"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-1284", "CWE-22", "CWE-89", "CWE-915" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-05-11T19:40:15Z",
    "nvd_published_at" : "2026-05-27T19:16:20Z"
  }
}