Total
330 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-35549 | 1 Mariadb | 1 Mariadb | 2026-07-24 | N/A | 6.5 MEDIUM |
| An issue was discovered in MariaDB Server before 11.4.10, 11.5.x through 11.8.x before 11.8.6, and 12.x before 12.2.2. If the caching_sha2_password authentication plugin is installed, and some user accounts are configured to use it, a large packet can crash the server because sha256_crypt_r uses alloca. | |||||
| CVE-2026-47313 | 1 Samsung | 1 Escargot | 2026-07-24 | N/A | 5.5 MEDIUM |
| Memory allocation with excessive size value vulnerability in Samsung Open Source Escargot allows Excessive Allocation. This issue affects Escargot: 590345cc6258317c5da850d846ce6baaf2afc2d3. | |||||
| CVE-2018-25378 | 2026-07-24 | N/A | 6.2 MEDIUM | ||
| Notebook Pro 2.0 contains a denial of service vulnerability that allows local attackers to crash the application by supplying an excessively long string in the notebook name field. Attackers can create a malicious text file containing 500 or more characters, paste the content into the New Notebook Name field, and trigger an application crash when attempting to create and save the notebook. | |||||
| CVE-2026-5740 | 1 Mattermost | 1 Mattermost Server | 2026-07-23 | N/A | 7.5 HIGH |
| Mattermost versions 11.6.x <= 11.6.0, 11.5.x <= 11.5.3, 11.4.x <= 11.4.4, 10.11.x <= 10.11.14 fail to properly validate msgpack-encoded WebSocket frames before memory allocation which allows an unauthenticated remote attacker to crash the server process and cause a full service outage for all users via a crafted binary WebSocket message sent to the public WebSocket endpoint.. Mattermost Advisory ID: MMSA-2026-00647 | |||||
| CVE-2026-8485 | 1 Progress | 1 Moveit Automation | 2026-07-23 | N/A | 5.9 MEDIUM |
| Uncontrolled Memory Allocation vulnerability in Progress Software MOVEit Automation allows Excessive Allocation. This issue affects MOVEit Automation: before 2025.0.11, from 2025.1.0 before 2025.1.7. | |||||
| CVE-2026-9538 | 1 Archive\ | 1 \ | 2026-07-23 | N/A | 7.5 HIGH |
| Archive::Tar versions before 3.10 for Perl allow memory exhaustion via attacker controlled entry size field in tar header. _read_tar() reads each entry's payload with $handle->read($$data, $block), where $block is derived from the entry's 12-byte size field in the tar header with no upper bound on that value. A crafted header declaring a multi-gigabyte size causes Perl to allocate a scalar of that size. | |||||
| CVE-2026-47734 | 2026-07-23 | N/A | 5.7 MEDIUM | ||
| Dulwich is a pure-Python implementation of the Git file formats and protocols. Starting in version 0.1.0 and prior to version 1.2.5, a client with push access could push a tiny crafted thin pack (~174 bytes) whose delta header declares a huge dest_size. When dulwich ingested it via add_thin_pack / apply_delta, it would allocate hundreds of MB of memory based on that attacker-controlled size, with no relationship to the actual bytes received. Operators running a Dulwich-based Git server that exposes git-receive-pack (i.e. accepts pushes) - for example via dulwich.server functionality, the HTTP smart server, or anything built on ReceivePackHandler - are impacted. The issue is patched in 1.2.5. add_thin_pack now accepts a max_input_size keyword (bytes; 0/None = unlimited, matching git's semantics), and ReceivePackHandler reads receive.maxInputSize from the repository config and passes it through. Wire reads are counted and a PackInputTooLarge exception is raised once the cap is exceeded - equivalent to git index-pack --max-input-size. Users should upgrade to Dulwich 1.2.5 or later and set receive.maxInputSize in their server's repository config to a sane bound for their environment. On unpatched versions, receive.maxInputSize has no effect, so it cannot be used as a workaround. Until upgrading, operators should restrict dulwich-receive-pack (push) access to trusted, authenticated clients only, or disable it entirely on servers that only need to serve fetches and/or run the server under an OS-level memory limit (e.g. ulimit, cgroups/MemoryMax, or a container memory limit) so a malicious push is killed rather than taking down the host. | |||||
| CVE-2026-47319 | 2026-07-22 | N/A | 6.1 MEDIUM | ||
| Memory allocation with excessive size value vulnerability in Samsung Open Source rlottie allows Excessive Allocation. This issue affects rlottie: before 0b4e308fa88c72cbb60cc8a2c1d2c2ad89b101dd. | |||||
| CVE-2026-41178 | 1 Opentelemetry | 1 Opentelemetry | 2026-07-22 | N/A | 5.3 MEDIUM |
| OpenTelemetry-Go is the Go implementation of OpenTelemetry. Versions 1.41.0 and 1.43.0 removed raw-length rejection and it causes `Parse` to process arbitrarily large/invalid baggage headers and log errors, enabling DoS via oversized inputs. Versions 1.42.0 and 1.44.0 fix the issue. | |||||
| CVE-2026-40378 | 1 Microsoft | 13 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 10 more | 2026-07-22 | N/A | 7.5 HIGH |
| Memory allocation with excessive size value in Windows Local Security Authority Subsystem Service (LSASS) allows an unauthorized attacker to deny service over a network. | |||||
| CVE-2026-14684 | 2026-07-16 | 1.7 LOW | 3.3 LOW | ||
| A flaw has been found in HdrHistogram up to 2.2.2. This affects the function org.HdrHistogram.AbstractHistogram.decodeFromByteBuffer of the file src/main/java/org/HdrHistogram/AbstractHistogram.java. This manipulation of the argument numberOfSignificantValueDigits causes uncontrolled memory allocation. The attack can only be executed locally. The exploit has been published and may be used. The actual existence of this vulnerability is currently in question. This issue is disputed due to the potential lack of crossing of security boundaries and the pre-requisites for a successful attack. | |||||
| CVE-2026-14683 | 2026-07-16 | 1.7 LOW | 3.3 LOW | ||
| A vulnerability was detected in HdrHistogram up to 2.2.2. Affected by this issue is the function org.HdrHistogram.AbstractHistogram.decodeFromCompressedByteBuffer of the file src/main/java/org/HdrHistogram/AbstractHistogram.java. The manipulation of the argument lengthOfCompressedContents results in uncontrolled memory allocation. The attack needs to be approached locally. The exploit is now public and may be used. It is still unclear if this vulnerability genuinely exists. This issue is disputed due to the potential lack of crossing of security boundaries and the pre-requisites for a successful attack. | |||||
| CVE-2026-58559 | 2026-07-15 | N/A | 6.5 MEDIUM | ||
| DoS vulnerability in the vibration service. Impact: Successful exploitation of this vulnerability may affect availability. | |||||
| CVE-2026-25985 | 1 Imagemagick | 1 Imagemagick | 2026-07-15 | N/A | 7.5 HIGH |
| ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, a crafted SVG file containing an malicious element causes ImageMagick to attempt to allocate ~674 GB of memory, leading to an out-of-memory abort. Versions 7.1.2-15 and 6.9.13-40 contain a patch. | |||||
| CVE-2026-32836 | 1 Mackron | 1 Dr Libs | 2026-07-14 | N/A | 6.2 MEDIUM |
| dr_libs dr_flac.h version 0.13.3 and earlier (fixed in commits fefced4, 4f5a4cd, and 663239a) contain an uncontrolled memory allocation vulnerability in drflac__read_and_decode_metadata() that allows attackers to trigger excessive memory allocation by supplying crafted PICTURE metadata blocks. Attackers can exploit attacker-controlled mimeLength and descriptionLength fields to cause denial of service through memory exhaustion when processing FLAC streams with metadata callbacks. | |||||
| CVE-2026-22188 | 1 Cmu | 1 Panda3d | 2026-07-14 | N/A | 5.5 MEDIUM |
| The deploy-stub component in Panda3D versions up to and including 1.10.16 contains a denial of service vulnerability due to unbounded stack allocation. The deploy-stub executable allocates argv_copy and argv_copy2 using alloca() based directly on the attacker-controlled argc value without validation. Supplying a large number of command-line arguments can exhaust stack space and propagate uninitialized stack memory into Python interpreter initialization, resulting in a reliable crash and undefined behavior. | |||||
| CVE-2026-55213 | 2026-07-13 | N/A | 7.5 HIGH | ||
| h2o is an HTTP server with support for HTTP/1.x, HTTP/2 and HTTP/3. Prior to commit edd7a120bfc4af11ac0cbebce2a43cc1f93f9af1, when h2o processes a QPACK instruction sent from the peer over HTTP/3, lib/http3/qpack.c might allocate an on-stack buffer as large as approximately 800 KB by calling alloca, which exceeds the default pthread stack size used by musl libc and causes the h2o server to crash with a segmentation fault while touching the guard page. This issue is fixed in commit edd7a120bfc4af11ac0cbebce2a43cc1f93f9af1. | |||||
| CVE-2026-55079 | 1 Coder | 1 Coder | 2026-07-08 | N/A | 4.9 MEDIUM |
| Coder allows organizations to provision remote development environments via Terraform. Starting in version 2.24.0 and prior to versions 2.29.7, 2.32.7, 2.33.8, and 2.34.2, `NewDataBuilder` in `provisionersdk/proto/dataupload.go` allocated a byte slice using the client-supplied `FileSize` from a `DataUpload` message without an upper-bound check. Although the DRPC wire limit is 4 MiB, the `FileSize` value itself was unconstrained. The fix in versions 2.29.7, 2.32.7, 2.33.8, and 2.34.2 validates `FileSize` against an upper bound (`MaxFileSize = 100 MiB`) before allocation. As a workaround, restrict access to the provisioner daemon serve endpoint to trusted provisioner daemon service accounts. | |||||
| CVE-2026-53916 | 1 Apache | 1 Activemq | 2026-07-02 | N/A | 7.5 HIGH |
| Memory Allocation with Excessive Size Value vulnerability in Apache ActiveMQ, Apache ActiveMQ All, Apache ActiveMQ Stomp. An unauthenticated client that opens a STOMP NIO connection can send header bytes that never terminate which makes the broker buffer them without limit, exhausting the JVM heap. This issue affects Apache ActiveMQ: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ All: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ Stomp: before 5.19.8, from 6.0.0 before 6.2.7. Users are recommended to upgrade to version 6.2.7 or 5.19.8, which fixes the issue. | |||||
| CVE-2026-53917 | 1 Apache | 2 Activemq, Activemq Broker | 2026-07-02 | N/A | 7.5 HIGH |
| Memory Allocation with Excessive Size Value vulnerability in Apache ActiveMQ, Apache ActiveMQ All, Apache ActiveMQ Client, Apache ActiveMQ Broker. An authenticated user can cause a broker DoS by sending a crafted OpenWire Message with a large encoded size value for the map. OpenWire message property maps are unmarshaled without size validation which can trigger OOM and crash the broker. This issue affects Apache ActiveMQ: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ All: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ Client: before 5.19.8, from 6.0.0 before 6.2.7; Apache ActiveMQ Broker: before 5.19.8, from 6.0.0 before 6.2.7. Users are recommended to upgrade to version 6.2.7 or 5.19.8, which fixes the issue. | |||||