GHSA-cxjx-vmm2-qr8r: Unbounded query cache growth from interpolated JSON paths and splice lists in Ecto

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 jsonextractpath/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 ectosql 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)

escapejsonpath/2 checks interpolated path elements with jsonpathelement!/1, and a whole interpolated path with jsonpath!/1, at runtime and places the resulting strings and integers in the {:jsonextractpath, [], [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. castandmergeparams/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.insertnew/2 in the table that Ecto.Repo.Supervisor creates with newquerycache/1, and nothing removes entries. ectosql 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 ectosql 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 ectosql 3.14.0, Postgrex 0.22.4 and PostgreSQL 18.4, on Elixir 1.20.4 and Erlang/OTP 29, with poolsize: 1.

1. Define a handler that filters by a JSON key from the request: Repo.all(from i in Item, where: jsonextractpath(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, querycache: 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 (jsonextractpath(field, ^path), jsonextractpath(field, [^key]) or field[^key]), or a request-controlled list into splice/1, and run the query through a repository with the default querycache: 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 querycache: false, so distinct keys and list lengths don't add cache entries.