GHSA-5vcm-3xc3-w7x3
HIGHResponse Splitting from unsanitized headers
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
org.http4s:http4s-client_2.12☕org.http4s:http4s-client_2.12☕org.http4s:http4s-client_2.12☕org.http4s:http4s-client_2.13☕org.http4s:http4s-client_2.13☕org.http4s:http4s-client_2.13☕org.http4s:http4s-client_3☕org.http4s:http4s-client_3+12 moreReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Impact
http4s is vulnerable to response-splitting or request-splitting attacks when untrusted user input is used to create any of the following fields:
- Header names (
Header.nameå - Header values (
Header.value) - Status reason phrases (
Status.reason) - URI paths (
Uri.Path) - URI authority registered names (
URI.RegName) (through 0.21)
The following backends render invalid carriage return, newline, or null characters in an unsafe fashion.
| blaze-server | ember-server | blaze-client | ember-client | jetty-client | |
|---|---|---|---|---|---|
| header names | ⚠ | ⚠ | ⚠ | ⚠ | ⚠ |
| header values | ⚠ | ⚠ | ⚠ | ⚠ | |
| status reasons | ⚠ | ⚠ | |||
| URI paths | ⚠ | ⚠ | |||
| URI regnames | ⚠ < 0.22 | ⚠ < 0.22 |
For example, given the following service:
import cats.effect._
import org.http4s._
import org.http4s.dsl.io._
import org.http4s.server.blaze.BlazeServerBuilder
import scala.concurrent.ExecutionContext.global
object ResponseSplit extends IOApp {
override def run(args: List[String]): IO[ExitCode] =
BlazeServerBuilder[IO](global)
.bindHttp(8080)
.withHttpApp(httpApp)
.resource
.use(_ => IO.never)
val httpApp: HttpApp[IO] =
HttpApp[IO] { req =>
req.params.get("author") match {
case Some(author) =>
Ok("The real content")
.map(_.putHeaders(Header("Set-Cookie", s"author=${author}")))
case None =>
BadRequest("No author parameter")
}
}
}
A clean author parameter returns a clean response:
curl -i 'http://localhost:8080/?author=Ross'
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Set-Cookie: author=Ross
Date: Mon, 20 Sep 2021 04:12:10 GMT
Content-Length: 16
The real content
A malicious author parameter allows a user-agent to hijack the response from our server and return different content:
curl -i 'http://localhost:8080/?author=hax0r%0d%0aContent-Length:+13%0d%0a%0aI+hacked+you'
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Set-Cookie: author=hax0r
Content-Length: 13
I hacked you
Patches
Versions 0.21.29, 0.22.5, 0.23.4, and 1.0.0-M27 perform the following:
- If a status reasoon phrase is invalid, it is dropped. Rendering is optional per spec.
- If a header name is invalid in a request or response, the header is dropped. There is no way to generically sanitize a header without potentially shadowing a correct one.
- If a header value is invalid in a request or response, it is sanitized by replacing null (
\u0000), carriage return (\r), and newline (\n) with space () characters per spec. - If a URI path or registered name is invalid in a request line, the client raises an
IllegalArgumentException. - If a URI registered name is invalid in a host header, the client raises an
IllegalArgumentException.
Workarounds
http4s services and client applications should sanitize any user input in the aforementioned fields before returning a request or response to the backend. The carriage return, newline, and null characters are the most threatening.
Not all backends were affected: jetty-server, tomcat-server, armeria, and netty on the server; async-http-client, okhttp-client, armeria, and netty as clients.
References
- https://owasp.org/www-community/attacks/HTTP_Response_Splitting
- https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#fields.values
For more information
If you have any questions or comments about this advisory:
- Open an issue in GitHub
- Contact us via the http4s security policy
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.http4s:http4s-client_2.12 | all versions | 0.21.29 |
| ☕Maven | org.http4s:http4s-client_2.12 | ≥ 0.22.0&&< 0.22.5 | 0.22.5 |
| ☕Maven | org.http4s:http4s-client_2.12 | ≥ 0.23.0&&< 0.23.4 | 0.23.4 |
| ☕Maven | org.http4s:http4s-client_2.13 | all versions | 0.21.29 |
| ☕Maven | org.http4s:http4s-client_2.13 | ≥ 0.22.0&&< 0.22.5 | 0.22.5 |
| ☕Maven | org.http4s:http4s-client_2.13 | ≥ 0.23.0&&< 0.23.4 | 0.23.4 |
Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.http4s:http4s-client_2.12. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update org.http4s:http4s-client_2.12 to 0.21.29 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-5vcm-3xc3-w7x3 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-5vcm-3xc3-w7x3 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-5vcm-3xc3-w7x3. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-5vcm-3xc3-w7x3 in your dependencies?
O3 detects GHSA-5vcm-3xc3-w7x3 across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.