| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 could allow an authenticated user to cause a denial of service using a specially crafted HTTP query due to improper allocation of system resources |
| IBM Db2 11.5.0 through 11.5.9, and 12.1.0 through 12.1.5 is vulnerable to a denial of service when inserting into a table with XML columns under specific conditions. |
| SGLang through 0.5.21 contains a resource budget bypass vulnerability that allows remote attackers to override GLM-V video processing limits by supplying fps, max_frames, max_tokens_per_frame and max_image_tokens in the video_url object. Attackers can set these values arbitrarily high so glm4v.py decodes every frame of high-resolution video at full size, exhausting worker memory and denying service. |
| OpenPrinting CUPS through 2.4.20 contains a resource-exhaustion vulnerability in the submission-timeout handling of cupsdCheckJobs(). The scheduler suppresses timeout processing for all pending jobs whenever any client connection has an in-flight Send-Document operation, without matching that connection to the job being examined. A client allowed to reach the IPP service can hold an incomplete HTTP request containing parsed Send-Document headers before operation authorization, preventing unrelated incomplete jobs from expiring. Where Create-Job submission is allowed, incomplete jobs can accumulate until MaxJobs is exhausted and further legitimate print submissions are rejected. The suppression ends when the held connection closes. |
| Parsing a multipart form can bypass memory limits and read an arbitrarily long line into memory when the remaining limit at the start of a part is less than 400 bytes. |
| Allocation of resources without limits or throttling (CWE-770) during Java object deserialization in Google Guava versions 4.0 through 33.7.1 allows an attacker to cause a Denial of Service via OutOfMemoryError. When deserializing CompactHashMap, CompactHashSet, or MapMakerInternalMap instances, Guava eagerly allocates an array based on a caller-specified size parameter without throttling, permitting memory exhaustion from crafted serialization streams. |
| A malicious HTTP/2 peer can cause excessive CPU consumption in the client or server by opening a large number of streams and then sending many small SETTINGS frames containing SETTINGS_INITIAL_WINDOW_SIZE values. |
| When parsing a Range header containing a large number of small ranges, FileServer(FS), ServeContent, and ServeFile(FS) can consume an excessive amount of CPU. |
| The HTTP/2 server can refund connection-level flow control twice for the same data: Once when a client resets a stream (refunding data for any sent-but-unread portion of the stream), and again when a request handler reads the buffered data. A malicious client can exploit this to bypass the configured connection-level flow control limit (MaxReceiveBufferPerConnection). Total buffered data is still limited by the concurrent stream limit and stream-level flow control. |
| Multiple ECH outer extension references are not permitted under RFC 9849; previously, a client could send a well-crafted packet that could trigger memory exhaustion in the server process by specifying multiple references. We now reject these as malformed and curb the memory amplification vector as a result. |
| amqp091-go is a Go AMQP 0.9.1 client. From 1.13.0 until 1.14.0, the frame-size mitigation from the prior allocation advisory can be bypassed before connection.tune completes because Connection.maxFrameSize uses zero for both the not-yet-negotiated and negotiated-unlimited states. A malicious or compromised AMQP peer can send a short body-frame header with a large declared payload length, causing ReadFrame and the body-frame parser to allocate attacker-selected memory before the payload is received or the frame's protocol state is rejected. The condition is reachable through public Open even when Config.FrameSize is set to the protocol minimum and can cause severe memory pressure, out-of-memory termination, or loss of the client process before authentication completes. This issue is fixed in version 1.14.0. |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can lead to Denial of Service via Excessive Allocation (CAPEC-130). Elasticsearch enforces a size limit on the user-supplied metadata field for each individual template resource, but does not limit the total memory used when multiple such resources are retrieved together. A user holding the *manage_index_templates* cluster privilege can register multiple resources each within the individual limit. Retrieving them together materializes all of their metadata values in memory at once, exhausting available heap and causing the affected node to fail with an out-of-memory error, resulting in a denial of service. |
| Memory Allocation with Excessive Size Value (CWE-789) in Elasticsearch can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user with connector management privileges could cause the cluster to allocate an uncontrolled amount of memory when connector resources with an excessively large `description` field are created and subsequently accessed, exhausting available heap memory and crashing the affected node. |
| A flaw was found in quarkus-websockets-next. This vulnerability allows a remote attacker to cause a Denial of Service (DoS) by streaming messages over a single connection faster than the application can process them. Due to unbounded message buffering and a lack of read backpressure, this rapidly exhausts heap space, leading to a java.lang.OutOfMemoryError that crashes the Java Virtual Machine (JVM). |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: hhf: cap hh_flows_limit at change time
hhf_change() stores TCA_HHF_HH_FLOWS_LIMIT with no upper bound. A huge
hh_flows_limit lets each new heavy-hitter flow pass the
hh_flows_current_cnt check in alloc_new_hh() and forces a fixed-size
kzalloc(GFP_ATOMIC) per flow under spoofed traffic, for unbounded memory
growth.
Bound the attribute with NLA_POLICY_MAX() at 2*HH_FLOWS_CNT (the
hhf_init() default) and report the rejected value via extack. The
deprecated nested parse is kept: legacy tc does not set NLA_F_NESTED on
TCA_OPTIONS. Configs relying on hh_limit above the default were relying
on unbounded, unsafe behaviour and are not supported going forward.
hhf_init() also ran hhf_change() before setting the default
hh_flows_limit, so a user-supplied hh_limit at add time was clobbered
back to 2048. Set the default before hhf_change() so the configured
value sticks.
This is a follow-up to commit eb56a495f59b ("net/sched: hhf: clamp
quantum in change and init paths"), which bounded the quantum of the
same qdisc; the hh_flows_limit bound is the remaining unbounded knob of
that series' scope.
Conditions to recreate the bug: CAP_NET_ADMIN in a user namespace;
tc qdisc change dev X root hhf hh_limit 4294967295 succeeds and the
value is echoed by tc qdisc show, unbounding heavy-hitter flow
allocations; also tc qdisc add dev X root hhf hh_limit 500 stores 2048
instead of 500. |
| This CVE ID has been rejected as a duplicate. |
| Uncontrolled Recursion (CWE-674) in Elasticsearch can lead to Denial of Service via a specially crafted, deeply nested request submitted to the aggregation feature of the search API. Elasticsearch contains an uncontrolled recursion weakness in its search aggregation processing. An authenticated user with read access to a single index can submit a specially crafted request containing deeply nested aggregation definitions. Processing this request triggers unbounded recursive execution that exhausts the server process's available resources, causing the affected node to terminate. The node does not recover automatically and requires manual intervention to restore service. |
| Uncontrolled Recursion (CWE-674) in Elasticsearch can lead to Denial of Service via a specially crafted request that causes the server to construct and process a deeply nested data structure with no bound on recursion depth. Elasticsearch contains an uncontrolled recursion weakness in how it builds and serializes geometry values produced by scripted runtime fields. Unlike geometry supplied as text, which is subject to a nesting-depth limit, geometry constructed from a script's output is not bounded. An authenticated user with read access to a single index can submit a request defining such a field with a script that produces a deeply nested structure. Processing this request recurses past the available stack space, causing the affected node to terminate. The node does not recover automatically on all deployments and may require manual intervention to restore service. |
| savg-sanitizer is a PHP SVG/XML sanitizer. Prior to 1.0.0, svg-sanitizer allows a crafted SVG DTD with a #FIXED attribute default to make cleanAttributesOnWhitelist() perform a double DOMElement::removeAttribute() call on the same attribute name in src/Sanitizer.php. The first removal deletes the explicit attribute, while the DTD default rematerializes the value before the href safety path performs the second removal, which can corrupt libxml state and terminate the PHP worker. An attacker who can submit SVG content to a sanitization endpoint can repeatedly interrupt workers and degrade or exhaust application availability. This issue is fixed in version 1.0.0. |
| Allocation of resources without limits or throttling vulnerability in ESET PROTECT On-Prem increased resource consumption (CPU and RAM), leading to conditions for a Denial-of-Service attack. |
