CVE-2026-100724: http4k before 6.49.0.0 Host Header Routing Bypass via reverseProxy
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
org.http4k:http4k-coreto a version that resolves this vulnerability.Fixed in 6.49.0.0 - Upgrade
Upgrade
org.http4k:http4k-coreto a version that resolves this vulnerability.Fixed in 5.42.0.0 - Upgrade
Upgrade
org.http4k:http4k-coreto a version that resolves this vulnerability.Fixed in 4.51.0.0
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments are exposed when reverseProxy() or reverseProxyRouting() is used as a public-facing inbound HTTP handler with two or more configured virtual hosts. Intended outbound-dispatch and test-time uses are not affected because the calling application sets the Host value.
What does an attacker need to exploit the routing bypass?
An attacker only needs network access to send an HTTP request to the public-facing handler. They can use a Host header that contains a configured virtual-host name, such as admin.evil.com when admin is configured, to reach that vhost.
When does this result in an authorization bypass?
The impact occurs when routing to a virtual host is relied on as an authorization boundary. A crafted Host header can cause traffic to be dispatched to a configured vhost that the requester should not be able to access.
Which versions contain the corrected behavior?
The issue affects versions before 6.49.0.0, 5.42.0.0, and 4.51.0.0. Updating to the applicable listed version or later addresses the vulnerable default Host-header matching behavior.