CVE-2026-75808
Allocation of Resources Without Limits or Throttling in ASUS Armoury Crate allows a local user to cause a denial-of-service condition throug
CVSS
—
No CVSS
EPSS
0.1%
p4
KEV
—
Exploit Today
1
0-100
Published: Sep 8, 2026 · Last modified: Sep 28, 2026 · CWE-770
0.1%EPSS · 30 days0.1%
2026-09-302026-10-28
Allocation of Resources Without Limits or Throttling in ASUS Armoury Crate allows a local user to cause a denial-of-service condition through system memory exhaustion by bypassing driver authentication and allocating an unrestricted amount of memory.Refer to the ' Security Update for Armoury Crate App ' section on the ASUS Security Advisory for more information.
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-1186897.5 HIG—
——0OvenMediaEngine 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.15hCVE-2026-118260——
——0Echo 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.18hCVE-2026-117501——
——0HTTP::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.19hCVE-2026-116273——
——0MIME::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.19hCVE-2026-116134——
——0HTTP::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.19hCVE-2026-116131——
——0HTTP::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.19h