CVE-2026-69213

Received Received - Intake

Http/2 Memory Exhaustion in Http4s Ember

Publication date: 2026-09-15

Last updated on: 2026-09-15

Assigner: GitHub, Inc.

Description

Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, Ember HTTP/2 serializes outbound frames through one unbounded queue consumed by writeLoop. When the peer stops reading, an unauthenticated HTTP/2 client can continue sending PING, SETTINGS, or DATA frames that cause Ember to enqueue acknowledgments or WINDOW_UPDATE frames faster than the writer drains them, exhausting heap memory on a server built with withHttp2. The shared behavior also affects an ember-client connected to a hostile HTTP/2 server, and the patch replaces the unbounded path with bounded, backpressured outbound queues. This issue is fixed in versions 0.23.35 and 1.0.0-M47.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-09-15

Last Modified

2026-09-15

Generated

2026-10-06

AI Q&A

2026-09-16

EPSS Evaluated

2026-10-04

NVD

CVE-2026-69213

EUVD

EUVD-2026-79183

Affected Vendors & Products

Vendor	Product	Version / Range
ember	ember_http2	to 0.23.35 (inc)
ember	ember_http2	to 1.0.0-m47 (inc)

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-400	The product does not properly control the allocation and maintenance of a limited resource.
CWE-770	The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.

Attack-Flow Graph

Executive Summary

This vulnerability in Http4s is a memory exhaustion issue in the HTTP/2 implementation. It occurs because outbound frames are queued in an unbounded buffer that grows without limit when the peer stops reading. An attacker can send minimal control frames like PING, SETTINGS, or DATA to force the server or client to queue acknowledgments or WINDOW_UPDATE frames indefinitely, consuming all available heap memory and causing a denial-of-service condition.

Detection Guidance

Detecting this vulnerability requires monitoring for abnormal memory usage or connection patterns in HTTP/2 traffic. Check for processes using http4s-ember-core with HTTP/2 enabled that show unusually high memory consumption. Use system monitoring tools like top, htop, or ps to observe memory usage spikes in Java/Scala applications. Network monitoring tools like Wireshark can inspect HTTP/2 frames for excessive PING, SETTINGS, or WINDOW_UPDATE frames from a single source.

Impact Analysis

If you use Http4s with HTTP/2 enabled, an unauthenticated remote attacker could exploit this to crash your application by exhausting its memory. This affects both servers (if a malicious client connects) and clients (if connecting to a hostile server). The impact includes application crashes, service unavailability, and potential data loss due to forced restarts.

Compliance Impact

This vulnerability could lead to denial-of-service conditions via memory exhaustion, potentially disrupting availability of systems handling sensitive data. For GDPR, this may impact availability requirements under Article 32. For HIPAA, it could affect the integrity and availability of protected health information systems.

Mitigation Strategies

Upgrade http4s-ember-core to version 0.23.35 or 1.0.0-M47 or later to patch the unbounded queue issue.
Disable HTTP/2 by avoiding the use of .withHttp2 in your application configuration as a temporary workaround.
Implement rate limiting or connection throttling for HTTP/2 traffic to prevent resource exhaustion.
Monitor memory usage of http4s applications and set up alerts for abnormal spikes that may indicate exploitation.

Hi! I’m here to help you understand CVE-2026-69213. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70