CWE-1049
Excessive Data Query Operations in a Large Data Table
Extended description
While the interpretation of "large data table" and "large number of joins or sub-queries" may vary for each product or developer, CISQ recommends a default of 1 million rows for a "large" data table, a default minimum of 5 joins, and a default minimum of 3 sub-queries.
Common consequences1
- OtherReduce Performance
This issue can make the product perform more slowly. If the relevant code is reachable by an attacker, then this performance problem might introduce a vulnerability.
Relationships1
- ChildOfCWE-1176
CVEs referencing this CWE3
| CVE | Description | Severity | EPSS | Flags | Modified |
|---|---|---|---|---|---|
| CVE-2019-8460 | OpenBSD kernel version <= 6.5 can be forced to create long chains of TCP SACK holes that causes very expensive calls to tcp_sack_option() for every incoming SACK packet which can lead to a denial of service. | HIGH7.5 | 2.19%p80 | 2024-11-21 | |
| CVE-2023-5192 | Excessive Data Query Operations in a Large Data Table in GitHub repository pimcore/demo prior to 10.3.0. | MEDIUM6.5 | 0.78%p51 | 2024-11-21 | |
| CVE-2025-0190 | In version 3.25.0 of aimhubio/aim, a denial of service vulnerability exists. By tracking a large number of `Text` objects and then querying them simultaneously through the web API, the Aim web server becomes unresponsive to other requests for an extended period while processing and returning these objects. This vulnerability can be exploited repeatedly, leading to a complete denial of service. | HIGH7.5 | 0.55%p42 | 2025-03-28 |