CVE-2026-118391

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.

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.

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.

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.

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…