CVE WatchSep 15, 2026

CVE-2026-69218

Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, When Ember receives an HTTP/2 HEADERS or PUSH_PROMISE frame w

CVSS

7.5

High

EPSS

—

KEV

—

Exploit Today

—

0-100

Published: Sep 15, 2026 · Last modified: Sep 15, 2026 · CWE-770

EPSS · 30d

Not enough EPSS history yet.

Technical description

Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, When Ember receives an HTTP/2 HEADERS or PUSH_PROMISE frame without END_HEADERS, H2Connection buffers the header block and subsequent CONTINUATION fragments without a size bound. A remote peer can keep an incomplete block open and exhaust heap memory before request decoding, affecting an ember-server or ember-client configured with withHttp2. The remediation tracks accumulated size against SETTINGS_MAX_HEADER_LIST_SIZE derived from EmberServerBuilder.maxHeaderSize or EmberClientBuilder.maxResponseHeaderSize, sends GOAWAY when the limit is exceeded, and applies receiveHeadersTimeout to incomplete blocks. This issue is fixed in versions 0.23.35 and 1.0.0-M47.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-691476.5 MED

—

———vLLM is an inference and serving engine for large language models. Prior to 0.28.0, request bodies for Chat Completions and Responses can set media_io_kwargs.video.video_backend to pynvvideocodec, and MediaConnector.fetch_video forwards that choice to VideoMediaIO even when startup configuration selected a software decoder. The engine's _reserve_mm_ipc_gpu_memory logic budgets decoder memory only from static configuration, so the request-selected VIDEO_LOADER_REGISTRY backend can create a CUDA context, decoder surfaces, and decoded-frame allocations that were not removed from the engine's KV-cache budget. An attacker able to submit video requests to a video-capable GPU deployment with PyNvVideoCodec installed can exhaust shared GPU memory, causing request failures, worker crashes, or denial of service. The first release containing the fix is version 0.28.0.2h CVE-2026-571736.5 MED

—

———vLLM is an inference and serving engine for large language models. Prior to 0.24.0, the input_audio handling path for /v1/chat/completions calls AudioMediaIO.load_bytes or AudioMediaIO.load_file without passing VLLM_MAX_AUDIO_DECODE_DURATION_S to the shared audio decoder. An unauthenticated client can therefore submit a small compressed audio input that expands into a very large float32 PCM allocation, bypassing the duration guard already used by /v1/audio/transcriptions and causing an out-of-memory worker crash. Inline data URLs reach this path without being bounded by VLLM_AUDIO_FETCH_TIMEOUT. The issue affects deployments serving an audio-capable model, and authentication changes only the deployment-specific reachability. This issue is fixed in version 0.24.0.3h CVE-2026-77409—

—

———RabbitMQ amqp091-go is a Go AMQP 0.9.1 client. Prior to 1.13.0, Channel.dispatch in channel.go, confirms.confirm in confirms.go, and Connection.dispatch0 in connection.go synchronously send publisher confirmations, flow-control events, consumer cancellations, returned messages, including NotifyConfirm events and connection block notifications, to application-provided channels. If a listener channel is unbuffered, full, or not drained promptly, the sole reader goroutine blocks and stops processing frames, acknowledgments, deliveries, and heartbeats. Broker-driven event bursts can therefore cause connection stalls, missed heartbeats, deadlocks, and disconnection. This issue is fixed in version 1.13.0.5h CVE-2026-77403—

—

———RabbitMQ amqp091-go is a Go AMQP 0.9.1 client. Prior to 1.13.0, Connection.openTune in connection.go accepts a server-advertised FrameMax below the AMQP frameMinSize value of 4096 bytes because the connection negotiation loop does not enforce the protocol minimum. A malicious or compromised AMQP broker can therefore advertise an extremely small FrameMax, causing later client publications to be fragmented into excessive numbers of frames and write operations. This can consume CPU and stall the client or its host. This issue is fixed in version 1.13.0.4h CVE-2026-855015.3 MED

—

———Novel vulnerabilities to launch algorithmic complexity attacks on DNSSEC have been researched under the term 'ReTrap'. These result in degradation of service when malicious zones are used to serve the algorithmic complexity vulnerabilities. NLnet Labs Unbound up to and including 1.26.0 is vulnerable to some of them. TagTrap, where the triple(Zone, Algo, KeyTag) matching mechanism introduces a significant attack vector when resolvers handle malicious responses containing numerous mismatched DNSKEY, RRSIG, and DS record. DelegationTrap, where constructing the chain-of-trust requires iterative validation of DNSKEY and DS records from the root zone downward. For deeply nested domains, this results in significant computational overhead. NsecTrap, where responses with excessive invalid NSEC records compel the resolver to validate each one. AdditionalTrap, where Unbound by default would try to DNSSEC validate the ADDITIONAL section as well. This can be exploited to waste validation resources by malicious users.5h CVE-2026-802255.3 MED

—

———In NLnetLabs Unbound up to and including 1.26.0, a degradation of service vulnerability is present in the TCP/DoT reading procedure where there is no limit on consecutive reads. A malicious actor that can stream and sustain a rate of distinct uncached names over the TCP/DoT connection, monopolizes a single worker's entire event loop for as long as its writes stay ahead of the drain.5h