Overview 2,848 matches · 243 in Waratek scope · 14 protected · 3 exploited · 2 CISA KEV · 20 public PoC · 16 EPSS ≥ 0.5
2,848matches
243in Waratek scope8.5%
14protected0.5%
3exploited0.1%
2CISA KEV0.1%
20public PoC0.7%
16EPSS ≥ 0.50.6%
Protected by Waratek
14
0.5%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
229
8.0%
Outside Waratek scope
38
1.3%
Not applicable
2,566
90.1%
Withdrawn CVE
1
0.0%
blocked by ARMR today
14
0.5%
partly blocked
0
0.0%
not blocked
2,834
99.5%
not established
0
0.0%
unrecorded
0
0.0%
split by
peak 1,426 / year
20011
Not applicable1
Medium1
not blocked1
No public exploit1
20020
20030
20040
20053
No exploit published1
Not applicable2
Medium3
not blocked3
No public exploit3
20060
20070
20083
Not applicable3
High1
Medium2
not blocked3
Working exploit published1
No public exploit2
20094
Outside Waratek scope1
Not applicable3
High2
Medium2
not blocked4
Working exploit published1
No public exploit3
20100
20111
Not applicable1
Medium1
not blocked1
Working exploit published1
20120
20130
20140
20150
20162
Not applicable2
High1
Medium1
not blocked2
No public exploit2
201741
No exploit published2
Outside Waratek scope1
Not applicable38
Critical2
High20
Medium19
not blocked41
Working exploit published2
No public exploit39
201841
Protected by Waratek1
No exploit published2
Outside Waratek scope3
Not applicable35
High19
Medium22
blocked by ARMR today1
not blocked40
Working exploit published1
No public exploit40
201999
No exploit published6
Outside Waratek scope13
Not applicable80
Critical3
High58
Medium38
not blocked99
Forecast only6
No public exploit93
202064
No exploit published4
Outside Waratek scope2
Not applicable58
High39
Medium22
Low3
not blocked64
Exploited2
Working exploit published2
No public exploit60
2021109
No exploit published11
Outside Waratek scope4
Not applicable94
Critical2
High57
Medium49
Low1
not blocked109
Proof of concept only2
No public exploit107
2022186
Protected by Waratek5
No exploit published9
Outside Waratek scope4
Not applicable168
Critical5
High90
Medium91
blocked by ARMR today5
not blocked181
Proof of concept only16
Forecast only1
No public exploit169
2023207
Protected by Waratek2
No exploit published17
Outside Waratek scope1
Not applicable187
Critical6
High122
Medium78
Low1
blocked by ARMR today2
not blocked205
Proof of concept only49
Forecast only3
No public exploit155
2024281
Protected by Waratek2
No exploit published19
Outside Waratek scope5
Not applicable255
Critical6
High134
Medium137
Low4
blocked by ARMR today2
not blocked279
Exploited1
Working exploit published1
Proof of concept only36
Forecast only1
No public exploit242
2025380
No exploit published23
Outside Waratek scope2
Not applicable355
Critical4
High179
Medium186
Low11
not blocked380
Proof of concept only67
No public exploit313
20261,426
Protected by Waratek4
No exploit published135
Outside Waratek scope2
Not applicable1,284
Withdrawn CVE1
Critical18
High792
Medium569
Low44
Unknown3
blocked by ARMR today4
not blocked1,422
Proof of concept only337
No public exploit1,089
200220052008201120142017202020232026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-55367 | High | 2026-11-04 | Not applicable | No public exploit | h2o is an HTTP server with support for HTTP/1.x, HTTP/2 and HTTP/3. Prior to commit 4212ce114506a073505fd389db16ad2ba4e582a0, a client could send an incomplete CONNECT-UDP Capsule with an excessively large declared length, causing H2O to keep buffering received bytes without a per-Capsule limit while waiting for the remainder. Deployments that enabled proxy.connect-udp and accepted CONNECT-UDP requests could exhaust server memory and lose availability. This vulnerability is fixed with commit 4212ce114506a073505fd389db16ad2ba4e582a0. |
| CVE-2026-120650 | Medium | 2026-11-04 | Not applicable | No public exploit | CGI versions before 5.00 for Perl allow memory, CPU and disk exhaustion via missing or unenforced request size, parameter and upload limits. $CGI::POST_MAX defaults to no limit, and when set is not enforced for chunked multipart bodies or for the boundary line of a multipart body without a boundary= parameter. Bodies saved as PUTDATA, POSTDATA or PATCHDATA uploads are read into memory in one go, and nothing limits the number of parameters or uploads. |
| CVE-2026-118391 | High | 2026-11-04 | Not applicable | No public exploit | 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. |
| CVE-2026-115448 | High | 2026-11-04 | No exploit published | No public exploit | Uncontrolled recursion in Apache ZooKeeper. The server serializes its data tree to a snapshot by recursing one stack frame per znode level, with no depth bound. A client permitted to create znodes (the default root ACL is open) can build a chain of nested znodes deep enough that taking a snapshot exhausts the JVM stack and kills the snapshot thread; sizes stay within jute.maxbuffer, so existing limits do not prevent it. This is a denial of service that becomes persistent: on restart the server rebuilds the deep tree from its transaction log and fails again while taking the startup snapshot, so it does not return to service, and recovery can entail data loss. The same log affects a leader and its followers, so it can spread across an ensemble. This issue affects Apache ZooKeeper 3.8.0 through 3.8.7 and 3.9.0 through 3.9.6. Users are recommended to upgrade to 3.8.8 or 3.9.7, which fix the issue. As a workaround, use ACLs and authentication to restrict znode creation rather than relying on the default open root ACL. |
| CVE-2026-110944 | Low | 2026-11-04 | Not applicable | No public exploit | Resource exhaustion vulnerability in the HTTP request handling of the QHttpServer component of Qt HTTP Server. |
| CVE-2026-100302 | High | 2026-11-04 | No exploit published | No public exploit | Allocation of Resources Without Limits or Throttling in the multiRead request handler of Apache ZooKeeper allows a remote attacker to crash the server (denial of service) with a single small request. The multiRead handler places no limit on the number of bundled read operations or on the cumulative size of the response it builds in memory. Because each operation's result is fully materialized and retained before serialization, a request that is small on the wire — within the jute.maxbuffer limit — but that references a large znode many times can force the server to allocate far more heap than the request size implies, exhausting the JVM heap and terminating the server with an OutOfMemoryError. Neither jute.maxbuffer nor largeRequestMaxBytes prevents this, as both bound only the inbound request, not the response. This issue affects Apache ZooKeeper from 3.7.0 through 3.9.6. Users are recommended to upgrade to version 3.9.7, which enforces configurable limits on the multiRead operation count and cumulative response size. |
| CVE-2026-89295 | High | 2026-11-03 | Not applicable | No public exploit | In Eclipse Mnestix AAS Generator versions 0.1.0 up until but excluding 1.5.0, a practical upper bound on the client-supplied count parameter of the GET /api/v1/IdGenerator/submodelIds/{count} and GET /api/v2/IdGenerator/submodelIds/{count} endpoints is not enforced. The service generates and retains identifiers in memory before returning a response. A remote unauthenticated attacker can submit a large count to cause excessive memory consumption, potentially resulting in denial of service. Exploitation requires network access to the endpoint and successful retrieval of the ID-generation configuration from the configured backend repository. |
| CVE-2026-63501 | High | 2026-11-03 | Not applicable | Proof of concept only | ag-psd is a JavaScript library for reading and writing Photoshop Document files. Prior to 31.0.3, readPsd() accepts a totalMemoryLimit for parsing untrusted PSD files, but decodeLayerImageData expects a differently named memoryLimit property and therefore passes an undefined limit to createImageDataBitDepth. An attacker who can supply a PSD to an application with layer decoding enabled can use attacker-controlled layer dimensions to trigger an allocation larger than the configured limit, causing process memory exhaustion and denial of service. The advisory also identifies inflateSync(compressed) decompressing ZIP-encoded channel data without an output-size cap, which can cause a similar denial of service through unbounded decompression. This vulnerability is fixed in 31.0.1. |
| CVE-2026-121412 | High | 2026-11-03 | Not applicable | No public exploit | FreeRDP from 3.0.0 before 3.32.2 contains an uncontrolled resource consumption vulnerability in the proxy that lets connected clients retain heap memory via intercepted DVC message reassembly. Attackers can declare a large DATA_FIRST length and keep sending fragments without completing the message, growing proxy memory proportional to traffic and degrading service. |
| CVE-2026-121405 | Medium | 2026-11-03 | Not applicable | Proof of concept only | FreeRDP before 3.32.2 fails to cap the OutputBufferLength in serial device-control IRP requests, allowing malicious servers to trigger excessive memory allocation. Attackers running a server with serial redirection can send an IRP_MJ_DEVICE_CONTROL request with IOCTL_USBPRINT_GET_1284_ID and a near-maximum length to exhaust client memory. |
| CVE-2026-121403 | Medium | 2026-11-03 | Not applicable | Proof of concept only | FreeRDP before 3.32.2 contains a denial of service vulnerability where a malformed drive DEVICE_IOREQUEST with a truncated IRP_MJ_CREATE body silently kills the drive worker. A malicious RDP server can send such an IRP then post further requests that accumulate unbounded in the IrpQueue, exhausting memory and causing session availability loss. |
| CVE-2026-121399 | Medium | 2026-11-03 | Not applicable | Proof of concept only | FreeRDP before 3.32.2 contains a memory allocation vulnerability in rdg_receive_packet that allows a malicious RD Gateway to force a 2 GiB client allocation before tunnel authentication. Attackers can send an eight-byte RDG header declaring packet length 0x7FFFFFFF to trigger pre-authentication memory exhaustion and denial of service. |
| CVE-2026-121388 | High | 2026-11-03 | Not applicable | No public exploit | FreeRDP from 3.0.0 before 3.32.2 contains an uncontrolled resource allocation vulnerability that allows malicious RDP servers to force large client allocations through the DRDYNVC DATA_FIRST Length field. Attackers can declare lengths up to 4,294,967,295 bytes on running dynamic channels, causing StreamPool_Take to reserve memory before body validation and exhaust client memory. |
| CVE-2026-118488 | Medium | 2026-11-03 | No exploit published | Proof of concept only | In Eclipse Vert.x versions [4.0.0, 4.5.35] or [5.0.0, 5.2.2], when a malicious server keeps sending bytes on an EOL-terminated line (not length-prefixed, for example a simple string [1]), we'll keep growing the buffer without bounds, eventually leading to an OOM. We need to have a configurable limit for EOL-terminated lines. If a malicious server sends a specially crafted RESP response (for example a bulk string [2] with missing CRLF trailer), the parser enters an infinite loop where it keeps parsing the same buffer and pushing the same response to the caller, which may lead e.g. to an OOM if the consumer just buffers the responses. We must fix the parser to avoid this infinite looping. |
| CVE-2026-118487 | High | 2026-11-03 | No exploit published | Proof of concept only | In Eclipse Vert.x versions [4.0.0, 4.5.35] or [5.0.0, 5.2.2], the `FrameParser` in vertx-stomp creates a `RecordParser` without setting `maxRecordSize`, so any peer that streams bytes continuously without a newline character causes the parser to accumulate data indefinitely. Both the STOMP server and the STOMP client are affected: a malicious server can exploit this against a connecting client, and a malicious client can exploit this against a server before or after authentication. Sustained byte streaming exhausts JVM heap memory, crashing the affected process and causing a complete denial of service. |
| CVE-2026-116646 | Medium | 2026-11-03 | Not applicable | No public exploit | Tanium addressed an uncontrolled resource consumption vulnerability in Threat Response. |
| CVE-2026-115716 | Medium | 2026-11-03 | Not applicable | No public exploit | Allocation of Resources Without Limits or Throttling (CWE-770) in APM Server can lead to denial of service via Oversized Serialized Data Payloads (CAPEC-231). An attacker who can send OpenTelemetry (OTLP) data to APM Server over HTTP can cause APM Server to exhaust its memory and terminate. This stops the intake of APM and OpenTelemetry data until APM Server restarts. |
| CVE-2026-115715 | Medium | 2026-11-03 | Not applicable | No public exploit | Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can lead to denial of service via a specially crafted input value that is processed by an affected phonetic encoder of the analysis-phonetic plugin. An authenticated user with permission to write documents to or run searches against an index that uses an affected encoder can cause an Elasticsearch node to exhaust its heap memory. The node can become unresponsive or terminate. |
| CVE-2026-111751 | High | 2026-11-03 | Not applicable | No public exploit | Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. From 21.2.0 until 21.2.25 and 22.2.1, RouterLink directives rendered during Node.js server-side rendering retain computed UrlTree instances for the lifetime of each request. When queryParamsHandling is set to merge or preserve, either per link or through defaultQueryParamsHandling, every rendered link can retain a copy of attacker-controlled query parameters in its UrlTree. When upstream proxies or load balancers forward oversized query strings without rejecting them at the edge, multiple affected links and overlapping renders can amplify heap use until the Node.js old-space heap is exhausted and the SSR worker terminates. Numeric query-parameter names increase allocation pressure but are not required, memory is released after rendering completes, and pure client-side SPAs are not affected. This issue is fixed in versions 21.2.25 and 22.2.1. |
| CVE-2026-108147 | Medium | 2026-11-03 | Not applicable | No public exploit | An issue was discovered in Django 6.1 before 6.1.3, 6.0.4 before 6.0.10, and 5.2.13 before 5.2.19. `django.http.multipartparser.MultiPartParser` is subject to excessive memory consumption when processing multipart file uploads with base64 `Content-Transfer-Encoding`, which could be buffered entirely in memory before being passed to upload handlers. Earlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected. Django would like to thank Ignacy Kujawa for reporting this issue. |
| CVE-2026-108048 | Medium | 2026-11-03 | Not applicable | No public exploit | Vulnerability due to a lack of request limits in Alosuite’s password recovery functionality. The ‘/Account/resetPwd’ endpoint does not enforce adequate restrictions on the number or frequency of password reset requests sent for a single account. As a result, a remote attacker can repeatedly call the endpoint to generate an unlimited number of password reset emails addressed to a user, causing an email flood and enabling abuse of the password recovery mechanism. The absence of request limits or other controls against automation can harm legitimate users, consume application and email infrastructure resources, and facilitate automated attacks against the password recovery service. |
| CVE-2026-115215 | High | 2026-11-02 | Not applicable | No public exploit | In Eclipse ThreadX NetX Duo versions 6.0 through 6.5.2.202603a, the NetX Secure DTLS server allocates a session from its fixed session pool for the first datagram from any unrecognised address and port, before the cookie exchange, and never releases a session whose handshake stalls. A remote, unauthenticated attacker can exhaust the pool with one spoofed datagram per source and deny DTLS service to legitimate clients until the application resets the sessions. |
| CVE-2026-84170 | High | 2026-11-01 | No exploit published | No public exploit | Allocation of resources without limits or throttling in Apache Wicket. org.apache.wicket.markup.html.form.upload.resource.AbstractFileUploadResource is the server side of the form-less upload offered by FileUploadToResourceField, which posts the selected files to a separately mounted resource rather than through a Form. The resource is an application-wide singleton with no component to consult, so newResourceResponse() takes the three limits that bound the upload - the total request size, the maximum size of a single part and the maximum number of parts - from the request parameters maxSize, fileMaxSize and fileCountMax, and hands them to the multipart parser as they arrive. Nothing binds those numbers to the field that is supposed to be uploading. A request naming a very large maxSize is therefore parsed with no effective ceiling on the total size, and omitting fileMaxSize and fileCountMax leaves the per-part and part-count limits unset as well. The values the application configured through FileUploadToResourceField#setMaxSize(), #setFileMaxSize() and #setFileCountMax() are consulted only when the client omits the corresponding parameter, so against a client that supplies one they have no effect at all. Parts above the parser's in-memory threshold are spooled to the container's temporary directory, and the file parts are then copied into the folder the application's IUploadsFileManager owns, under a sub-folder the request names, where they remain. A part that is not a file is read into the heap in full while the request is parsed. One request, repeatable, can therefore consume as much disk or as much heap as the client chooses to send. The resource carries no authorization annotation and the default authorization strategy permits every resource request, so unless the application authorizes the resource itself the request needs no authentication, no session, no prior page view and no user interaction. An application is affected where it uses FileUploadToResourceField, or mounts FileUploadResourceReference itself. This is not the ordinary upload path: the resource is a singleton that has to be created and mounted deliberately. An application that configures no upload limit at all loses nothing, because Wicket applies no total-size limit of its own by default; what the defect removes is a limit the application set. Uploads through Form with FileUploadField, and through AjaxFileDropBehavior, are not affected, because both read their limits from the component rather than from the request. The upload resource does not exist in the 8.x line. This issue affects Apache Wicket: from 9.14.0 through 9.24.0, from 10.0.0 through 10.9.1. Users are recommended to upgrade to version 9.25.0 or 10.12.0, which fix the issue. |
| CVE-2026-119701 | Medium | 2026-10-30 | Not applicable | No public exploit | WPGraphQL before 2.24.1 contains a missing rate limiting vulnerability that allows unauthenticated attackers to flood password reset emails by aliasing the sendPasswordResetEmail mutation. Attackers can send one HTTP request with many aliases, bypassing batch_limit, to exhaust mail provider quota and repeatedly rotate reset keys, blocking legitimate password recovery. |
| CVE-2026-119699 | Medium | 2026-10-30 | Not applicable | No public exploit | WPGraphQL Smart Cache before 2.3.3 contains an uncontrolled resource consumption vulnerability that allows unauthenticated attackers to persist unlimited query documents via the Automatic Persisted Query handler. Attackers can send distinct queries with matching SHA-256 queryId values, including batched operations, to grow the wp_posts table without bound and degrade database performance. |
| CVE-2026-119036 | High | 2026-10-30 | Not applicable | No public exploit | Business::GoCardless versions before 1.01 for Perl allow memory exhaustion by flattening legacy webhook payloads before checking their signature. A webhook body with a top-level "payload" key is verified as a legacy webhook. To rebuild the signed string, the payload is flattened into one key and value pair per leaf, each key carrying the full path to that leaf, and the pairs are then encoded, sorted and joined. A long key holding a long array costs memory proportional to the key length times the array length. A remote attacker can exhaust memory in the process receiving webhooks with a single request that carries no valid signature. |
| CVE-2026-117350 | Medium | 2026-10-30 | Not applicable | No public exploit | Bitcoin Core prior to 29.5, 30.4, 31.2 and 32.1 is vulnerable to an OOM issue. |
| CVE-2026-117346 | High | 2026-10-30 | Not applicable | No public exploit | Bitcoin Core through 31.1 is vulnerable to Denial of Service via undo files having no size limit |
| CVE-2026-116128 | High | 2026-10-30 | Not applicable | No public exploit | Starlet versions from 0.20 before 0.33 for Perl allow memory exhaustion via unbounded buffering when decoding chunked request bodies. The decoder adds each read to one buffer of unconsumed input. Nothing limits the length of a chunk-size line, so a line without a CRLF grows the buffer for as long as the client keeps sending, and the read timeout restarts after every read. The data of a large chunk is also held in the buffer until the whole chunk has arrived. A remote attacker can exhaust a worker's memory with a single request. |
| CVE-2026-107312 | Medium | 2026-10-30 | Not applicable | No public exploit | Allocation of Resources Without Limits or Throttling vulnerability in Drupal Examples for Developers allows Excessive Allocation. This issue affects Examples for Developers versions: from 0.0.0 to 4.0.7. |
| CVE-2026-90991 | Medium | 2026-10-29 | Not applicable | No public exploit | IBM Langflow OSS 1.0.0 through 1.12.4 could allow a remote authenticated attacker to cause a denial of service due to allocation of resources without limits or throttling. |
| CVE-2026-119209 | High | 2026-10-29 | Not applicable | No public exploit | pypdf is a free and open-source pure-python PDF library. Prior to 6.21.3, pypdf can consume excessive memory while opening a crafted PDF containing cross-reference streams that declare very large entry counts. Highly compressible streams and /Prev chains can multiply the number of parsed entries across a document, while negative /Index counts can bypass the existing per-stream clamp. This issue is fixed in version 6.21.3. |
| CVE-2026-119134 | Medium | 2026-10-29 | Not applicable | No public exploit | Wasmtime before 36.0.18, 37.0.0 before 48.0.6, and 49.0.0 before 49.0.3 caps component-model resource handle tables only per component instance and does not charge handle allocations to any ResourceLimiter or StoreLimits. A malicious guest can repeatedly call resource.new and instantiate sub-components to exceed the per-instance cap many times over, causing unbounded host memory growth. |
| CVE-2026-119119 | High | 2026-10-29 | Not applicable | Proof of concept only | Crawl4AI before 0.9.5 contains a denial of service vulnerability in the Docker API server where _clamp_untrusted() fails to cap the delay_before_return_html, mean_delay, and max_range fields of untrusted CrawlerRunConfig bodies. Unauthenticated attackers can send huge values to /crawl or /crawl/stream to hold browser pages or stall the rate limiter, exhausting the page pool and blocking other crawls. |
| CVE-2026-119051 | High | 2026-10-29 | Not applicable | Proof of concept only | flat through 6.0.1 contains an uncontrolled resource allocation vulnerability in unflatten() that allows attackers to create huge sparse arrays via unbounded numeric keys. Attackers can supply flattened keys such as a.4294967294, causing iteration with forEach, spread or JSON.stringify to block the Node.js event loop. |
| CVE-2026-92665 | Medium | 2026-10-28 | Not applicable | No public exploit | Dell PowerProtect Data Domain, Feature Release versions 7.7.1.0 through 8.8, LTS2024 release versions 7.13.1.0 through 7.13.1.80, LTS2025 release versions 8.3.1.0 through 8.3.1.40, LTS2026 release versions 8.6.1.0 through 8.6.1.20, contain an Allocation of Resources Without Limits or Throttling vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Denial of service. |
| CVE-2026-118689 | High | 2026-10-28 | Not applicable | Proof of concept only | OvenMediaEngine through 0.21.0 contains a denial of service vulnerability in OvtPacket::LoadHeader() that allows unauthenticated attackers to stall connections by sending payload_length values above 32750. Attackers can send crafted OVT packets to the OVT listener to hold connections open indefinitely and accumulate buffered memory, disrupting origin-to-edge stream relay. |
| CVE-2026-118374 | High | 2026-10-28 | Not applicable | No public exploit | LibreSSL ocspcheck through 4.4.0 contains a memory exhaustion vulnerability that allows malicious OCSP responders to exhaust memory by sending unbounded HTTP responses. Attackers controlling the responder or intercepting plain HTTP AIA OCSP traffic can stream endless headers or body data to http_head_read() and http_body_read(), denying certificate status checks. |
| CVE-2026-118260 | High | 2026-10-28 | Not applicable | No public exploit | Echo is a Go web framework. From 4.0.0 until 4.16.1, Echo v4's opt-in BodyDump middleware reads complete request bodies into memory before handlers run and retains complete response bodies for the dump callback without capture limits. An unauthenticated client that can reach a route using BodyDump can submit large bodies or influence large responses, causing repeated or concurrent allocations that exhaust process memory. BodyDump is not enabled by default, and external request limits may reduce request-side exposure but do not bound response capture. This issue is fixed in 4.16.1. |
| CVE-2026-118036 | High | 2026-10-28 | Not applicable | No public exploit | In Progress® Telerik® Document Processing Libraries prior to version 2026.3.1027, uncontrolled recursion, infinite loop, inefficient algorithmic complexity and resource allocation vulnerabilities in RadPdfProcessing and AI document summarization and question answering allow an unauthenticated attacker to terminate or hang the host process via a crafted PDF document or document text submitted for summarization or question answering. |
| CVE-2026-117501 | High | 2026-10-28 | Not applicable | No public exploit | HTTP::Body versions before 1.24_01 for Perl allow memory exhaustion via unbounded buffering of chunked request bodies. In chunked mode, used when no content length is given, add() holds each chunk in memory until all of it has arrived. A line that is not a chunk-size line, a size line without CRLF, or a size too large to fit an integer leaves the parser waiting forever, and every later add() grows the buffer. A remote attacker can exhaust memory in applications that pass chunked request bodies to HTTP::Body. |
| CVE-2026-116273 | High | 2026-10-28 | Not applicable | No public exploit | MIME::Parser versions before 5.521 for Perl set no limit on the number of message parts by default, allowing memory exhaustion. The max_parts option defaulted to -1, which disables the limit, so a parser created with default settings builds an entity for every part however many a message has. Version 5.521 sets max_parts to 1000 and max_depth to 64 by default. Setting either to -1 still removes the limit. |
| CVE-2026-116134 | High | 2026-10-28 | Not applicable | No public exploit | HTTP::Body versions before 1.23_01 for Perl allow memory exhaustion via an unbounded multipart part header block. The multipart parser takes everything up to the first blank line after a boundary as the part's header block, with no limit on its size or number of lines. Every line is stored in the part's header hash, so a block of short lines costs about 60 bytes of memory per input byte. A remote attacker can exhaust worker memory with a single request. |
| CVE-2026-116131 | Medium | 2026-10-28 | Not applicable | No public exploit | HTTP::Body versions before 1.23_01 for Perl allow memory and temporary file exhaustion via an unlimited number of form fields and multipart parts. The urlencoded parser splits the whole body on its separators at once, creating one scalar per separator before any field is stored. This costs about 90 bytes of memory per separator byte. The multipart parser creates a temporary file for every part that carries a filename. Neither parser limits how many fields or parts a body may hold. A remote attacker can exhaust worker memory with a body made of separators, or create thousands of temporary files with one request of small file parts. |
| CVE-2026-116078 | High | 2026-10-28 | Not applicable | Proof of concept only | Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/2 request body reader of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via a request body sent as many 1-byte DATA frames. do_read_data/5 in lib/bandit/http2/stream.ex keeps every DATA frame payload as its own list element until the read returns. The :length option of read_body/2 counts body bytes, not frames, so a body of 1-byte frames costs a list cell and a binary term per byte. Interleaving the frames across up to 500 concurrent streams per connection keeps each stream consuming its frames as they arrive; in the reporter's test, 100 streams held 25 to 40 MiB of stream process memory for 5 MB sent. Only routes whose Plug reads the request body are affected, which includes any route behind Plug.Parsers. This issue affects bandit: from 0.3.1 before 1.14.1. |
| CVE-2026-111115 | Critical | 2026-10-28 | No exploit published | No public exploit | Apache Kafka's code-generated readers for flexible protocol versions read a tagged-field count declared by the sender and retain a RawTaggedField object for each unknown field. That count was bounded only by the outer request frame size (socket.request.max.bytes); it was not checked against the remaining buffer bytes or capped. Because each entry can be encoded in as little as two bytes (unknown tag 0, size 0), a modest request can declare tens of millions of tagged fields and force one object allocation per declared field. Flexible request headers (header version 2, used by flexible APIs such as ApiVersions v3) are parsed this way, so the amplification applies to the request header itself. Impact: The flexible request header is parsed on the network thread before authorization, request dispatch, and request-time quota accounting. A client can send a request of a few tens of megabytes whose header declares about 20 million tagged fields, forcing roughly that many RawTaggedField allocations and exhausting broker heap or inducing process-wide GC stalls, denying broker service. Because the header is parsed for pre-authentication APIs such as ApiVersions (v3), the allocation can occur before authentication; no Kafka resource ACL or quota is required. Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes and restricting network access to broker listeners reduces, but does not remove, exposure. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers bounds-check the tagged-field count for flexible-versioned messages, rejecting a negative count, a count exceeding the remaining buffer bytes, or a count exceeding a fixed maximum (10,000), before any per-field allocation. |
| CVE-2026-111108 | Critical | 2026-10-28 | No exploit published | No public exploit | Apache Kafka's code-generated protocol readers pre-size an array's collection from the element count declared by the sender. That count is checked only against the bytes remaining in the request buffer, which assumes about one byte per element; because most elements need several bytes, a request can declare far more elements than the buffer holds and still pass. For a keyed array the reader then allocates an ImplicitLinkedHashCollection of capacity (2 * count +1), so a request of a few tens of megabytes can force a heap allocation several times larger before any element is read. The pattern is emitted into every generated reader, so it affects all Kafka API types with an array field. Impact: Request parsing happens before any authorization check. On a listener that does not require authentication (for example PLAINTEXT), an unauthenticated attacker can send a few concurrent requests that each declare a very large= array length and allocate many times their wire size in broker heap, crashing the broker with an OutOfMemoryError. The reporter demonstrated three concurrent ~90 MB ProduceRequest (v3) connections exhausting a 1 GB heap (~8x amplification). On listeners that require authentication, the attacker needs valid credentials but no specific ACL, since parsing precedes authorization.. Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes and restricting network access to broker listeners reduces, but does not remove, exposure. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers cap the initial array pre-allocation at MessageUtil.MAX_PREALLOCATED_ARRAY_CAPACITY (1000) and grow it on demand, and reject a declared array length above MessageUtil.MAX_ARRAY_LENGTH (1,000,000). |
| CVE-2026-111073 | Medium | 2026-10-28 | No exploit published | No public exploit | The broker-side PushTelemetry API (KIP-714) validates only the compressed size of a client's metrics payload against telemetry.max.bytes (default 1 MB) before decompressing it. ClientTelemetryUtils.decompress() then decompresses the payload with no limit on the decompressed output size, growing a heap buffer until the compressed input is exhausted. A small, highly compressible payload (for example gzip-compressed zeros) can therefore expand to hundreds of megabytes of broker heap. Impact: An authenticated client can send a PushTelemetry request with a small compressed payload that decompresses to a very large size, consuming broker heap out of proportion to the request size. Repeated or concurrent requests can exhaust the broker heap and cause an OutOfMemoryError, degrading or crashing the broker; a client that targets multiple brokers can affect cluster availability. PushTelemetry is available to any authenticated client and is not gated by an ACL. Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.1, or 4.4.0. On affected versions there is no configuration that fully prevents the amplification, because telemetry.max.bytes bounds only the compressed size; lowering telemetry.max.bytes reduces the worst-case decompressed size proportionally and is a partial mitigation. Resolution: - From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: ClientTelemetryUtils.decompress() enforces a maximum decompressed size equal to telemetry.max.bytes (default 1 MB). Decompression reads in bounded chunks and aborts with a TelemetryTooLargeException once the decompressed total exceeds the limit, so an over-large or highly compressible payload is rejected instead of being fully expanded in heap. The decompressed size is therefore bounded by default. |
| CVE-2026-54462 | Medium | 2026-10-27 | Not applicable | Proof of concept only | Knative pkg provides common packages shared across Knative repositories. Prior to 0.0.0-20260531000007-52dbd5ece63f, the knative.dev/pkg/webhook admissionHandler in webhook/admission.go decodes an attacker-supplied AdmissionReview through json.NewDecoder(io.TeeReader(r.Body, &bodyBuffer)) under an http.HandlerFunc without an http.MaxBytesReader or equivalent body-size limit. A pod-network client can send one oversized POST to an admission webhook, causing the decoder and bodyBuffer to retain amplified copies of the request until the controller pod exhausts memory and is OOM-killed. Every downstream consumer using the shared webhook server inherits the vulnerable behavior, including Knative, Tekton, KEDA, Sigstore policy-controller, and Kpack. For consumers configured with failurePolicy=Fail, loss of the controller can interrupt admission; with failurePolicy=Ignore, the affected webhook is unavailable while other admissions continue. This issue is fixed in version 0.0.0-20260531000007-52dbd5ece63f. |
| CVE-2026-116877 | High | 2026-10-27 | Not applicable | Proof of concept only | Semantic MediaWiki from 2.5.0 before 7.3.1 contains an uncontrolled resource consumption vulnerability that allows low-privilege editors to bypass smwgMaxNumRecurringEvents by supplying a large limit parameter. Attackers can save pages using #set_recurring_event without an end date to generate thousands or millions of date subobjects, exhausting CPU, memory, and database resources. |
| CVE-2026-116775 | Low | 2026-10-27 | Not applicable | Proof of concept only | pageant provides a PageantStream type that implements AsyncRead and AsyncWrite traits and can be used to communicate with a running Pageant instance. From 0.2.0 until 0.2.5, PageantStream::new in pageant/src/wmmessage.rs trusts a peer-controlled four-byte length prefix and buffers until len + 4 bytes are available without checking the fixed _AGENT_MAX_MSGLEN transport capacity. An application that bridges an SSH forwarded-agent channel to the raw stream can allow a malicious server to force large allocations or retain a partially filled frame, causing client memory exhaustion. This issue is fixed in version 0.2.5. |
| CVE-2026-116773 | Medium | 2026-10-27 | Not applicable | Proof of concept only | russh is a Rust SSH client and server library that includes an SSH agent protocol implementation. Prior to 0.65.0, the client Session::process_packet path in russh/src/client/encrypted.rs accepts repeated packets encoded with russh's private msg::EXT_INFO = 7 before authentication, while the standards-compliant EXT_INFO message number 82 does not reach the affected handler. The handle_ext_info function appends every parsed extension name to received_extensions without clearing, deduplicating, or bounding the vector. A malicious SSH server that deliberately sends private message number 7 can therefore retain an unbounded number of attacker-controlled extension names for the session lifetime, causing progressive client memory exhaustion. This issue is fixed in version 0.65.0. |
| CVE-2026-116696 | Low | 2026-10-27 | Not applicable | Proof of concept only | russh is a Rust SSH client and server library that includes an SSH agent protocol implementation. Prior to 0.65.0, russh::keys::agent::server::serve in russh/src/keys/agent/server.rs accepts repeated SSH_AGENT_CONSTRAIN_CONFIRM records while adding a key and appends every Constraint::Confirm record to the key's retained constraint vector without a count or memory limit. A process that can connect to the agent socket, including the remote side of a forwarded agent session, can repeatedly add constrained keys and cause renewable memory growth that persists for the process lifetime because keys without a lifetime constraint do not expire. This issue is fixed in version 0.65.0. |
| CVE-2026-116694 | Medium | 2026-10-27 | Not applicable | No public exploit | OpenTelemetry Python provides the Python API and SDK for OpenTelemetry. Prior to 1.45.0, JaegerPropagator.extract() in opentelemetry-propagator-jaeger processes inbound uberctx-* baggage values without entry, per-entry byte, or total-byte limits. Services that enable the optional Jaeger propagator can perform unnecessary CPU work and short-lived heap allocations when an untrusted carrier supplies numerous or oversized values, contributing to denial of service when transport-level limits do not constrain the input. Common default Python HTTP server limits reduce the practical impact, while custom getters, non-HTTP transports, or raised header limits increase exposure. This issue is fixed in version 1.45.0. |
| CVE-2026-116659 | Medium | 2026-10-27 | Not applicable | No public exploit | Tanium addressed an uncontrolled resource consumption vulnerability in Enforce. |
| CVE-2026-116657 | Medium | 2026-10-27 | Not applicable | No public exploit | Tanium addressed a denial of service vulnerability in Enforce. |
| CVE-2026-108310 | Medium | 2026-10-27 | Not applicable | No public exploit | Tanium addressed a denial of service vulnerability in Tanium Server. |
| CVE-2026-108309 | Medium | 2026-10-27 | Not applicable | No public exploit | Tanium addressed an uncontrolled resource consumption vulnerability in Performance Client Extension. |
| CVE-2026-97200 | High | 2026-10-26 | Not applicable | No public exploit | Allocation of Resources Without Limits or Throttling vulnerability in hackney_conn in benoitc hackney allows a malicious HTTP server to exhaust client memory via an oversized or highly compressed response body. hackney:request/5 and hackney:body/1 return the whole response body, and nothing bounds how much the connection process buffers. Any server the client requests can trigger it. hackney_conn:read_full_body/2 and the HTTP/2 and HTTP/3 accumulators append every chunk until the body ends. With {auto_decompress, true} the buffered body is then inflated in one step with zlib:gunzip/1 or zlib:inflate/2, which return the whole output at once. This issue affects hackney: from 2.0.0-beta.1 before 4.9.0. |
| CVE-2026-116587 | High | 2026-10-26 | Not applicable | No public exploit | Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. Prior to 4.1.6, go-jose parses attacker-controlled RSA modulus and prime values from JWKs without enforcing size and consistency bounds before passing them to crypto/rsa.PrivateKey.Validate. On Go 1.24 and later, crafted large or degenerate RSA parameters can make that validation consume cubic CPU time, allowing remote denial of service in applications that parse JWKs from untrusted sources. This issue is fixed in version 4.1.6. |
| CVE-2026-116584 | High | 2026-10-26 | Not applicable | No public exploit | Seroval facilitates JavaScript value stringification, including complex structures beyond JSON.stringify capabilities. From 1.4.1 until 1.6.8, fromJSON and fromCrossJSON do not require an array node's element list to be an actual array. A small crafted payload can supply an attacker-controlled length that determines memory allocation and decoder iterations independently of payload size, allowing an unauthenticated request to exhaust the process or block its thread. This issue is a residual bypass of the remediation for CVE-2026-23957. This issue is fixed in version 1.6.8. |
| CVE-2026-116579 | Medium | 2026-10-26 | Not applicable | No public exploit | Autobahn Python is a WebSocket and WAMP implementation for Python that supports Twisted and asyncio. From 26.7.1 until 26.10.1, PerMessageBrotli.decompress_message_data in compress_brotli.py calls the Brotli decompressor without an output limit and checks maxMessagePayloadSize only after a complete frame has been inflated. An unauthenticated WebSocket client can send a small, highly compressed frame that allocates hundreds of MiB before rejection, causing memory-exhaustion denial of service on servers that enable the opt-in permessage-brotli feature through the compress extra. Deflate and bzip2 already enforce the remaining output budget and are outside this residual vulnerability. This issue is fixed in version 26.10.1. |
| CVE-2026-116577 | Medium | 2026-10-26 | Not applicable | No public exploit | Tornado is a Python web framework and asynchronous networking library. Prior to 6.6, Tornado's HTTP header parser accepts obsolete line folding and repeatedly concatenates short continuation lines, causing quadratic CPU consumption on the IOLoop thread. An unauthenticated client can submit a header block containing many obsolete line-folding continuations before application code runs, blocking other connections served by the process. The cost grows with max_header_size, and only availability is affected. This issue is fixed in version 6.6. |
| CVE-2026-116120 | Medium | 2026-10-26 | Not applicable | No public exploit | A vulnerability was determined in NocoDB up to 2026.07.0. This vulnerability affects the function UserRefreshToken.deleteAllUserToken of the file /auth/user/signup of the component PublicApiLimiterGuard. This manipulation causes allocation of resources. The attack is possible to be carried out remotely. The attack is considered to have high complexity. It is stated that the exploitability is difficult. Code-verified absence of in-app rate limiting on the unauthenticated signup and password-forgot endpoints and per-request refresh/OAuth token invalidation, but the vendor documents the pass-through limiter as intentional design. The vendor deleted the GitHub issue for this vulnerability without any explanation. Afterwards the vendor was contacted early about this disclosure via email but did not respond in any way. |
| CVE-2026-115927 | Medium | 2026-10-26 | Not applicable | No public exploit | Tornado is a Python web framework and asynchronous networking library. Prior to 6.6.0, Tornado decodes HTTP/1.1 chunked transfer encoding by processing body data that has already arrived without yielding to the event loop. A remote unauthenticated peer can send millions of one-byte chunks to monopolize the process event loop and stall every other connection served by that process, while lowering max_body_size only limits the duration of each request. For handlers that do not use @stream_request_body, retaining each chunk as a separate object can consume roughly twenty times the received body size, and SimpleAsyncHTTPClient has the same event-loop behavior when reading a response from a malicious server. This issue is fixed in version 6.6.0. |
| CVE-2026-115918 | Medium | 2026-10-26 | Not applicable | No public exploit | vLLM is an inference and serving engine for large language models. From 0.16.0 until 0.32.0, the /v1/responses endpoint allows an authenticated caller to place an attacker-controlled template in chat_template_kwargs[chat_template] when no server template is configured. ChatParams.get_apply_chat_template_kwargs() preserves that value without enforcing trust_request_chat_template, so the request can bypass the intended trust policy and cause CPU or memory exhaustion through Jinja rendering. This issue is fixed in version 0.32.0. |
| CVE-2026-115913 | Medium | 2026-10-26 | Not applicable | No public exploit | vLLM is an inference and serving engine for large language models. Prior to 0.32.0, the Phi-4 multimodal audio encoder in phi4mm_audio.py and phi4mm_utils.py uses eager attention by default, allowing a remote client to submit one legal long audio clip that causes MultiHeadedAttention.forward_attention to materialize and retain full attention matrices in self.attn. The scaled dot-product attention branch does not materialize these matrices. The resulting quadratic GPU-memory use can cause an out-of-memory condition and terminate EngineCore for all users. This issue is fixed in version 0.32.0. |
| CVE-2026-115911 | Medium | 2026-10-26 | Not applicable | No public exploit | vLLM is an inference and serving engine for large language models. From 0.19.0 until 0.32.0, authenticated callers can supply a request chat template when no server-side --chat-template is configured, or a malicious model repository can provide a template that is compiled and rendered by tokenizer.apply_chat_template() without a wall-clock timeout, output-size limit, or iteration bound. Rendering runs in a ThreadPoolExecutor with one worker by default, so a nonterminating render can block /v1/responses and other chat-template users after the request ends, while an output-expanding render can exhaust server memory. Harmony models are not affected because they do not use this Jinja path. This issue is fixed in version 0.32.0. |
| CVE-2026-115721 | High | 2026-10-26 | No exploit published | No public exploit | **UNSUPPORTED WHEN ASSIGNED** Unbounded allocation in XML parsing in Apache Vysper; all versions, may lead to an out of memory condition. This issue affects all versions of Apache Vysper. Apache Vysper is an XMPP (Jabber) server library. As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative. |
| CVE-2026-115269 | High | 2026-10-26 | Not applicable | No public exploit | Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/2 request body reader of mtrudel bandit allows an unauthenticated remote attacker to hold stream processes open indefinitely via WINDOW_UPDATE or empty SETTINGS frames sent while a Plug reads the request body. Bandit.HTTP2.Stream.do_read_data/4 in lib/bandit/http2/stream.ex waits for each frame with a fresh read_timeout. A stream WINDOW_UPDATE, or the zero-delta window update that every empty SETTINGS frame delivers to all streams, ends the wait without delivering any body data, and the loop starts a new full countdown. A client that sends one of these 9-byte frames before each countdown expires keeps read_body blocked, together with the stream process and whatever the application holds while reading, for as long as it likes. This issue affects bandit: from 1.4.0 before 1.14.0. |
| CVE-2026-114213 | High | 2026-10-26 | Not applicable | No public exploit | Allocation of Resources Without Limits or Throttling vulnerability in the WebSocket fragment reassembly of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via a fragmented message made of many 1-byte continuation frames. Bandit.WebSocket.Connection checks max_fragmented_message_size against the payload bytes received, but keeps every non-final continuation frame as a new list cell around its own binary, and nothing limits the number of fragments. A 1-byte fragment costs 7 bytes on the wire but about 150 to 170 bytes of server memory, so one connection can hold about 150 times the configured limit, roughly 1.2 to 1.4 GB at the default 8 MB. Ping frames between fragments keep the connection alive past the idle timeout. This issue affects bandit: from 1.11.0 before 1.14.0. |
| CVE-2026-112671 | High | 2026-10-26 | Not applicable | No public exploit | A resource exhaustion issue was addressed with improved input validation. This issue is fixed in iOS 26.7.2 and iPadOS 26.7.2, iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2, visionOS 27.2. A remote attacker may be able to cause a denial-of-service. |
| CVE-2026-111101 | High | 2026-10-26 | Not applicable | No public exploit | Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/1.1 chunked body reader of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory and CPU via a request body made of many 1-byte chunks. The chunked reader in lib/bandit/http1/socket.ex keeps every chunk as its own list cell and binary term until IO.iodata_to_binary/1 joins them, and nothing limits the number of chunks. The :length option of read_body/2 counts only data bytes, so tiny chunks cost far more memory than their payload: 48 MB of 1-byte chunks grew one handler process to about 500 MB and took about 6 s of CPU. The route does not need to read the body, because on keep-alive connections ensure_completed/1 drains unread bodies through the same reader. This issue affects bandit: from 0.1.0 before 1.14.0. |
| CVE-2026-110499 | High | 2026-10-26 | Not applicable | No public exploit | Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to grow per-connection memory and CPU cost without bound via a large SETTINGS_HEADER_TABLE_SIZE. Bandit resizes its HPACK encoder table to whatever size the client advertises, up to 2^32-1 bytes, and indexes response headers into it. Because responses carry distinct values such as date or content-length, nothing is evicted and the table grows with every response for the life of the connection, while each lookup scans it linearly. The SETTINGS handling in Bandit.HTTP2.Connection (lib/bandit/http2/connection.ex) passes remote_settings.header_table_size to HPAX.resize/2 with no server-side cap, and encode_headers encodes every response header as :store. Serving N responses on one connection therefore costs O(N²) CPU in the connection process. This issue affects bandit: from 0.3.6 before 1.14.0. |
| CVE-2026-108525 | High | 2026-10-26 | Not applicable | No public exploit | Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via DATA frames sent past the advertised receive window. The attacker requests a response larger than the 65,535-byte initial window and withholds WINDOW_UPDATE, so the stream process blocks while sending and stops reading, then floods small DATA frames on that stream. Every frame is queued in the stream's mailbox until the BEAM node runs out of memory. Bandit.HTTP2.Connection.handle_frame/3 in lib/bandit/http2/connection.ex forwards each DATA frame to the stream process without consulting the receive window, and Bandit.HTTP2.FlowControl.compute_recv_window/2 replenishes the window as data arrives rather than as it is consumed, and never answers a violation with FLOW_CONTROL_ERROR. This issue affects bandit: from 0.3.1 before 1.14.0. |
| CVE-2026-105626 | High | 2026-10-26 | Not applicable | No public exploit | HashiCorp Consul and Consul Enterprise are vulnerable to a denial of service in the HTTP API that may allow an unauthenticated attacker to exhaust memory on a Consul agent. This vulnerability (CVE-2026-105626) is fixed in Consul Community Edition 2.1.0 and Consul Enterprise 2.1.0 and 1.21.19. |
| CVE-2026-116179 | High | 2026-10-25 | Not applicable | No public exploit | vLLM from 0.18.0 before 0.31.0 contains a resource exhaustion vulnerability that allows API clients to bypass the video/jpeg frame-count cap by overriding num_frames through media_io_kwargs. Attackers can set num_frames to -1 with a large inline video so VideoMediaIO.load_base64 decodes every frame, exhausting memory and crashing the API frontend. |
| CVE-2026-116143 | Medium | 2026-10-25 | Not applicable | No public exploit | ImageMagick before 6.9.13-58 and 7.x before 7.1.2-33 contains a policy bypass in the PS, PDF and XPS decoders that allows the security policy's list length limit on scene selection to be circumvented. Attackers supplying a specific argument can cause ImageMagick to process more scenes than permitted, potentially exhausting resources. |
| CVE-2026-115824 | High | 2026-10-25 | Not applicable | No public exploit | Starman versions before 0.4019 for Perl allow memory exhaustion via unbounded buffering of chunked request bodies. The chunked body decoder keeps each chunk in memory until the whole chunk and its CRLF have arrived, and sets no limit on the length of a chunk-size line. A client that declares a huge chunk size and streams data, or sends a chunk-size line that never ends, grows the buffer for as long as it keeps sending. A remote attacker can exhaust worker memory with a single connection. |
| CVE-2026-115817 | High | 2026-10-25 | Not applicable | No public exploit | Starman versions before 0.4019 for Perl allow a stalled request body to hold a worker indefinitely, as read_timeout covers only the headers. Content-Length and chunked request bodies are read with blocking reads and no deadline. A client that sends complete headers and then stalls or trickles the body keeps the worker waiting until it disconnects. A remote attacker can take every worker with a few such connections, five with the default worker count, so the server stops answering requests. Version 0.4019 applies read_timeout to each wait for body data and adds a body_timeout limit, 300 seconds by default, on the total time to read a body. |
| CVE-2026-86019 | Medium | 2026-10-23 | Not applicable | Proof of concept only | Part-DB is an open source inventory management system for electronic components. Prior to version 2.13.2, Part-DB allows authenticated API users to bypass the configured maximum attachment file size by uploading attachments through the API using base64-encoded file data. The application enforces the configured attachment size limit for normal browser-based file uploads, but the API base64 upload path does not apply the same size validation. As a result, an authenticated user with API access and permission to create attachments can upload files larger than the configured maximum attachment size, potentially exhausting disk space and causing a denial of service. This issue has been patched in version 2.13.2. |
| CVE-2026-86018 | Medium | 2026-10-23 | Not applicable | Proof of concept only | Part-DB is an open source inventory management system for electronic components. Prior to version 2.13.2, Part-DB allows authenticated users to bypass the configured maximum attachment file size when using the server-side “Download external file” attachment feature. When server-side attachment downloads are enabled, Part-DB downloads the remote file and streams it directly to disk without enforcing the configured MAX_ATTACHMENT_FILE_SIZE limit. As a result, an authenticated user who can create or edit attachments can cause Part-DB to store files larger than the configured maximum attachment size, potentially exhausting disk space and causing a denial of service. This issue has been patched in version 2.13.2. |
| CVE-2026-115778 | High | 2026-10-23 | Not applicable | No public exploit | Twisted is an event-based framework for internet applications, supporting Python 3.6+. Prior to 26.10.0rc1, twisted.conch.telnet.Telnet.dataReceived appends every byte received after IAC SB to a persistent subnegotiation buffer until IAC SE is received, without applying a maximum length. Telnet option negotiation occurs before authentication, so an unauthenticated peer can omit the terminator and continuously grow the buffer. The resulting memory exhaustion can terminate the process and every service it hosts. This issue is fixed in version 26.10.0rc1. |
| CVE-2026-115776 | High | 2026-10-23 | Not applicable | No public exploit | Twisted is an event-based framework for internet applications, supporting Python 3.6+. Prior to 26.10.0rc1, twisted.words.protocols.irc.IRC.dataReceived retains all bytes received without a line feed in its per-connection buffer and applies no maximum line length. The twisted.words.service.IRCUser server subclass inherits this behavior, and buffering occurs before PASS, NICK, or USER authentication commands. An unauthenticated connection can continuously grow the buffer until the shared server process runs out of memory and drops all users. This issue is fixed in version 26.10.0rc1. |
| CVE-2026-115775 | High | 2026-10-23 | Not applicable | Proof of concept only | Twisted is an event-based framework for internet applications, supporting Python 3.6+. Prior to 26.10.0rc1, the twisted.words.xish.domish ExpatElementStream parser allows an unauthenticated remote peer to keep a container element open while continuously adding child elements. The parser retains the unfinished stanza as an in-memory tree without a byte or element-count limit, and XMPP pre-authentication stream parsing exposes this behavior before credentials are accepted. A single connection can therefore exhaust server memory and terminate the process. This issue is fixed in version 26.10.0rc1. |
| CVE-2026-96377 | Medium | 2026-10-22 | Not applicable | No public exploit | Allocation of Resources Without Limits or Throttling vulnerability in Drupal Combined image style allows Excessive Allocation. This issue affects Combined image style versions: from 0.0.0 to 1.0.7. |
| CVE-2026-96365 | High | 2026-10-22 | Not applicable | No public exploit | Allocation of Resources Without Limits or Throttling vulnerability in Drupal Webform allows Excessive Allocation. This issue affects Webform versions: from 0.0.0 to 6.2.12, from 6.3.0 to 6.3.1. |
| CVE-2026-94482 | High | 2026-10-22 | Not applicable | No public exploit | Next.js is a React framework for building full-stack web applications. From 13.0.0 until 15.5.28 and 16.4.1, crafted requests targeting App Router applications with at least one Server Action can cause excessive CPU consumption and block processing of further requests in the same process. Applications using the Pages Router and App Router applications without Server Actions are not affected. This issue is fixed in versions 15.5.28 and 16.4.1. |
| CVE-2026-86696 | High | 2026-10-22 | Not applicable | Proof of concept only | Allocation of Resources Without Limits or Throttling vulnerability in esaml in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via unsigned LogoutResponse messages. esaml:status_code_map/1 in src/esaml.erl maps any StatusCode value it does not recognize to an atom with list_to_atom/1 on the last colon-separated segment of the URN. esaml_sp:validate_logout_response/2 verifies a signature only when the message carries one, so an unsigned LogoutResponse posted to the single-logout endpoint reaches esaml:decode_logout_response/1 and mints one permanent atom per distinct status value. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so an attacker who posts that many distinct values aborts the node. This issue affects esaml: from 0.1.0 onward. |
| CVE-2026-75508 | High | 2026-10-22 | Not applicable | Proof of concept only | GraphQL-core is a Python port of the GraphQL.js reference implementation. From 3.2.3 until 3.2.12 and 3.3.0rc1, the parser's max_tokens limit in Parser.advance_lexer counts only non-comment tokens returned after Lexer.lookahead skips comments. Each skipped comment is still allocated as a Token and retained through token.next and token.prev, allowing a highly compressible comment-padded GraphQL document to pass a low token limit while consuming memory. An unauthenticated remote attacker can exhaust worker memory before AST-based depth or complexity controls run. This issue is fixed in versions 3.2.12 and 3.3.0rc1. |
| CVE-2026-115482 | High | 2026-10-22 | Not applicable | No public exploit | In lsquic before 4.9.0, the HTTP/3 implementation can use an excessive amount of memory because the number of buffered header sets is not limited, as demonstrated by a QPACK amplification attack. This is related to header_out_dynamic_entry and es_max_header_list_size. |
| CVE-2026-115454 | Medium | 2026-10-22 | Not applicable | No public exploit | An excessive resource allocation issue in the remote workflow editing capabilities of KNIME Business Hub prior to version 1.19.0 allows a authenticated attack to exhaust resources on the server side. This leads to intermittent unavailability of workflow execution functionality. A workaround is not possible. |
| CVE-2026-115398 | Medium | 2026-10-22 | Not applicable | No public exploit | Ghidra before 12.2 contains a resource allocation without limits vulnerability in FileSystemIndexHelper used by TarFileSystem and ZipFileSystem, which store unbounded archive entries. Attackers can persuade a user to open or batch-import a crafted TAR or ZIP archive with excessive entries to exhaust the Java heap and hang the session. |
| CVE-2026-115397 | Medium | 2026-10-22 | Not applicable | No public exploit | Ghidra before 12.2 contains a resource allocation without limits vulnerability in ExtensionUtils.unzipToInstallationFolder() that extracts every extension ZIP entry without limiting file count. Attackers who persuade a user to install a crafted extension archive with many files can exhaust filesystem inodes, causing project writes and other processes to fail. |
| CVE-2026-115395 | Medium | 2026-10-22 | Not applicable | No public exploit | Ghidra 10.3 before 12.2 contains a resource allocation without limits vulnerability in ThemeReader.readZipTheme() that extracts unlimited theme ZIP entries to the images directory. Attackers can persuade users to import a crafted theme archive with many small files, exhausting inodes and disk space to deny service to the host. |
| CVE-2026-115391 | Medium | 2026-10-22 | Not applicable | No public exploit | Wasmtime 46.0.0 before 46.0.3 and 47.0.0 before 47.0.4 contains an uncontrolled resource allocation vulnerability in its WASIp3 implementation that buffers guest-specified-length writes on the host without limit. Malicious guests can offer large buffers to WASIp3 file or HTTP write streams, causing the host to copy and buffer all bytes, bounded only by guest linear memory, exhausting host memory. |
| CVE-2026-115389 | Low | 2026-10-22 | Not applicable | No public exploit | Wasmtime before 36.0.16, 37.0.0 before 48.0.3, and 49.0.0 before 49.0.1 does not adequately account for host allocations when lifting guest values through the dynamically-typed Val API, bypassing the hostcall fuel limit. A malicious WebAssembly guest can return crafted values that allocate at least ~100x more host memory than tracked, causing denial of service. |
| CVE-2026-115381 | Medium | 2026-10-22 | Not applicable | No public exploit | Wasmtime before 36.0.17, 37.0.0 before 48.0.4, and 49.0.0 before 49.0.2 contains an unbounded memory allocation in the wasmtime-wasi WASIp2 write-zeroes method of SinkOutputStream, the default stream used when stdout/stderr are not configured. A malicious WebAssembly guest can request huge zero-filled writes, exhausting host memory and causing denial of service. |
| CVE-2026-115380 | Medium | 2026-10-22 | Not applicable | No public exploit | Wasmtime before 36.0.17, 37.0.0 before 48.0.4, and 49.0.0 before 49.0.2 contains a denial of service vulnerability in the wasmtime-wasi WASI preview 0 poll_oneoff adapter, which performs O(n) host work per subscription without consuming or checking fuel. Malicious guest modules can pass many subscriptions to force long-running host computation that ignores configured fuel limits. |
| CVE-2026-114731 | Medium | 2026-10-22 | Not applicable | No public exploit | Roundcube Webmail before 1.6.20 and 1.7.x before 1.7.5 is affected by an uncontrolled resource consumption vulnerability in the CSS proxy (the utils/modcss action). The fetched stylesheet was read into memory in full, with no size limit and no read timeout, so a stylesheet URL referencing an attacker-controlled host could be used to exhaust server memory. Upstream fixed this in the commit “Add a size limit to the CSS proxy content processing”, which caps the response at 5 MB, reads it as a stream and applies a read timeout. |