CVE-2026-118391 (GCVE-0-2026-118391)
Vulnerability from cvelistv5 – Published: 2026-11-04 13:57 – Updated: 2026-11-05 19:07
VLAI
EPSS
VEX
Title
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 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.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-11-04 20:48 UTC
CWE
- CWE-770 - Allocation of Resources Without Limits or Throttling
Assigner
References
11 references
| URL | Tags |
|---|---|
| https://github.com/elixir-ecto/ecto/security/advi… | vendor-advisory |
| https://cna.erlef.org/cves/CVE-2026-118391.html | related |
| https://osv.dev/vulnerability/EEF-CVE-2026-118391 | related |
| https://github.com/elixir-ecto/ecto/commit/d0e97d… | patch |
| https://ecto.hexdocs.pm/Ecto.Query.API.html#json_… | technical-description |
| https://ecto.hexdocs.pm/Ecto.Query.API.html#splice/1 | technical-description |
| https://github.com/elixir-ecto/ecto/commit/eb03f4… | related |
| https://github.com/elixir-ecto/ecto/issues/4470 | related |
| https://github.com/elixir-ecto/ecto/issues/1031 | related |
| https://github.com/elixir-ecto/ecto/commit/cb2f03… | related |
| https://github.com/elixir-ecto/ecto/commit/eef014… | patch |
Impacted products
2 products
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| elixir-ecto | ecto |
Affected:
3.4.0 , < 3.14.3
(semver)
cpe:2.3:a:elixir-ecto:ecto:*:*:*:*:*:*:*:* |
||
| elixir-ecto | ecto |
Affected:
cb2f03964dac324a9771f84f5088e395326e6de8 , < eef014ad090d27d1a5b69c0e32a50eabd44ab3bb
(git)
cpe:2.3:a:elixir-ecto:ecto:*:*:*:*:*:*:*:* |
Date Public
2026-11-04 08:46
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-118391",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-11-04T20:48:32.374051Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-11-05T19:07:34.294Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:elixir-ecto:ecto:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"packageName": "ecto",
"packageURL": "pkg:hex/ecto",
"product": "ecto",
"repo": "https://github.com/elixir-ecto/ecto",
"vendor": "elixir-ecto",
"versions": [
{
"lessThan": "3.14.3",
"status": "affected",
"version": "3.4.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:elixir-ecto:ecto:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"packageName": "elixir-ecto/ecto",
"packageURL": "pkg:github/elixir-ecto/ecto",
"product": "ecto",
"repo": "https://github.com/elixir-ecto/ecto",
"vendor": "elixir-ecto",
"versions": [
{
"lessThan": "eef014ad090d27d1a5b69c0e32a50eabd44ab3bb",
"status": "affected",
"version": "cb2f03964dac324a9771f84f5088e395326e6de8",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eThe application must pass request data into an interpolated JSON path (\u003ccode\u003ejson_extract_path(field, ^path)\u003c/code\u003e, \u003ccode\u003ejson_extract_path(field, [^key])\u003c/code\u003e or \u003ccode\u003efield[^key]\u003c/code\u003e), or a request-controlled list into \u003ccode\u003esplice/1\u003c/code\u003e, and run the query through a repository with the default \u003ccode\u003equery_cache: true\u003c/code\u003e.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "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`."
}
],
"value": "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."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:elixir-ecto:ecto:*:*:*:*:*:*:*:*",
"versionEndExcluding": "3.14.3",
"versionStartIncluding": "3.4.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Eric Meadows-J\u00f6nsson"
},
{
"lang": "en",
"type": "reporter",
"value": "Eric Meadows-J\u00f6nsson"
},
{
"lang": "en",
"type": "remediation developer",
"value": "Jos\u00e9 Valim"
}
],
"dateAssigned": "2026-10-30T12:36:37.000Z",
"datePublic": "2026-11-04T08:46:53.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAllocation 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 \u003ccode\u003ejson_extract_path/2\u003c/code\u003e, \u003ccode\u003efield[^key]\u003c/code\u003e or \u003ccode\u003esplice/1\u003c/code\u003e. 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 \u003ccode\u003esplice/1\u003c/code\u003e 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.\u003c/p\u003e\n\u003cp\u003eThis issue affects ecto: from 3.4.0 before 3.14.3.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "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.\n\nThis issue affects ecto: from 3.4.0 before 3.14.3."
}
],
"value": "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.\n\nThis issue affects ecto: from 3.4.0 before 3.14.3."
}
],
"impacts": [
{
"capecId": "CAPEC-131",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAn 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 \u003ccode\u003esplice/1\u003c/code\u003e. 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.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "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."
}
],
"value": "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."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 8.9,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "HIGH",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-770",
"description": "CWE-770 Allocation of Resources Without Limits or Throttling",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-04T13:57:29.762Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GHSA-cxjx-vmm2-qr8r",
"tags": [
"vendor-advisory"
],
"url": "https://github.com/elixir-ecto/ecto/security/advisories/GHSA-cxjx-vmm2-qr8r"
},
{
"name": "EEF CNA record for CVE-2026-118391",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-118391.html"
},
{
"name": "OSV record EEF-CVE-2026-118391",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-118391"
},
{
"name": "Do not cache queries with interpolated JSON paths, splices, and constants (main)",
"tags": [
"patch"
],
"url": "https://github.com/elixir-ecto/ecto/commit/d0e97d8a6e274c81c25fbf08087da8d8b9bae0ea"
},
{
"name": "Ecto.Query.API.json_extract_path/2",
"tags": [
"technical-description"
],
"url": "https://ecto.hexdocs.pm/Ecto.Query.API.html#json_extract_path/2"
},
{
"name": "Ecto.Query.API.splice/1",
"tags": [
"technical-description"
],
"url": "https://ecto.hexdocs.pm/Ecto.Query.API.html#splice/1"
},
{
"name": "Add splice to fragment (#4228), v3.11.0",
"tags": [
"related"
],
"url": "https://github.com/elixir-ecto/ecto/commit/eb03f45b999e2bf67ffae92811233eb6e56dba55"
},
{
"name": "Should we allow disabling of Ecto cache on specific queries? (#4470)",
"tags": [
"related"
],
"url": "https://github.com/elixir-ecto/ecto/issues/4470"
},
{
"name": "String interpolation will grow cached unboundedly (#1031)",
"tags": [
"related"
],
"url": "https://github.com/elixir-ecto/ecto/issues/1031"
},
{
"name": "Introducing commit cb2f039 in elixir-ecto/ecto",
"tags": [
"related"
],
"url": "https://github.com/elixir-ecto/ecto/commit/cb2f03964dac324a9771f84f5088e395326e6de8"
},
{
"name": "Fix commit eef014a in elixir-ecto/ecto",
"tags": [
"patch"
],
"url": "https://github.com/elixir-ecto/ecto/commit/eef014ad090d27d1a5b69c0e32a50eabd44ab3bb"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUpgrade Ecto to 3.14.3 or later. Queries with interpolated JSON path elements or an interpolated \u003ccode\u003esplice/1\u003c/code\u003e list are no longer cached, the same as running them with \u003ccode\u003equery_cache: false\u003c/code\u003e, so distinct keys and list lengths don\u0027t add cache entries.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "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\u0027t add cache entries."
}
],
"value": "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\u0027t add cache entries."
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Unbounded query cache growth from interpolated JSON paths and splice lists in Ecto",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003ePass the path as a query parameter so it is not part of the cache key. With PostgreSQL: \u003ccode\u003efragment(\"? #\u0026gt; ?\", i.meta, type(^path, {:array, :string}))\u003c/code\u003e. Alternatively, disable the cache for these queries with \u003ccode\u003eRepo.all(query, query_cache: false)\u003c/code\u003e, or restrict keys and list lengths to a known set before building the query.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Pass the path as a query parameter so it is not part of the cache key. With PostgreSQL: `fragment(\"? #\u003e ?\", 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."
}
],
"value": "Pass the path as a query parameter so it is not part of the cache key. With PostgreSQL: fragment(\"? #\u003e ?\", 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."
}
],
"x_proofOfConcept": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eReproduced on Ecto main (\u003ccode\u003ead8fda5\u003c/code\u003e) with ecto_sql 3.14.0, Postgrex 0.22.4 and PostgreSQL 18.4, on Elixir 1.20.4 and Erlang/OTP 29, with \u003ccode\u003epool_size: 1\u003c/code\u003e.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eDefine a handler that filters by a JSON key from the request: \u003ccode\u003eRepo.all(from i in Item, where: json_extract_path(i.meta, ^[key]) == ^value, select: i.id)\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eSend 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.\u003c/li\u003e\n\u003cli\u003eSend 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.\u003c/li\u003e\n\u003cli\u003eSend 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.\u003c/li\u003e\n\u003cli\u003eRepeating a key that was already seen adds nothing. \u003ccode\u003efragment(\"? IN (?)\", i.id, splice(^ids))\u003c/code\u003e with list lengths 1 to 300 adds 300 cache entries, while \u003ccode\u003ei.id in ^ids\u003c/code\u003e with the same lengths adds 1.\u003c/li\u003e\n\u003c/ol\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "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`.\n\n1. 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)`.\n2. 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.\n3. 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.\n4. 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.\n5. 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."
}
],
"value": "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.\n\n* 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).\n* 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.\n* 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.\n* 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.\n* 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."
}
],
"x_technicalAnalysis": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003e\u003cstrong\u003e1. Cache keys\u003c/strong\u003e (\u003ccode\u003elib/ecto/query/builder.ex\u003c/code\u003e, \u003ccode\u003elib/ecto/query/planner.ex\u003c/code\u003e)\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eescape_json_path/2\u003c/code\u003e checks interpolated path elements with \u003ccode\u003ejson_path_element!/1\u003c/code\u003e, and a whole interpolated path with \u003ccode\u003ejson_path!/1\u003c/code\u003e, at runtime and places the resulting strings and integers in the \u003ccode\u003e{:json_extract_path, [], [field, path]}\u003c/code\u003e expression instead of in the query parameters. \u003ccode\u003eEcto.Query.Planner\u003c/code\u003e builds the cache key from the query expressions, so every distinct path is a distinct key. \u003ccode\u003esplice(^list)\u003c/code\u003e keeps the values as parameters but expands into one placeholder per element. \u003ccode\u003ecast_and_merge_params/5\u003c/code\u003e marks \u003ccode\u003e{:in, _}\u003c/code\u003e parameters as not cacheable but keeps \u003ccode\u003e{:splice, _}\u003c/code\u003e parameters cacheable, so every distinct list length is a distinct key, and the entry grows with the length.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2. Cache storage\u003c/strong\u003e (\u003ccode\u003elib/ecto/query/planner.ex\u003c/code\u003e, \u003ccode\u003elib/ecto/repo/supervisor.ex\u003c/code\u003e)\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eEcto.Query.Planner.query/6\u003c/code\u003e stores each new query with \u003ccode\u003e:ets.insert_new/2\u003c/code\u003e in the table that \u003ccode\u003eEcto.Repo.Supervisor\u003c/code\u003e creates with \u003ccode\u003enew_query_cache/1\u003c/code\u003e, and nothing removes entries. ecto_sql renders the path into the SQL text, for example \u003ccode\u003eWHERE ((i0.\"meta\"#\u0026gt;array[\u0027color\u0027]::text[]) = $1)\u003c/code\u003e, and Postgrex prepares a named statement for each new SQL text on the connection that runs it.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3. Effect\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eEach 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 \u003ccode\u003evalues/2\u003c/code\u003e sources after a similar report, but not for these two cases.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "**1. Cache keys** (`lib/ecto/query/builder.ex`, `lib/ecto/query/planner.ex`)\n\n`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.\n\n**2. Cache storage** (`lib/ecto/query/planner.ex`, `lib/ecto/repo/supervisor.ex`)\n\n`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\"#\u003earray[\u0027color\u0027]::text[]) = $1)`, and Postgrex prepares a named statement for each new SQL text on the connection that runs it.\n\n**3. Effect**\n\nEach 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."
}
],
"value": "1. Cache keys (lib/ecto/query/builder.ex, lib/ecto/query/planner.ex)\n\nescape_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.\n\n2. Cache storage (lib/ecto/query/planner.ex, lib/ecto/repo/supervisor.ex)\n\nEcto.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\"#\u003earray[\u0027color\u0027]::text[]) = $1), and Postgrex prepares a named statement for each new SQL text on the connection that runs it.\n\n3. Effect\n\nEach 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."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-118391",
"datePublished": "2026-11-04T13:57:29.762Z",
"dateReserved": "2026-10-30T09:45:01.832Z",
"dateUpdated": "2026-11-05T19:07:34.294Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-118391",
"date": "2026-11-06",
"epss": "0.00494",
"percentile": "0.42612"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:elixir-ecto:ecto:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"packageName": "ecto",
"packageURL": "pkg:hex/ecto",
"product": "ecto",
"repo": "https://github.com/elixir-ecto/ecto",
"vendor": "elixir-ecto",
"versions": [
{
"lessThan": "3.14.3",
"status": "affected",
"version": "3.4.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:elixir-ecto:ecto:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"packageName": "elixir-ecto/ecto",
"packageURL": "pkg:github/elixir-ecto/ecto",
"product": "ecto",
"repo": "https://github.com/elixir-ecto/ecto",
"vendor": "elixir-ecto",
"versions": [
{
"lessThan": "eef014ad090d27d1a5b69c0e32a50eabd44ab3bb",
"status": "affected",
"version": "cb2f03964dac324a9771f84f5088e395326e6de8",
"versionType": "git"
}
]
}
],
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "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.\n\nThis issue affects ecto: from 3.4.0 before 3.14.3."
}
],
"id": "CVE-2026-118391",
"lastModified": "2026-11-05T19:17:11.763",
"metrics": {
"cvssMetricV40": [
{
"cvssData": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"availabilityRequirement": "NOT_DEFINED",
"baseScore": 8.9,
"baseSeverity": "HIGH",
"confidentialityRequirement": "NOT_DEFINED",
"exploitMaturity": "NOT_DEFINED",
"integrityRequirement": "NOT_DEFINED",
"modifiedAttackComplexity": "NOT_DEFINED",
"modifiedAttackRequirements": "NOT_DEFINED",
"modifiedAttackVector": "NOT_DEFINED",
"modifiedPrivilegesRequired": "NOT_DEFINED",
"modifiedSubAvailabilityImpact": "NOT_DEFINED",
"modifiedSubConfidentialityImpact": "NOT_DEFINED",
"modifiedSubIntegrityImpact": "NOT_DEFINED",
"modifiedUserInteraction": "NOT_DEFINED",
"modifiedVulnAvailabilityImpact": "NOT_DEFINED",
"modifiedVulnConfidentialityImpact": "NOT_DEFINED",
"modifiedVulnIntegrityImpact": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "HIGH",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2026-118391",
"options": [
{
"exploitation": "none"
},
{
"automatable": "yes"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-11-04T20:48:32.374051Z",
"version": "2.0.3"
}
}
]
},
"published": "2026-11-04T14:17:29.983",
"references": [
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://cna.erlef.org/cves/CVE-2026-118391.html"
},
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://ecto.hexdocs.pm/Ecto.Query.API.html#json_extract_path/2"
},
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://ecto.hexdocs.pm/Ecto.Query.API.html#splice/1"
},
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://github.com/elixir-ecto/ecto/commit/cb2f03964dac324a9771f84f5088e395326e6de8"
},
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://github.com/elixir-ecto/ecto/commit/d0e97d8a6e274c81c25fbf08087da8d8b9bae0ea"
},
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://github.com/elixir-ecto/ecto/commit/eb03f45b999e2bf67ffae92811233eb6e56dba55"
},
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://github.com/elixir-ecto/ecto/commit/eef014ad090d27d1a5b69c0e32a50eabd44ab3bb"
},
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://github.com/elixir-ecto/ecto/issues/1031"
},
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://github.com/elixir-ecto/ecto/issues/4470"
},
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://github.com/elixir-ecto/ecto/security/advisories/GHSA-cxjx-vmm2-qr8r"
},
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-118391"
}
],
"sourceIdentifier": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"vulnStatus": "Received",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-770"
}
],
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"type": "Secondary"
}
]
}
}
}
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.