CVE-2026-118391 in Ecto
Summary
by MITRE • 11/04/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified as an allocation of resources without limits or throttling in Ecto, specifically affecting versions from 3.4.0 up to but not including 3.14.3, represents a significant denial-of-service risk for applications utilizing this database wrapper library within the Elixir ecosystem. This flaw allows unauthenticated remote attackers to exhaust memory resources on both the application server and the underlying database engine through carefully crafted requests containing distinct JSON keys or list lengths. The core of the issue lies in how Ecto handles query preparation and caching mechanisms when processing dynamic data structures, leading to an unbounded growth in resource consumption that can eventually crash services or degrade performance to unusable levels for legitimate users.
At a technical level, the vulnerability exploits the interaction between user-supplied input and Ecto's internal query compilation process. When developers use functions such as json_extract_path/2, field[^key], or splice/1 with dynamic inputs derived from external requests, these interpolated JSON path elements are treated as part of the static query expression rather than being passed as bindable parameters. In standard SQL execution models, parameterized queries allow the database engine to cache and reuse prepared statements for identical query structures regardless of the specific data values provided. However, because Ecto incorporates these dynamic keys directly into the query string structure, each unique key or list length results in a syntactically distinct query expression. This behavior fundamentally breaks the assumption that similar operations can share cached execution plans, forcing the system to treat every variation as a new and separate entity requiring its own resources.
The operational impact is exacerbated by Ecto's caching strategy for prepared queries. The library stores these compiled query expressions in an Erlang Term Storage (ETS) table associated with each repository connection pool. Crucially, this cache operates without any size limits or eviction policies such as least recently used (LRU). Consequently, every distinct key introduced into the application via malicious requests creates a new entry in the ETS table that persists indefinitely until the process is restarted. For applications using ecto_sql, which interfaces with relational databases like PostgreSQL or MySQL, each of these cache entries also corresponds to a newly prepared statement on the database connection itself. This dual-layer caching mechanism means that memory consumption grows linearly and unboundedly in both the application node's heap space and the database server's session memory, creating a severe resource exhaustion scenario.
From a security classification perspective, this vulnerability aligns with CWE-770: Allocation of Resources Without Limits or Throttling, as it involves the failure to restrict the consumption of system resources based on user input. It also relates closely to CWE-400: Uncontrolled Resource Consumption, where an attacker can cause the application to consume excessive amounts of memory. In terms of attack tactics, this falls under MITRE ATT&CK technique T1496: Resource Hijacking, specifically within the context of Denial of Service (DoS) attacks that aim to make a machine or network resource unavailable to its intended users by exhausting available capacity. The lack of input validation and rate limiting on dynamic query construction parameters allows for efficient exploitation without requiring authentication credentials.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary solution is to upgrade the Ecto library to version 3.14.3 or later, where this caching behavior has been corrected to prevent unbounded growth of prepared statement caches when handling dynamic inputs. For applications unable to immediately patch due to dependency constraints, developers should implement strict input validation and sanitization on all JSON keys and list lengths before they are passed into functions like json_extract_path/2, field[^key], or splice/1. Additionally, implementing rate limiting at the API gateway level can help throttle the volume of requests containing diverse dynamic structures, thereby reducing the rate at which new cache entries are generated. Application-level monitoring should also be enhanced to detect sudden spikes in memory usage associated with query compilation caches, allowing for proactive intervention before service degradation occurs.