CVE-2026-12588
An attacker with access to an HX 10.0.0 and previous versions, may send specially-crafted data to the HX console. The malicious detection w
CVSS
—
No CVSS
EPSS
0.3%
p26
KEV
—
Exploit Today
8
0-100
Published: Jul 14, 2026 · Last modified: Jul 15, 2026 · CWE-409
0.2%EPSS · 30 days0.3%
2026-08-172026-09-14
An attacker with access to an HX 10.0.0 and previous versions, may send specially-crafted data to the HX console. The malicious detection would then trigger decompression of a large file that consumes an excessive amount of system resources thus causing a Denial of Service.
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-441635.3 MED—
———fluent-plugin-opentelemetry is a Fluentd input and output plugin for forwarding OpenTelemetry Protocol data. Prior to 0.5.3, the in_opentelemetry HTTP input read the entire incoming request body and decompressed payloads into memory without enforcing maximum size thresholds. When an OpenTelemetry ingestion endpoint was exposed to an untrusted network, an attacker could send an excessively large request or a highly compressed payload that expanded in memory. The resulting memory exhaustion could cause the operating system to terminate the Fluentd process, disrupting all log collection and forwarding on the affected node. This issue is fixed in version 0.5.3.6hCVE-2026-536597.5 HIG—
——0http4k is a functional toolkit for Kotlin HTTP applications. Prior to 4.51.0.0, 5.42.0.0, and 6.49.0.0, ServerFilters.GZip, RequestFilters.GunZip, and the underlying Gzip request-body decompression functions impose no limit on decompressed size. An unauthenticated client can send a small gzip-encoded request body that expands to gigabytes, exhausting the JVM heap and denying service to other clients. The fix uses SizeLimitedInputStream to enforce a default 10 MiB limit, causes ServerFilters.GZip and RequestFilters.GunZip to return 413 Request Entity Too Large, and causes other decompression paths to throw SizeLimitExceededException. This issue is fixed in versions 4.51.0.0, 5.42.0.0, and 6.49.0.0.1dCVE-2026-441622.7 LOW—
——0fluent-plugin-s3 is an Amazon S3 input and output plugin for Fluentd. From 0.7.0 to 1.8.4, the in_s3 input plugin reads the entire decompressed payload of gzip, lzma2, and lzop objects into memory without enforcing a decompression_size_limit. An attacker with permission to upload objects to the monitored S3 bucket can provide a highly compressed object that expands excessively when Fluentd processes it. The resulting memory exhaustion can cause the operating system to terminate the Fluentd process and disrupt all log collection on the affected node. This issue is fixed in version 1.8.5.1dCVE-2026-51326.5 MED—
——0Mattermost versions 11.9.x <= 11.9.0, 11.8.x <= 11.8.4, 11.7.x <= 11.7.7, 10.11.x <= 10.11.22 fail to limit size of unpacked SDP messages compressed with zlib, which allows attacker to deny service or crash server via sending many SDP messages that unpack to large size.. Mattermost Advisory ID: MMSA-2026-006431dCVE-2026-158146.5 MED—
——0Mattermost versions 11.9.x <= 11.9.0, 11.8.x <= 11.8.4, 11.7.x <= 11.7.7, 10.11.x <= 10.11.22 fail to limit the amount of memory allocated when decoding uploaded image files which allows an authenticated user to cause excessive server memory consumption and potential denial of service via uploading a specially crafted image as a profile picture, channel file attachment, team icon, or custom brand image. Mattermost Advisory ID: MMSA-2026-007191dCVE-2026-893214.3 MED18.5%
——6Publishing limits the compressed size of a VSIX (ovsx.publishing.max-content-size, 512 MB by default) but nothing limited how large an entry becomes when opened.
On the first request to /vscode/unpkg/{namespace}/{extension}/{version}/{path}, WebResourceService opened the entry with ZipFile.getInputStream() and passed the decompressed stream to Files.copy(), which ran to the end of the stream without counting bytes written. The result was cached under java.io.tmpdir, and that cache evicted by entry count (150), not by size, so it placed no bound on disk usage.
A publisher with access only to their own namespace could therefore upload a small, highly compressible VSIX and cause the server to write far larger files to the temp filesystem — repeating with different files or versions, since a repeat request is served from the cache.
Impact observed: the temp filesystem filled; requests for files not already cached returned 500 with No space left on device; a failed extraction left a partial cache file that blocked later attempts at that path; publishing failed with Failed to read extension file. Metadata and already-cached files kept working, and the server did not stop.
Triggering the extraction needs no authentication — only the upload does.1d