Medium Org.http4s CVEs with no public exploit
6 CVEs, 2 protected by Waratek
Overview 6 matches · 2 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
Protected by Waratek
2
33.3%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
4
66.7%
blocked by ARMR today
2
33.3%
partly blocked
0
0.0%
not blocked
4
66.7%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
0
0.0%
Forecast only
0
0.0%
No public exploit
6
100.0%
split by
peak 5 / quarter
Q2 211
Protected by Waratek1
Medium1
blocked by ARMR today1
No public exploit1
Q3 210
Q4 210
Q1 220
Q2 220
Q3 220
Q4 220
Q1 230
Q2 230
Q3 230
Q4 230
Q1 240
Q2 240
Q3 240
Q4 240
Q1 250
Q2 250
Q3 250
Q4 250
Q1 260
Q2 260
Q3 265
Protected by Waratek1
No exploit published4
Medium5
blocked by ARMR today1
not blocked4
No public exploit5
Q3 21Q1 22Q3 22Q1 23Q3 23Q1 24Q3 24Q1 25Q3 25Q1 26Q3 26
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-69216 | Medium | 2026-09-15 | No exploit published | No public exploit | Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, Ember’s chunk decoder trims the chunk-size token and accepts leading plus or minus signs instead of requiring one or more hexadecimal digits followed by the required CRLF. When an intermediary forwards chunked data without re-encoding and interprets malformed chunk boundaries differently, an unauthenticated attacker can create TE.TE request smuggling that bypasses intermediary controls, poisons caches, or hijacks the request queue. The same response-path leniency can enable response smuggling against an ember-client used as a gateway when the upstream is malicious or compromised. This issue is fixed in versions 0.23.35 and 1.0.0-M47. |
| CVE-2026-69215 | Medium | 2026-09-15 | No exploit published | No public exploit | Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, The CookieJar client middleware uses unanchored substring checks instead of RFC 6265 domain and path matching when deciding whether to attach a stored cookie. A cookie for example.com can consequently be sent to an attacker-controlled hostname such as evilexample.com when an application using the same jar makes an attacker-influenced outbound request. This exposes session or authentication cookies and can enable hijacking of the application’s outbound sessions. This issue is fixed in versions 0.23.35 and 1.0.0-M47. |
| CVE-2026-69214 | Medium | 2026-09-15 | No exploit published | No public exploit | Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, The CookieJar client middleware stores a response cookie’s Domain attribute without checking that it domain-matches the host that supplied the cookie or rejecting public suffixes. A malicious or compromised server contacted through the same CookieJar can plant a cookie for another domain, and the jar later sends that cookie to the victim domain, enabling session fixation or overwriting security-sensitive cookies. The patch validates the Set-Cookie domain against the response origin, although public-suffix rejection remains unimplemented. This issue is fixed in versions 0.23.35 and 1.0.0-M47. |
| CVE-2026-69206 | Medium | 2026-09-15 | No exploit published | No public exploit | Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, DigestAuth replay protection records lastNc plus one instead of the highest nonce-count value it has accepted. When a legitimate client sends noncontiguous nc values because of parallel or retried requests, the stored counter remains below the accepted maximum, allowing a passive observer to replay a captured Authorization header multiple times. Successful replays execute authenticated requests, including state-changing operations, as the captured user. This issue is fixed in versions 0.23.35 and 1.0.0-M47. |
| CVE-2026-69201 | Medium | 2026-09-15 | Protected by Waratek | No public exploit | Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, ResourceService and WebjarService decode each URL path segment but reject only segments exactly equal to an empty string, a dot, or two dots. A request containing percent-encoded slash or backslash separators can turn an accepted segment into a parent-directory traversal after decoding, allowing access to classpath or WebJar resources outside the configured base when a directory-backed classpath is served and the backend preserves the encoded separator. The patch rejects decoded segments containing slash or backslash in ResourceService and WebjarService, and applies the same guard to the non-exploitable FileService for consistency. This issue is fixed in versions 0.23.35 and 1.0.0-M47. |
| CVE-2021-32643 | Medium | 2021-05-27 | Protected by Waratek | No public exploit | Http4s is a Scala interface for HTTP services. `StaticFile.fromUrl` can leak the presence of a directory on a server when the `URL` scheme is not `file://`, and the URL points to a fetchable resource under its scheme and authority. The function returns `F[None]`, indicating no resource, if `url.getFile` is a directory, without first checking the scheme or authority of the URL. If a URL connection to the scheme and URL would return a stream, and the path in the URL exists as a directory on the server, the presence of the directory on the server could be inferred from the 404 response. The contents and other metadata about the directory are not exposed. This affects http4s versions: 0.21.7 through 0.21.23, 0.22.0-M1 through 0.22.0-M8, 0.23.0-M1, and 1.0.0-M1 through 1.0.0-M22. The [patch](https://github.com/http4s/http4s/commit/52e1890665410b4385e37b96bc49c5e3c708e4e9) is available in the following versions: v0.21.24, v0.22.0-M9, v0.23.0-M2, v1.0.0-M23. As a workaround users can avoid calling `StaticFile.fromUrl` with non-file URLs. |