EEF-CVE-2026-118391

Dashboard / Vulnerabilities / EEF-CVE-2026-118391

EEF-CVE-2026-118391

Summary: Unbounded query cache growth from interpolated JSON paths and splice lists in Ecto

Details: ## Summary Allocation of Resources Without Limits or Throttling vulnerability in elixir-ecto ecto allows an unauthenticated remote attacker to exhaust memory in the application and in the database server by sending requests with distinct JSON keys or list lengths where the application interpolates them into `json_extract_path/2`, `field[^key]` or `splice/1`. Ecto caches prepared queries per repository in an ETS table with no size limit and no eviction. Interpolated JSON path elements become part of the query expression instead of its parameters, and `splice/1` expands into one placeholder per element, so every distinct key or list length creates a new cache entry. With ecto_sql each entry is also a new prepared statement on the database connection that runs it. None of this memory is released until the processes restart. This issue affects ecto: from 3.4.0 before 3.14.3. ## Details **1. Cache keys** (`lib/ecto/query/builder.ex`, `lib/ecto/query/planner.ex`) `escape_json_path/2` checks interpolated path elements with `json_path_element!/1`, and a whole interpolated path with `json_path!/1`, at runtime and places the resulting strings and integers in the `{:json_extract_path, [], [field, path]}` expression instead of in the query parameters. `Ecto.Query.Planner` builds the cache key from the query expressions, so every distinct path is a distinct key. `splice(^list)` keeps the values as parameters but expands into one placeholder per element. `cast_and_merge_params/5` marks `{:in, _}` parameters as not cacheable but keeps `{:splice, _}` parameters cacheable, so every distinct list length is a distinct key, and the entry grows with the length. **2. Cache storage** (`lib/ecto/query/planner.ex`, `lib/ecto/repo/supervisor.ex`) `Ecto.Query.Planner.query/6` stores each new query with `:ets.insert_new/2` in the table that `Ecto.Repo.Supervisor` creates with `new_query_cache/1`, and nothing removes entries. ecto_sql renders the path into the SQL text, for example `WHERE ((i0."meta"#>array['color']::text[]) = $1)`, and Postgrex prepares a named statement for each new SQL text on the connection that runs it. **3. Effect** Each request with a new key or list length adds memory that is never released, in the BEAM, where the cache is shared by the whole repository, and with ecto_sql in the database server, where prepared statements are kept per connection. Large keys amplify this: every 1 MB of request data retained about 2 MB in the application and 3 MB in PostgreSQL. The query cache was disabled for `values/2` sources after a similar report, but not for these two cases. ## Proof of concept Reproduced on Ecto main (`ad8fda5`) with ecto_sql 3.14.0, Postgrex 0.22.4 and PostgreSQL 18.4, on Elixir 1.20.4 and Erlang/OTP 29, with `pool_size: 1`. 1. Define a handler that filters by a JSON key from the request: `Repo.all(from i in Item, where: json_extract_path(i.meta, ^[key]) == ^value, select: i.id)`. 2. Send 2,000 requests with the same key. The query cache has 1 entry and the connection 1 prepared statement; PostgreSQL backend memory goes from 2 MB to 3 MB. 3. Send 2,000 more requests with distinct short keys. The cache has 2,001 entries and the connection 2,001 prepared statements; backend memory is 21 MB. 4. Send 200 requests with a distinct 500 KB key each (100 MB in total). BEAM binary memory grows by 191 MB and PostgreSQL backend memory by 289 MB, measured after garbage collecting every process. 5. Repeating a key that was already seen adds nothing. `fragment("? IN (?)", i.id, splice(^ids))` with list lengths 1 to 300 adds 300 cache entries, while `i.id in ^ids` with the same lengths adds 1. ## Impact An unauthenticated client can make the application and its database keep memory from every request that carries a new JSON key or list length, when the application passes it into an interpolated JSON path or `splice/1`. Nothing frees that memory until the processes restart. In the proof of concept, 200 requests with 100 MB of keys in total left 191 MB in the BEAM and 289 MB in the PostgreSQL backend of one connection. Sustained requests exhaust memory in the application node, the database server, or both. ## Workarounds Pass the path as a query parameter so it is not part of the cache key. With PostgreSQL: `fragment("? #> ?", i.meta, type(^path, {:array, :string}))`. Alternatively, disable the cache for these queries with `Repo.all(query, query_cache: false)`, or restrict keys and list lengths to a known set before building the query. ## Configurations The application must pass request data into an interpolated JSON path (`json_extract_path(field, ^path)`, `json_extract_path(field, [^key])` or `field[^key]`), or a request-controlled list into `splice/1`, and run the query through a repository with the default `query_cache: true`. ## Solutions Upgrade Ecto to 3.14.3 or later. Queries with interpolated JSON path elements or an interpolated `splice/1` list are no longer cached, the same as running them with `query_cache: false`, so distinct keys and list lengths don't add cache entries.

References: https://github.com/elixir-ecto/ecto/security/advisories/GHSA-cxjx-vmm2-qr8r, https://cna.erlef.org/cves/CVE-2026-118391.html, https://github.com/elixir-ecto/ecto/commit/d0e97d8a6e274c81c25fbf08087da8d8b9bae0ea, https://ecto.hexdocs.pm/Ecto.Query.API.html#json_extract_path/2, https://ecto.hexdocs.pm/Ecto.Query.API.html#splice/1, https://github.com/elixir-ecto/ecto/commit/eb03f45b999e2bf67ffae92811233eb6e56dba55, https://github.com/elixir-ecto/ecto/issues/4470, https://github.com/elixir-ecto/ecto/issues/1031, https://github.com/elixir-ecto/ecto/commit/cb2f03964dac324a9771f84f5088e395326e6de8, https://github.com/elixir-ecto/ecto/commit/eef014ad090d27d1a5b69c0e32a50eabd44ab3bb, https://hex.pm/packages/ecto