Description

http4k (Maven package org.http4k:http4k-core) before 6.49.0.0, 5.42.0.0 and 4.51.0.0 uses substring (Contains) matching on the Host header by default in reverseProxy() and reverseProxyRouting() when dispatching to configured virtual hosts. If these functions are deployed as a public-facing inbound HTTP handler with two or more configured virtual hosts, a remote attacker can supply a Host header that merely contains a configured vhost name (for example Host: admin.evil.com for a vhost configured as "admin") and be routed to that vhost, bypassing routing-based authorization. The intended outbound-dispatch and test-time uses, where the Host value is set by the calling application, are not affected.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-09-27T02:17:20.603Z",
  "pubdate": "2026-09-27T02:17:20.603Z",
  "executiveSummary": "A vulnerability exists in the http4k library, specifically within the reverseProxy() and reverseProxyRouting() functions, involving improper validation of the HTTP Host header.\nThe vulnerability is characterized by flawed string matching logic that uses substring (contains) verification rather than exact matching when dispatching requests to virtual hosts (vhosts).\nAffected versions include org.http4k:http4k-core prior to 6.49.0.0, 5.42.0.0, and 4.51.0.0.\nThe impact allows a remote, unauthenticated attacker to manipulate the Host header to bypass routing-based authorization controls.\nBy supplying a malicious Host header that contains a configured vhost string as a substring, an attacker can influence the application to route traffic to an unintended virtual host.\nThis flaw is exploitable only when these functions are utilized as public-facing inbound HTTP handlers with multiple virtual host configurations.\nThe risk is significant as it undermines host-based access control policies, potentially granting unauthorized access to restricted internal services or administrative environments exposed via the proxy.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the routing logic within http4k's reverseProxy() and reverseProxyRouting() handlers. When multiple virtual hosts are registered, the handler attempts to match the incoming request's Host header against the defined configuration. Instead of performing a strict, exact-match comparison against the Host header value, the library employs a substring-based search (the 'contains' operator).\nUnder normal operating conditions, an application expects the Host header to explicitly map to a specific, unique virtual host destination. However, due to the substring matching logic, if an attacker sends an HTTP request where the Host header contains a registered virtual host name, the http4k engine incorrectly identifies a match. For example, if an administrator has configured a virtual host named 'admin', an attacker can send a crafted request with 'Host: admin.evil.com'. Because the string 'admin' is found within 'admin.evil.com', the reverse proxy logic will erroneously route the request to the 'admin' vhost backend.\nThis behavior facilitates a routing bypass. Because many applications rely on the Host header to determine the security context or the intended target application/service, forcing a misroute allows an attacker to interact with services they are not authorized to access. If an application uses this routing mechanism to enforce tiered security or separate public-facing sites from administrative interfaces, the attacker can move laterally into restricted environments by manipulating the Host header input.\nThe vulnerability is scoped specifically to inbound public-facing HTTP handlers where the Host header is influenced by external, untrusted traffic. Internal outbound-dispatch operations and unit testing scenarios where the Host header is programmatically set by the calling application remain unaffected by this logic flaw, as they do not rely on untrusted header input for routing decisions.\nExploitation requires no special privileges or authentication, as the flaw resides in the request dispatching phase prior to application-level authentication. An attacker simply needs network reachability to the vulnerable endpoint and the ability to craft HTTP requests with arbitrary Host headers, which is standard in most HTTP clients and proxies. Successful exploitation results in the unauthorized redirection of traffic to arbitrary vhosts, bypassing existing authorization logic tied to host-header validation."
}