Total
330 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-77410 | 2026-09-23 | N/A | N/A | ||
| RabbitMQ amqp091-go is a Go AMQP 0.9.1 client. Prior to 1.13.0, Channel.recvContent in channel.go preallocates the message body slice with the uint64 ch.header.Size value supplied by an AMQP content header without capping the allocation to the negotiated Connection.Config.FrameSize value. A malicious or compromised broker can send an extreme declared body size and cause the Go runtime to attempt a correspondingly large allocation before body data is received. The allocation can exhaust memory and terminate the client process. This issue is fixed in version 1.13.0. | |||||
| CVE-2026-93307 | 2026-09-23 | 4.0 MEDIUM | 4.3 MEDIUM | ||
| A vulnerability has been found in O-RAN-SC SMO OAM 2025-06-10. Affected is an unknown function of the component VES Collector. Such manipulation of the argument additionalFields.padding leads to uncontrolled memory allocation. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The project was informed of the problem early through a bug report but has not responded yet. | |||||
| CVE-2026-58268 | 2026-09-23 | N/A | 7.5 HIGH | ||
| SIPGO is a library for writing SIP services in the GO language. Prior to 1.4.1, ParserStream.parseSingle in sip/parser_stream.go allocates a SIP body buffer from the client-controlled Content-Length header before ParseMaxMessageLength is enforced. An unauthenticated peer can send a stream-transport message over TCP, TLS, WS, or WSS with an oversized declared length, causing excessive memory allocation and denial of service before the body is read. This issue is fixed in version 1.4.1. | |||||
| CVE-2026-77322 | 2026-09-23 | N/A | 7.5 HIGH | ||
| SIPGO is a library for writing SIP services in the GO language. Prior to 1.4.3, WSConnection.Read in sip/transport_ws.go creates a wsutil.Reader without setting MaxFrameSize, allowing NextFrame to accept a client-controlled header.Length before ParseMaxMessageLength is applied. An unauthenticated WS or WSS peer can send a frame header declaring an extremely large payload, causing an oversized allocation or a makeslice length panic before the payload is read and crashing or exhausting memory in the server process. This issue is fixed in version 1.4.3. | |||||
| CVE-2026-59991 | 2026-09-23 | N/A | 7.5 HIGH | ||
| psd-tools is a Python package for working with Adobe Photoshop PSD files. Prior to 1.17.4, PSDImage.composite() and PSDImage.numpy() allocated output buffers from attacker-controlled PSD header geometry, including width, height, channels, depth, and per-layer rectangles, before validating those values against the available file data. A tiny crafted PSD could therefore cause multi-gigabyte memory allocation, and PSDImage.composite() could return a black image with only a warning instead of raising an exception. Services that composite untrusted PSD files could be terminated by out-of-memory handling. This issue is fixed in version 1.17.4. | |||||
| CVE-2026-81692 | 2026-09-23 | N/A | 7.5 HIGH | ||
| openssl_encrypt (pip: openssl-encrypt) versions 1.4.8 and earlier fail to validate the 36-bit STREAMINFO total_samples field of FLAC files before using it to size an allocation (np.random.randint(size=(total_samples, channels))). A ~50-byte crafted FLAC file declaring ~100 million samples causes a multi-gigabyte memory allocation, leading to out-of-memory denial of service during 'decrypt --stego-extract'. The issue is fixed in 1.4.9; both the 1.4.x and 1.5.x lines are affected. | |||||
| CVE-2026-47321 | 2026-09-21 | N/A | 7.5 HIGH | ||
| The CompressionFilter class uses ZLib to deflate and inflate data sent and received. When we inflate incoming data, the filter does not control the resulting size, and create a buffer no matter what. Some compressed data may have a compression ration greater than 1 thousand, leading to an exhaustion of the application memory, as we don't control the deflated size. The fix adds such a control by allowing the application developer to provide a fixed size limit, which when reached throws an exception. It also allows the user to provide a compression ratio that should not be exceeded, protected the application from small inflated files that inflate in gigantic files, but with a grace limit for the resulting size (1Mb) to avoid false positive (like a very small file inflating with a high ratio, but resulting with a acceptable size, like a few thousands bytes) For application using this feature, it is highly recommended to create the CompressionFilter and to pass the maximum limit as a forth constructor parameter, maxDecompressedSize: public CompressionFilter(final boolean compressInbound, final boolean compressOutbound, final int compressionLevel, final int maxDecompressedSize)Optionally one can also provide a maxDecompressRatio fifth parameter, and a decompressRatioMinSize sixth parameter to allow small inflated files with a high compression ratio to still be accepted. Here are the additional constructor: public CompressionFilter(final boolean compressInbound, final boolean compressOutbound, final int compressionLevel, final int maxDecompressedSize, final long maxDecompressRatio, final long decompressRatioMinSize) Also note that a fluent API has been added to spare the users the pain to call a constructor with that many parameters: CompressionFilter compressionFilter = new CompressionFilter() .setCompressionLevel(Zlib.COMPRESSION_MAX) .setMaxDecompressedSize(1_000_000) .setMaxDecompressRatio(100). .setDecompressRatioMinSize(100_000); Applications using Apache MINA are advised to upgrade and configure their CompressionFilter instance. | |||||
| CVE-2026-93019 | 2026-09-18 | N/A | 9.1 CRITICAL | ||
| Imager versions before 1.036 for Perl exit the process reading a TGA with a colour map length of 32768 or more in tga_palette_read. The reader unpacks the two-byte colour map length into a signed short, so a length of 32768 or more becomes negative. tga_palette_read() casts that value to size_t and asks mymalloc() for a size near SIZE_MAX. The allocation fails and Imager's allocator calls exit(3). Reading an attacker-supplied file through Imager->read() triggers an uncatchable exit. | |||||
| CVE-2026-20295 | 2026-09-18 | N/A | 8.6 HIGH | ||
| A vulnerability in the sftunnel inter-device communication protocol of Cisco Secure FMC Software and Cisco Secure FTD Software could allow an unauthenticated, remote attacker to exhaust the available memory of an affected device. This vulnerability is due to improper management of memory resources during sftunnel TLS connection setup. An attacker could exploit this vulnerability by sending crafted sftunnel TLS frames to an affected device during the connection setup. A successful exploit could allow the attacker to exhaust the available memory on the affected device, which could result in a DoS condition. | |||||
| CVE-2024-20260 | 2026-09-16 | N/A | 8.6 HIGH | ||
| Update for September 16, 2026: The original 1.0 version of this advisory was specific to the Cisco Adaptive Security Virtual Appliance (ASAv) and Cisco Secure Firewall Threat Defense Virtual (FTDv) models. However, it was later found that this vulnerability affects all Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Cisco Secure Firewall Threat Defense (FTD) Software platforms. A vulnerability in the VPN and management web servers of the Cisco Secure Firewall ASA Software and Cisco Secure FTD Software platforms could allow an unauthenticated, remote attacker to cause an affected device to run out of system memory or buffer blocks, which in turn could cause SSL VPN connection processing to slow down and eventually cease altogether. This vulnerability is due to a lack of proper memory management for new incoming SSL/TLS connections. An attacker could exploit this vulnerability by sending a large number of new incoming SSL/TLS connections to the targeted device. A successful exploit could allow the attacker to deplete system memory or buffers, resulting in a denial of service (DoS) condition. The memory or buffers could be reclaimed slowly if the attack traffic is stopped, but a manual reload may be required to restore operations quickly. | |||||
| CVE-2026-67211 | 1 Apache | 1 Opennlp | 2026-09-16 | N/A | 7.5 HIGH |
| OOM Denial of Service via Unbounded Map Pre-Sizing in Apache OpenNLP SymSpellModelSerializer Versions Affected: - 3.0.0-M4 - 3.0.0-M5 (The opennlp-spellcheck extension was introduced in 3.0.0-M4. Releases 1.x and 2.x do not contain the affected code.) Description: The SymSpellModelSerializer.create() method reads two 32-bit signed integer count fields (unigramCount and bigramCount) from a binary SymSpell model stream and passes each value directly to LinkedHashMap.newLinkedHashMap() after validating only that it is non-negative. No upper bound is applied, so the count is fully attacker-controlled when the model file originates from an untrusted source. A crafted .bin model file in which either count field is set to Integer.MAX_VALUE (or any value large enough to exhaust the available heap) causes the map to be pre-sized to a capacity of 2^30 entries. The oversized backing array is allocated on the first put() into that map, requesting 4–8 GB depending on whether compressed oops are in effect, and the load fails with an OutOfMemoryError. Because the count fields sit immediately after a fixed-size header (magic, format version, three UTF strings, the configuration fields, and the edit-distance identifier) the attacker pays no meaningful size cost to weaponize a payload: a file of well under 100 bytes plus a single real entry is sufficient to crash a JVM that loads it. Any code path that deserializes a SymSpell model is affected, including SymSpellModels.deserialize(InputStream), SymSpellModels.fromBytes(byte[]), classpath model loading via SymSpellModelResolver.resolveByLanguage(String), the CorrectTextTool command-line tool, and model-archive loading through the registered ArtifactSerializer. The opennlp-spellcheck extension ships in the official OpenNLP binary distribution. The practical impact is denial of service against processes that load SymSpell model files from untrusted or semi-trusted origins. Mitigation: - 3.x users should upgrade to 3.0.0-M6. Note: The fix applies an upper bound to both count fields, checked before the map is pre-sized; counts that are negative or exceed the bound cause an IOException to be thrown and the read to fail fast with no large allocation. The bound is the existing AbstractModelReader.MAX_ENTRIES limit introduced earlie, which the current change promotes to public visibility so that serializers implementing their own binary format can share it. The default bound is 10,000,000, which is well above the entry counts of legitimate SymSpell dictionaries but far below any value that would threaten heap exhaustion. Deployments that legitimately need to load larger dictionaries can raise the limit at JVM startup by setting the OPENNLP_MAX_ENTRIES system property to the desired positive integer (e.g. -DOPENNLP_MAX_ENTRIES=50000000); invalid or non-positive values fall back to the default. Note that this property is shared with the model-reader limit and raising it relaxes both. Users who cannot upgrade immediately should treat all SymSpell .bin model files as untrusted input unless their provenance is verified, and should avoid loading models supplied by end users or fetched from third-party repositories without integrity checks. | |||||
| CVE-2026-82435 | 2026-09-14 | N/A | 9.8 CRITICAL | ||
| Description The worker's Netty message decoder is installed ahead of the SASL authentication handlers in the pipeline and acts on frames before any authentication has taken place. It allocated buffers sized from a length field carried in the frame, so a single frame from an unauthenticated peer able to reach a worker slot port could drive a large allocation. `storm.messaging.netty.authentication` defaults to false, and the decoder runs before the handler that enforces it in any case, so no credentials are required. The attacker needs only TCP reachability to a worker port. The effect of a single frame at the default 768 MB worker heap has not been measured to distinguish sustained worker loss from transient garbage-collection pressure. The severity assigned to this advisory reflects the more conservative reading; consumers who require a precise figure should test against their own worker heap configuration. Mitigation Upgrade to 3.1.0, where frames are decoded only after the handshake completes. Users who cannot upgrade immediately should ensure that worker slot ports are reachable only from within the cluster, as the security model already recommends, and should enable `storm.messaging.netty.authentication` where the deployment permits it. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. | |||||
| CVE-2026-86776 | 2026-09-10 | N/A | 3.3 LOW | ||
| KeePass versions 2.35 through 2.61.1 fail to validate KDBX header field sizes before memory allocation in the ReadHeaderField function. Attackers can craft a malicious KDBX file declaring excessive header field lengths to trigger allocation of gigabytes of memory, causing the application to consume resources and terminate. | |||||
| CVE-2026-88045 | 2026-09-10 | N/A | 7.5 HIGH | ||
| rclone is a command-line program to sync files and directories to and from different cloud storage providers. From 1.75.0 until 1.75.1, the serve S3 streamed multipart path in cmd/serve/s3/multipart.go passes attacker-controlled contentLength to multipart.NewRW().Reserve before reading request-body bytes. waitForTurn admits the current part and one oversized part when the buffer is empty despite --multipart-streaming-buffer-limit, and lib/pool allocates 1 MiB pages according to Content-Length or X-Amz-Decoded-Content-Length. A network client can retain or multiply these reservations without sending the declared body, exhausting process or host memory or permanently blocking request handlers. Anonymous S3 deployments require no credentials, while deployments using auth_key require an accepted S3 key. This issue is fixed in version 1.75.1. | |||||
| CVE-2026-42154 | 1 Prometheus | 1 Prometheus | 2026-09-10 | N/A | 7.5 HIGH |
| Prometheus is an open-source monitoring system and time series database. Prior to versions 3.5.3 and 3.11.3, the remote read endpoint (/api/v1/read) does not validate the declared decoded length in a snappy-compressed request body before allocating memory. An unauthenticated attacker can send a small payload that causes a huge heap allocation per request. Under concurrent load this can exhaust available memory and crash the Prometheus process. This issue has been patched in versions 3.5.3 and 3.11.3. | |||||
| CVE-2026-71314 | 2026-09-08 | N/A | 7.5 HIGH | ||
| Nuxt is an open-source web development framework for Vue.js. From 3.1.0 until 3.21.10 and 4.5.1, an unauthenticated attacker can use a server island v-for prop, including vforToArray and , to trigger unbounded SSR memory allocation until MAX_VFOR_LENGTH = 100000 and crash the Nuxt process. This issue is fixed in 3.21.10 and 4.5.1. | |||||
| CVE-2026-85201 | 2026-09-08 | N/A | N/A | ||
| In Eclipse Ankaios versions 0.1.0 through 1.0.1, the agent does not limit the length declared by a workload in a length-delimited protobuf message received through the Control Interface FIFO. A workload granted Control Interface access can specify an excessive message length, causing an unbounded memory allocation that may abort the Ankaios agent process. This results in loss of orchestration services for workloads managed by the affected agent. | |||||
| CVE-2026-19204 | 2026-09-08 | N/A | N/A | ||
| A client may send a WebSocket frame with an unknown opcode and a very large declared payload length, causing Jetty to attempt a large memory allocation and potentially exhaust the JVM heap. This occurs when auto-fragmentation is enabled, as unknown opcodes bypass the normal maximum frame size handling and payload allocation occurs before the opcode is validated. | |||||
| CVE-2026-72656 | 1 Elastic | 1 Elasticsearch | 2026-09-04 | N/A | 6.5 MEDIUM |
| Memory Allocation with Excessive Size Value (CWE-789) in the ES|QL query processing of Elasticsearch can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user able to submit ES|QL queries could send a specially crafted query whose evaluation allocates an unbounded amount of heap memory, exhausting the available heap on the receiving node and causing the node to become unavailable. | |||||
| CVE-2026-26931 | 1 Elastic | 1 Metricbeat | 2026-09-04 | N/A | 5.7 MEDIUM |
| Memory Allocation with Excessive Size Value (CWE-789) in the Prometheus remote_write HTTP handler in Metricbeat can lead Denial of Service via Excessive Allocation (CAPEC-130). | |||||