CVE Watch13 nov 2026

CVE-2026-121808

Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in elixir-grpc grpc_core and grpc allows unauthenticated atta

CVSS

—

Sin CVSS

EPSS

—

KEV

—

Exploit Today

—

0-100

Publicado: 13 nov 2026 · Última mod.: 13 nov 2026 · CWE-409

EPSS · 30d

Sin historial EPSS suficiente todavía.

Descripción técnica

Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in elixir-grpc grpc_core and grpc allows unauthenticated attackers to exhaust server memory via a compressed Erlang external term in a gRPC message body. GRPC.Codec.Erlpack.decode/2 (grpc_core/lib/grpc/codec/erlpack.ex, and lib/grpc/codec/erlpack.ex before the package split) passes the message body to :erlang.binary_to_term/2. That function inflates a compressed term in full before it returns. The codec sets no limit on the decoded size, and its type checks run only on the decoded term. The server's max_body_size limit counts the compressed bytes of the request. A request with Content-Type: application/grpc+erlpack can therefore make the server allocate a term much larger than the request body. This issue affects grpc: from 0.4.0 before 1.0.0; grpc_core: from 1.0.0 before 1.1.0.

Referencias oficiales

CVEs relacionados

CVECVSSEPSSKEVRExplotTítuloVis.

CVE-2026-777066.5 MED

—

———Improper handling of highly compressed data (data amplification) vulnerability in Fileorbis Bilişim Hizmetleri Ticaret Anonim Şirketi FileOrbis NextGen FileServer allows Sustained Client Engagement. This issue affects FileOrbis NextGen FileServer: before 12.7.10h CVE-2026-1282427.5 ALT

—

——0actix-http before 3.20.1 and actix-web before 4.18.2 contain an unbounded decompression vulnerability in encoding::Decoder that lets remote attackers exhaust memory and CPU via compressed bodies. Attackers can send small highly compressed gzip, deflate, Brotli or zstd request bodies to Json, Form, Bytes or String extractors, or serve them to awc clients, causing denial of service.2h CVE-2026-1264234.3 MED

—

——0OpenEMR before 8.5.0 contains a denial of service vulnerability in four ZIP upload paths that read uncompressed entries into memory without size or ratio checks. Authenticated billing or Carecoordination users can upload highly compressed ZIP archives to exhaust PHP memory and worker pools, making OpenEMR unavailable.9h CVE-2026-121691—

3.2%

——1Improper Handling of Highly Compressed Data (CWE-409) in the ZIP loader of whatstk from 0.7.0 before 0.9.0 allows a party that supplies a chat export to exhaust the memory and the disk of the process that parses it, because _str_from_file() (whatstk/whatsapp/parser.py) calls zip_ref.extractall() with no bound on the size of the members and no check of the compression ratio, then reads the extracted file in full with f.read(). The only guard on the archive counts the extracted files and raises when there is not exactly one, but it runs after extractall() has already written them, so it does not prevent the cost. _clean_text() then passes the whole text through unicodedata.normalize("NFKD", text), which holds a second copy, and the parse builds a list of regular expression matches and a DataFrame over it, so peak memory is a multiple of the decompressed text rather than of the archive. A ZIP is a documented input of WhatsAppChat.from_source() and df_from_whatsapp(), and is the form in which WhatsApp exports a chat on iOS, so the attacker supplies the whole file. This results in a small upload costing hundreds of megabytes of memory and of disk, and in the process being killed where that exceeds what is available.1d CVE-2026-841614.9 MED

24.6%

——7When an operator enables store.analysis_statistics_dir, a network client with PRODUCT_STORE permission for a product can call that product's storeAnalysisStatistics Thrift-over-HTTP method. CodeChecker 6.29.0 decodes the attacker-controlled Base64 string and passes the complete compressed input to one-shot zlib.decompress(). No maximum decompressed size is enforced. This gives a correctly authorized, non-superuser store account a high-ratio memory and persistent-disk amplification primitive. The complete output is first materialized as a Python bytes object and is then written to the configured statistics directory. A sufficiently scaled payload can exhaust the API worker or host memory and impair CodeChecker availability. The shipped value of store.analysis_statistics_dir is null, so the affected feature is disabled by default. The primary assessment does not rely on authentication being disabled. There is no authorization bypass and no path traversal in this report.1d CVE-2026-1194346.2 MED

7.4%

——2Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in silviucpp ezstd allows an attacker who supplies a zstd frame to ezstd:decompress_using_ddict/2 to exhaust memory and terminate the Erlang VM via a small frame that declares a very large content size. zstd_nif_decompress_using_ddict in c_src/ezstd_nif.cc reads the frame's declared content size with ZSTD_getFrameContentSize and passes it directly to enif_make_new_binary, without the 1 GiB MAX_BUFFER_SIZE check that ezstd:decompress/1 applies before allocating. A valid 65,550-byte frame of RLE blocks declaring 2 GiB is rejected by ezstd:decompress/1 but is fully allocated and decompressed by the dictionary path. The allocation happens inside a NIF, so when it exceeds the memory available to the VM the operating system kills the whole node rather than the calling process. This issue affects ezstd: from 1.0.5 before 1.2.5.1d