Total
330 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-83745 | 2026-10-02 | N/A | N/A | ||
| Memory allocation with excessive size value, Improper handling of length parameter inconsistency vulnerability in Apache Thrift nodejs and D lang bindings. Both bindings' WebSocket server transports read the payload length out of the frame header and allocate that many bytes immediately, without checking that the bytes have arrived. A single ~14-byte frame therefore commits as much memory as it cares to declare -- measured at 513 MiB against the Node.js server and 2 GiB against the D transport -- and in the Node.js case the connection is left open afterwards, so the frame can simply be sent again. This issue affects Apache Thrift before 0.25.0. Users are recommended to upgrade to version 0.25.0, which fixes the issue. | |||||
| CVE-2026-82458 | 2026-10-02 | N/A | N/A | ||
| Memory allocation with excessive size value, Allocation of resources without limits or throttling vulnerability in Apache Thrift Go, netstd, OCaml, Erlang, JavaME, Rust, C++, Java, Kotlin and D language bindings. This issue affects Apache Thrift: before 0.25.0. Users are recommended to upgrade to version 0.25.0, which fixes the issue. | |||||
| CVE-2026-94633 | 2026-10-02 | N/A | N/A | ||
| Memory allocation with excessive size value, Improper handling of length parameter inconsistency vulnerability in Apache Thrift Dart bindings. This issue affects Apache Thrift: before 0.25.0. Users are recommended to upgrade to version 0.25.0, which fixes the issue. | |||||
| CVE-2026-102820 | 2026-09-30 | N/A | 6.2 MEDIUM | ||
| pageant provides a [PageantStream] type that implements [AsyncRead] and [AsyncWrite] traits and can be used to talk to a running Pageant instance. Prior to pageant 0.2.3, the Windows pageant crate's pageant/src/wmmessage.rs MemoryMap::read function trusts a peer-controlled u32 response length supplied through the 8192-byte Pageant shared-memory mapping reached by AgentClient::connect_pageant. A local process that impersonates the Pageant window can make query_pageant_direct allocate up to approximately 4 GiB and copy beyond the mapped view, reliably crashing a russh client and conditionally exposing adjacent committed memory. This issue is fixed in pageant 0.2.3. | |||||
| CVE-2026-55149 | 2026-09-30 | N/A | 7.5 HIGH | ||
| Vouch Proxy is an SSO and OAuth/OIDC login solution for Nginx using the auth_request module. Prior to 0.48.0, Cookie in pkg/cookie/cookie.go parses the total part count from an attacker-controlled multipart cookie name and passes the value to make([]string, numParts) without checking that the value is positive or reasonably bounded. Requests to /validate and /_external-auth-:id reach JWTCacheHandler in pkg/jwtmanager/jwtcache.go, FindJWT in pkg/jwtmanager/jwtmanager.go, and the vulnerable cookie reassembly before JWT validation, so no account or valid session is required. A cookie name such as VouchCookie_1of10000000000 causes an attempted slice allocation of roughly 160 GB and a fatal Go runtime out-of-memory condition, allowing one request to crash the authentication proxy and repeated requests to sustain unavailability. This vulnerability is fixed in 0.48.0. | |||||
| CVE-2026-85715 | 2026-09-30 | N/A | 7.5 HIGH | ||
| ExifReader is a JavaScript Exif information parser. Prior to 4.41.1, ExifReader parses attacker-controlled HEIC or AVIF ISO-BMFF files in getItems() within src/image-header-iso-bmff-iloc.js and trusts iloc itemCount and extentCount values while allocating an extent object for every nested-loop iteration. When offsetSize, lengthSize, baseOffsetSize, and indexSize are zero, the extent fields consume no input bytes and the buffer offset does not advance, but the parser can still allocate up to itemCount multiplied by extentCount objects without an allocation budget. A small malicious iloc box can therefore cause hundreds of megabytes of heap growth or exhaust system memory, terminating a Node.js process and denying service to web, desktop, or mobile applications that parse untrusted images. The zero field widths are valid ISO-BMFF values indicating absent fields, so the vulnerable parser must bound work rather than relying on offset advancement. The issue is fixed in version 4.41.1. | |||||
| CVE-2026-53716 | 2026-09-30 | N/A | 6.5 MEDIUM | ||
| Envoy Gateway is an open source project for managing Envoy Proxy as a standalone or Kubernetes-based application gateway. Prior to 1.7.4 and 1.8.1, getFileFromGZ in internal/wasm/httpfetcher.go calls io.ReadAll on a gzip.Reader without limiting decompressed output when a tenant-controlled EnvoyExtensionPolicy.spec.wasm[].code.http.url points to a reachable compressed Wasm payload. The 256 MiB compressed-input cap does not constrain the expanded size, no operator Wasm URL allowlist exists, and the optional sha256 check occurs only after decompression, so a comparatively small gzip stream can force a multi-gigabyte allocation in the shared controller. The resulting out-of-memory termination restarts the controller, re-reconciles the persistent custom resource, and can create a persistent cross-tenant control-plane outage. This issue is fixed in versions 1.7.4 and 1.8.1. | |||||
| CVE-2026-53717 | 2026-09-30 | N/A | 6.5 MEDIUM | ||
| Envoy Gateway is an open source project for managing Envoy Proxy as a standalone or Kubernetes-based application gateway. Prior to 1.7.4 and 1.8.1, internal/wasm/imagefetcher.go follows tenant-controlled EnvoyExtensionPolicy spec.wasm[].code.image.url values to Docker or OCI Wasm layers, and extractWasmPluginBinary uses the untrusted tar-header h.Size value to allocate memory before validating the entry name or declared size. A small PAX or GNU tar header can therefore claim a multi-terabyte entry even though the surrounding LimitReader restricts only the bytes read from the stream, and no registry allowlist prevents a permitted tenant from selecting an attacker-controlled registry that the controller can reach. The allocation is attempted for every tar entry and can cause an unrecoverable Go runtime out-of-memory failure; because the custom resource persists, reconciliation repeatedly crash-loops the shared controller and causes a single-request, non-volumetric, cluster-wide control-plane denial of service. This issue is fixed in versions 1.7.4 and 1.8.1. | |||||
| CVE-2026-102809 | 2026-09-30 | N/A | 6.5 MEDIUM | ||
| PX4 Autopilot through 1.17.0 contains an uncontrolled stack allocation vulnerability in the file2 test command that fails to validate the write chunk size parameter. Attackers with shell access can supply an excessively large value to the -c option to trigger stack overflow and crash the flight controller. | |||||
| CVE-2026-102509 | 2026-09-30 | N/A | N/A | ||
| Memory Allocation with Excessive Size Value, Allocation of Resources Without Limits, and Uncontrolled Recursion in the Java implementation of Apache PLC4X (PLC4J) allow a malicious or impersonated device to exhaust the memory or stack of the client application, causing a denial of service. In the OPC UA driver these defects are reachable before authentication: the offending data is parsed while the secure channel and session are being established, before the server's identity has been bound to it. Configuring a trusted server therefore does not prevent exploitation by an attacker who can impersonate it. The individual defects are: - Length-prefixed byte strings are allocated at the size claimed on the wire before the length is checked against the data actually received (0.10.0 through 0.13.1). - Array fields in generated protocol parsers pre-allocate a list with the element count claimed on the wire, allowing a single count field to trigger a multi-gigabyte allocation. This parser is shared by all PLC4J drivers; the OPC UA driver is the verified pre-authentication path (0.10.0 through 0.13.1). - The OPC UA driver accumulates message chunks without enforcing the negotiated maximum chunk count and message size (0.12.0 through 0.13.1). - The OPC UA driver pre-allocates collections using element counts received from the server (0.10.0 through 0.13.1). - Recursive protocol types are parsed without a nesting-depth limit. The same defect in the Go implementation is covered by CVE-2026-102510 https://cveprocess.apache.org/cve5/CVE-2026-102510 . This issue affects Apache PLC4X: from 0.10.0 before 1.0.0. Users are recommended to upgrade to version 1.0.0, which fixes the issue. | |||||
| CVE-2026-102510 | 2026-09-30 | N/A | N/A | ||
| Integer Overflow, Improper Validation of Array Index, Uncontrolled Recursion and Memory Allocation with Excessive Size Value in the Go implementation of Apache PLC4X (PLC4Go) allow a malicious device, or an attacker able to inject network traffic, to crash or exhaust the memory of the client application, causing a denial of service. The individual defects are: - Generated parsers pre-allocate arrays with the element count claimed on the wire (0.13.0 through 0.13.1). - Transport read helpers allocate buffers of the size claimed on the wire without an upper bound. - ADS and KNXnet/IP response handling indexes into received data without checking its length, causing a panic. - ADS and EIP frame-length handling accepts, or arithmetically wraps to, a length of zero, breaking message framing. - Recursive protocol types are parsed without a nesting-depth limit. The same defect in the Java implementation is covered by CVE-2026-102509 https://cveprocess.apache.org/cve5/CVE-2026-102509 . Additionally, length and position arithmetic in generated serializers was performed in 16-bit integers. If an application forwards attacker-influenced payloads larger than 8 KB, the length field wraps, and the remainder of the payload may be interpreted by the receiving device (for example, an ADS PLC) as additional, independent protocol messages. This issue affects Apache PLC4X: from 0.11.0 before 1.0.0. PLC4Go is consumed as the Go module github.com/apache/plc4x/plc4go; versions refer to the corresponding Apache PLC4X releases. Users are recommended to upgrade to version 1.0.0, which fixes the issue. | |||||
| CVE-2026-62370 | 2026-09-29 | N/A | 6.5 MEDIUM | ||
| KubeEdge is an open source system for extending native containerized application orchestration capabilities to hosts at Edge. From 1.0.0 until 1.21.2, 1.22.2, and 1.23.1, Reader.Read in pkg/viaduct/pkg/packer trusts the 32-bit PackageHeader.PayloadLen received through the CloudHub viaduct message-processing path and allocates that amount of memory before validating an upper bound. An authenticated malicious or compromised edge peer can repeatedly send crafted headers with excessive declared lengths, causing memory exhaustion, CloudHub process termination or restart loops, and temporary disruption of cloud-edge communication. This issue does not provide unauthenticated access or direct code execution. This issue is fixed in versions 1.21.2, 1.22.2, and 1.23.1. | |||||
| CVE-2026-94626 | 1 Vllm | 1 Vllm | 2026-09-29 | N/A | 7.5 HIGH |
| vLLM through 0.29.0 fails to validate the tp_size parameter in kv_transfer_params on OpenAI-compatible completion endpoints, allowing attackers to allocate unbounded memory. Attackers can supply arbitrary tp_size values in prefill/decode disaggregated deployments to exhaust memory and trigger kernel OOM-kill of the decode worker process. | |||||
| CVE-2026-84857 | 2026-09-28 | 5.0 MEDIUM | 5.3 MEDIUM | ||
| A flaw has been found in sigoden aichat up to 0.30.4. This affects an unknown function of the file src/serve.rs of the component API Endpoint. This manipulation causes uncontrolled memory allocation. The attack can be initiated remotely. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | |||||
| CVE-2025-8696 | 2026-09-26 | N/A | 7.5 HIGH | ||
| If an unauthenticated user sends a large amount of data to the Stork UI, it may cause memory and disk use problems for the system running the Stork server. This issue affects Stork versions 1.0.0 through 2.3.0. | |||||
| CVE-2026-77619 | 2026-09-24 | N/A | N/A | ||
| Vector is a high-performance observability data pipeline. From 0.15.0 until 0.57.0, the logstash source reads a 32-bit compressed-frame length from the network and uses it to size an in-memory buffer without an upper bound. An unauthenticated remote peer that can reach the default 0.0.0.0:5044 listener can send a minimal frame declaring a multi-gigabyte payload, causing an excessive allocation that can abort Vector or invoke the host OOM killer. Because the allocation follows the declared length rather than bytes transmitted, the attacker has low resource cost, and process termination can halt log ingestion for every tenant on a shared pipeline. This issue is fixed in version 0.57.0. | |||||
| CVE-2026-77301 | 2026-09-24 | N/A | 7.5 HIGH | ||
| adm-zip is a JavaScript library for creating and extracting ZIP archives in Node.js. Prior to 0.6.1, getData() in zipEntry.js trusts an entry's central-directory uncompressed size and allocates output memory before validating that value against the actual compressed data and decompression result. A small crafted ZIP can declare a multi-gigabyte uncompressed size, causing Buffer.alloc and decompression handling to commit excessive resident memory before CRC validation reports an error. Applications that read entries from untrusted archives can therefore be terminated by the operating system or suffer service-wide memory exhaustion. This issue is fixed in version 0.6.1. | |||||
| CVE-2026-91752 | 2026-09-24 | N/A | 7.5 HIGH | ||
| GNU libextractor before 1.15 contains a stack-based buffer overflow vulnerability in the process_star_office function that sizes a variable-length stack array from attacker-controlled OLE2 stream data. Attackers can craft malicious StarOffice documents that allocate up to 4 MB on the stack, causing stack overflow and crashing any application extracting metadata from the document. | |||||
| CVE-2026-88382 | 2026-09-24 | N/A | 7.5 HIGH | ||
| hiredis commit 29ea279 (post-v1.5.0) contains an uncontrolled memory allocation vulnerability in its RESP aggregate parser. | |||||
| CVE-2026-83530 | 1 Google | 1 Common Expression Language | 2026-09-23 | N/A | 4.3 MEDIUM |
| A user could provide an expression whose string length is longer than the ParserExpressionSizeLimit() configured on the CEL environment, and a memory allocation would occur proportional to the size of the input before the limit would be checked / enforced. | |||||