CVE-2026-102072
An Improper Handling of Highly Compressed Data vulnerability in the gRPC library used by na-grpcd of Juniper Networks Junos OS allows an aut
CVSS
6.5
Média
EPSS
0.4%
p36
KEV
—
Exploit Today
11
0-100
Publicado: 14 de out. de 2026 · Última mod.: 15 de out. de 2026 · CWE-409
0.4%EPSS · 30 dias0.4%
2026-10-152026-11-06
An Improper Handling of Highly Compressed Data vulnerability in the gRPC library used by na-grpcd of Juniper Networks Junos OS allows an authenticated network-based attacker to cause a denial of service via a compressed gRPC request.
CVECVSSEPSSKEVRExploitTítuloMod.
CVE-2026-841614.9 MÉD—
——0When 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.22hCVE-2026-1194346.2 MÉD7.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.2dCVE-2026-1223237.5 ALT27.2%
——8Kyverno from 1.11.0 before 1.19.2 contains an unbounded decompression vulnerability in FetchSignatureBlob that allows attackers to exhaust memory by supplying highly compressed notary signature layers. Attackers who control registry referrers or signatures can publish small gzip layers that decompress beyond maxPayloadSize, causing admission controller OOM kills and denial of service.2dCVE-2026-1223227.5 ALT34.0%
——10Kyverno from 1.11.0 before 1.19.2 contains an unbounded decompression vulnerability in extractStatement that allows remote attackers to exhaust memory by supplying highly compressed attestation layers. Attackers controlling registry referrer artifacts can push gzip predicate layers exceeding maxPayloadSize when decompressed, causing admission controller OOM kills and denial of service.2dCVE-2026-650597.5 ALT13.5%
——4Furl versions through 3.15 for Perl allow memory exhaustion via unbounded decompression of HTTP responses.
Furl inflates a response body sent with a gzip, x-gzip or deflate Content-Encoding and appends the output to the response string with no size limit. It does this whether or not the request asked for compression, and no option caps the decompressed size. Responses read with write_file or write_code are streamed rather than held in memory.
A malicious server, or an attacker on a plain HTTP connection, can send a small compressed response that expands to exhaust the client's memory and end the process.14hCVE-2026-117677—11.3%
——3When parsing an uploaded Helm chart, Gitea decompressed the archive and read every tar entry while looking for `Chart.yaml` without limiting the decompressed size, and did so before the package size quota was checked; the quota only considers the compressed upload size. A user with package write access to an owner, for example their own account on an instance with open registration, could repeatedly upload small, highly compressed archives that make the server spend CPU time proportional to the decompressed size, degrading the availability of the Gitea instance. The issue does not allow code execution or data access.17h