External risk intelligence

Http4s Ember HTTP/1.1 Request Smuggling Vulnerability

CVE advisorySeverity: CRITICAL (CVSS 9.2)

CVE-2026-69204

Http4s is a library used to build HTTP services and APIs. Because these services are commonly deployed to handle public-facing web traffic or act as internet-facing API endpoints, the vulnerable interface is frequently reachable from the internet in standard application deployments.

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A vulnerability exists in http4s, a Scala interface for HTTP services, related to how it handles specific message headers. This could allow an unauthenticated attacker to potentially bypass access controls, poison caches, or manipulate requests forwarded by intermediaries. The main concern is confirming if our environment utilizes the affected versions of http4s.

Unexpected header behavior allows request manipulation.
Risk of bypassed access controls and cache poisoning.
Confirm if affected http4s versions are in use.

Attack Path

How an attacker could exploit the issue

An attacker could exploit this vulnerability by sending specially crafted HTTP messages to a server running a vulnerable version of http4s, especially when it's behind a keep-alive intermediary. This could allow them to bypass access controls, manipulate cached content, or disrupt legitimate user requests.

Requires network access and no privileges.
Triggers by sending combined `Transfer-Encoding` and `Content-Length` headers.
Allows request smuggling and cache poisoning.

Live Threat

Current exploitation, exposure, and threat context

When intermediary servers and http4s's Ember HTTP/1.1 disagree on how to frame HTTP messages, an attacker could potentially smuggle a second request. This could allow them to bypass access controls, poison caches, or manipulate a victim's request. The vulnerability could also affect http4s client connections when interacting with a malicious upstream server.

Server and client communication.
Request header processing.
Bypassed access controls.

Operational Fix

Recommended remediation, mitigation, and detection steps

Technical leaders and system owners should engage platform or application teams responsible for services built with http4s. The first practical step is to identify all deployments of http4s, determine their reachability and criticality, and then assign an accountable owner to plan remediation.

Platform/application teams own the issue.
Verify http4s deployment reachability and criticality.
Plan remediation based on identified risk.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Http4s?

Http4s is a type-safe, functional library for the Scala programming language used to build HTTP servers and clients. It provides a modular interface for developers to create high-performance web services and APIs. Because it handles the complexities of HTTP protocol parsing, developers often integrate it into backend systems that manage application logic, data flow, and public-facing communication.

What does CWE-444 mean for CVE-2026-69204?

CWE-444, or HTTP Request Smuggling, occurs when a server and an intermediary (like a load balancer or proxy) interpret HTTP headers differently. In this CVE, the Ember HTTP/1.1 component fails to properly reject messages containing both Transfer-Encoding and Content-Length headers. This inconsistency lets an attacker trick the system into misidentifying where one request ends and another begins, allowing them to smuggle hidden requests through the server.

How is this vulnerability triggered?

An attacker triggers this by sending an HTTP request that includes both Transfer-Encoding and Content-Length headers. This exploit requires the vulnerable Http4s instance to be positioned behind a keep-alive intermediary server that interprets these headers differently. Requests sent directly to an instance not using an intermediary or those using properly configured proxies that sanitize these conflicting headers do not trigger this specific flaw.

Who should be concerned about this flaw?

Teams managing internet-facing applications built with Http4s should prioritize this. According to Halo Surface Signal, Http4s is frequently used for public-facing web traffic or API endpoints, making it highly likely to be reachable from the internet in standard deployments. If your service sits behind a proxy, it is at higher risk because the flaw relies on the interaction between your service and that upstream intermediary.

When should I update my Http4s software?

You should plan to update as soon as you identify any services running versions of Http4s prior to 0.23.35 or 1.0.0-M47. Start by auditing your dependency manifests to locate where Http4s is used, then verify which environments are exposed to external traffic. Once you have an inventory, coordinate with your application teams to upgrade to the patched versions, which explicitly address how these conflicting request headers are handled.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.