| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| containerd is an open-source container runtime. Prior to 1.7.35, 2.0.12, 2.2.8, and 2.3.5, containerd's layer unpack handler repeatedly traverses directories for certain opaque whiteout configurations. A malicious image layer can trigger repeated directory traversals while opaque whiteouts are processed. Pulling or importing the image can consume CPU, delay container startup, and reduce image-pull concurrency for unrelated deployments. This issue is fixed in versions 1.7.35, 2.0.12, 2.2.8, and 2.3.5. |
| SGLang through 0.5.21 contains a decompression amplification vulnerability in load_audio that allows remote attackers to exhaust memory by submitting highly compressed audio decoded without duration or sample limits. Attackers can supply small FLAC-encoded silence files through audio_url or audio_data inputs that expand into massive PCM buffers, exhausting worker memory and CPU for denial of service. |
| A flaw was found in openstack-network-exporter. The HTTP server within the component is configured without essential timeout settings, such as ReadHeaderTimeout. This vulnerability allows an unauthenticated, remote attacker to initiate multiple slow HTTP header connections. By trickling header bytes, the attacker can exhaust server resources, specifically file descriptors, leading to a Denial of Service (DoS) that prevents legitimate Prometheus metric scraping and alerting. |
| Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in hexpm hex_core allows an untrusted repository mirror, or a server answering hex_core's API requests, to exhaust the memory of the Erlang VM running hex_core. The same code is vendored in Hex (mix_hex_repo, mix_hex_api) and rebar3 (r3_hex_repo, r3_hex_api).
hex_repo:get_names/1, hex_repo:get_versions/1, hex_repo:get_package/2 and hex_repo:get_policy/2 decompress the registry response with zlib:gunzip/1 and decode the signed envelope before verifying its signature. A mirror doesn't have the repository's private key, but it chooses the compressed bytes, so a small response decompresses into an envelope of any size before the signature check rejects it.
hex_api decodes responses with the application/vnd.hex+erlang content type through hex_safe_binary_to_term:safe_binary_to_term/1, which calls binary_to_term(Binary, [safe]). The safe option prevents atom creation, but it accepts compressed terms and doesn't limit the size of the decoded term, and the check that rejects functions and ports runs after the term has been built. The fix for CVE-2026-21619 added the safe option and that check without bounding the decoded size.
This issue affects rebar3: from 3.9.1 before 3.27.3; hex: from 2.1.0 before 2.5.2; hex_core: from 0.1.0 before 0.20.0. |
| SGLang through 0.5.21 contains a denial of service vulnerability that disables Pillow decompression bomb protection process-wide by setting Image.MAX_IMAGE_PIXELS to None in NanoNemotronVLImageProcessor. Remote attackers can submit small, highly compressed images with huge dimensions to the generic image loader, exhausting worker memory during decoding. |
| Gitoxide gix-mailmap before 0.35.0 contains a denial of service vulnerability that allows attackers to exhaust CPU through quadratic-time parsing in Snapshot::from_bytes. Attackers can commit a crafted .mailmap with descending-ordered entries forcing repeated front inserts, blocking workers running log, blame, or shortlog for minutes. |
| Grav before 2.1.7 contains a denial of service vulnerability that allows authenticated media authors to exhaust memory by uploading compressed oversized raster images. Attackers can reference a Twig or Markdown transform so GD or Imagick decodes the full source without dimension checks, letting anonymous requests repeatedly cause page unavailability. |
| Open WebUI from 0.9.0 before 0.11.4 contains a denial of service vulnerability that allows authenticated users with automations permission to stall the instance by submitting unsatisfiable recurrence rules. Attackers can repeatedly send rules like February 30th to the automations create or update endpoints, blocking the shared event loop for seconds per request. |
| Open WebUI 0.11.0 before 0.11.4 compiles user-chosen grep patterns for its knowledge and chat file search tools with a regex engine that expands nested counted repetition unbounded at compile time and caches the result. Authenticated users can have the model call grep_knowledge_files with short nested-repetition patterns, blocking the event loop and exhausting worker memory. |
| Open WebUI 0.11.0 before 0.11.4 contains a denial of service vulnerability in the automation recurrence-rule validator, whose sub-daily frequency guard parses rule text more strictly than the calendar library that executes it. Users permitted to create automations can submit whitespace-folded rules (or, in 0.11.0, lowercase frequencies or omitted RRULE prefixes) that expand per-second synchronously, blocking the shared event loop for minutes per request and on every scheduler poll. |
| Open WebUI from 0.6.42 before 0.11.4 contains an uncontrolled resource consumption vulnerability that allows authenticated users to exhaust server memory by supplying compressed remote image URLs in chat messages. Attackers can point the image field at a host returning gzip-encoded responses, which get_image_base64_from_url decompresses unbounded, causing denial of service for all users. |
| ImageMagick before 6.9.13-57 and 7.x before 7.1.2-32 contains a memory leak in the wavelet-denoise operation, which fails to release allocated memory when a required resource cannot be acquired. Attackers can repeatedly trigger wavelet-denoise processing under resource-constrained conditions to leak memory and degrade service availability. |
| ImageMagick before 7.1.2-32 contains a policy bypass vulnerability in the -script operation due to missing checks on file descriptor handling. Attackers can use the -script operation to close file descriptors not opened by the current operation, circumventing configured security policies. |
| ImageMagick before 7.1.2-32 contains a memory leak vulnerability in the -process option that allows attackers to cause unreleased memory allocations by supplying certain arguments. Attackers can repeatedly invoke the -process option with crafted arguments to gradually exhaust memory and degrade service availability. |
| ImageMagick before 6.9.13-57 and 7.x before 7.1.2-32 contains a memory leak in the YUV encoder, which fails to release allocated memory when a specific operation fails. Attackers can supply crafted input that triggers the failing encoder operation, leaking memory and potentially exhausting resources to cause a denial of service. |
| ImageMagick before 6.9.13-57 and 7.x before 7.1.2-32 contains a memory leak in the SVG encoder (WriteSVGImage) that fails to release allocated memory when handling crafted images. Attackers can supply crafted image files that are processed by the SVG encoder to leak memory and cause a denial of service through resource consumption. |
| ImageMagick before 6.9.13-57 and 7.x before 7.1.2-32 contains a memory leak in the GIF encoder because allocated memory is not released when color quantization fails during encoding. Attackers can supply images whose GIF conversion causes quantization to fail, leaking memory with each attempt and degrading availability. |
| ImageMagick before 6.9.13-57 and 7.x before 7.1.2-32 contains a memory leak in the PNG encoder, which does not release allocated memory when libpng initialization fails. Attackers who can repeatedly trigger PNG encoding operations in which libpng initialization fails can exhaust memory and cause a denial of service. |
| Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in hexpm hex allows an untrusted package mirror to exhaust the memory or disk space of the machine running mix deps.get, mix deps.update, mix hex.package fetch or mix hex.docs fetch.
Hex treats a mirror configured with HEX_MIRROR_URL, HEX_MIRROR or mirror_url as untrusted: it doesn't send credentials to it, and it checks registry signatures and package checksums that the mirror can't forge. Several response paths consume memory or disk in proportion to what the mirror sends before any of those checks run.
Hex.HTTP.request/5 reads the whole response body into memory and decompresses it with :zlib.gunzip/1 whenever the response's Content-Encoding contains gzip, with no limit on the compressed or decompressed size. Hex doesn't ask for compressed responses, so the server decides whether this step runs. It applies to registry, package, docs and API responses.
Package tarballs have no download size limit. Hex 2.5.1 holds the whole tarball in memory and writes it to the cache, and the development branch streams it to a temporary file; the 16 MiB tarball limit is checked only when the file is unpacked. The tarball is then unpacked, into deps/<app> in 2.5.1 and into a staging directory on the development branch, before its checksums are compared with the registry.
mix hex.docs fetch, and mix hex.docs offline when docs are missing, write the docs tarball to disk and extract it with :mix_hex_erl_tar.extract/2 without the 16 MiB compressed and 128 MiB decompressed limits that mix_hex_tarball:unpack_docs/3 applies. The signed registry doesn't cover docs tarballs, so nothing checks them.
Registry responses are also decompressed before their signature is checked, in hex_core code that Hex vendors; that part is tracked in https://github.com/hexpm/hex_core/security/advisories/GHSA-7c4r-cgf9-9jmq.
This issue affects hex: from 0.11.2 before 2.5.2. |
| Gumlet php-image-resize before 3.0.1 contains a denial of service vulnerability because the ImageResize constructor in lib/ImageResize.php passes images to GD imagecreatefrom* functions without pixel limits. Remote attackers can upload small, highly compressed images that decode to large bitmaps, exhausting PHP memory and terminating the worker process. |
