CVE-2026-100724: http4k Virtual Host Auth Bypass Vulnerability

CVE-2026-100724 Overview

CVE-2026-100724 affects the http4k Kotlin HTTP toolkit, specifically the org.http4k:http4k-core Maven package. The flaw resides in the reverseProxy() and reverseProxyRouting() functions, which use substring (Contains) matching on the Host header by default when dispatching to configured virtual hosts. An attacker who sends a Host header merely containing a configured vhost name can route traffic to that vhost and bypass routing-based authorization. The issue is classified as HTTP Request Smuggling / Inconsistent Interpretation of HTTP Requests [CWE-444]. Fixed versions are 6.49.0.0, 5.42.0.0, and 4.51.0.0.

Critical Impact
Remote attackers can bypass virtual-host routing authorization by crafting a Host header such as admin.evil.com to reach a vhost configured as admin.

Affected Products

http4k org.http4k:http4k-core versions before 6.49.0.0
http4k org.http4k:http4k-core versions before 5.42.0.0 (5.x branch)
http4k org.http4k:http4k-core versions before 4.51.0.0 (4.x branch)

Discovery Timeline

2026-09-27 - CVE-2026-100724 published to NVD
2026-09-30 - Last updated in NVD database

Technical Details for CVE-2026-100724

Vulnerability Analysis

http4k provides reverseProxy() and reverseProxyRouting() helpers that dispatch inbound HTTP traffic to different HttpHandler instances based on the request Host header. Before the fix, these functions matched the configured vhost name using substring containment against the inbound Host value. Any inbound request whose Host header merely contained the vhost string would be routed to that handler.

When the library is used as a public-facing inbound HTTP handler with two or more configured virtual hosts, the attacker controls the Host header. By registering an external domain that embeds the vhost token (for example admin.evil.com), the attacker reaches a vhost that was intended to be reachable only through trusted hostnames protected by routing-based authorization. Intended outbound-dispatch and test-time uses, where the calling application sets the Host, are not affected.

Root Cause

The root cause is permissive host matching logic. The default matcher evaluated A.contains(B) rather than requiring an exact hostname match, violating the implicit trust boundary of host-based routing.

Attack Vector

Exploitation requires only network access to the exposed http4k endpoint. The attacker sends an HTTP request with a crafted Host header; no authentication or user interaction is required. The result is routing to a privileged vhost whose authorization model assumed hostname-based isolation.

text

// Initial patch introducing a pluggable matcher (default remained Contains)
+import org.http4k.routing.ReverseProxyHostMatcher.Companion.Contains

-fun reverseProxy(vararg hostToHandler: Pair<String, HttpHandler>): HttpHandler =
-    reverseProxyRouting(*hostToHandler)
+fun reverseProxy(
+    vararg hostToHandler: Pair<String, HttpHandler>, matcher: ReverseProxyHostMatcher = Contains
+): HttpHandler =
+    reverseProxyRouting(*hostToHandler, matcher = matcher)

// Follow-up patch changing the default to Exact
-    vararg hostToHandler: Pair<String, HttpHandler>, matcher: ReverseProxyHostMatcher = Contains
+    vararg hostToHandler: Pair<String, HttpHandler>, matcher: ReverseProxyHostMatcher = Exact

Source: GitHub Commit 0121b05537 and GitHub Commit 54c6385615

Detection Methods for CVE-2026-100724

Indicators of Compromise

Inbound HTTP requests whose Host header contains a configured vhost token as a substring but does not match an owned domain (for example Host: admin.attacker.tld).
Access log entries showing requests routed to privileged vhost handlers from unexpected Host values or source IP ranges.
Authorization decisions that succeeded on routes previously assumed to be reachable only via internal hostnames.

Detection Strategies

Inventory applications and services that depend on org.http4k:http4k-core and verify the version against the fixed releases.
Perform static review of code to locate calls to reverseProxy() or reverseProxyRouting() that are exposed to untrusted networks.
Replay historical access logs through a parser that flags Host headers not matching an allow-list of owned domains.

Monitoring Recommendations

Alert on anomalous Host header values at the ingress proxy or web application firewall layer.
Record and review which vhost handler processed each request to detect unexpected cross-vhost dispatch.
Monitor for authorization events on administrative routes correlated with external source addresses.

How to Mitigate CVE-2026-100724

Immediate Actions Required

Upgrade org.http4k:http4k-core to 6.49.0.0, 5.42.0.0, or 4.51.0.0 depending on the branch in use.
Audit all production uses of reverseProxy() and reverseProxyRouting() exposed to untrusted clients.
Enforce an explicit Host header allow-list at the upstream load balancer or reverse proxy until the library is patched.

Patch Information

The fix was delivered in two commits. Commit 0121b05537 introduced a pluggable ReverseProxyHostMatcher while retaining Contains as the default. Commit 54c6385615 changed the default matcher to Exact, resolving the bypass. See the GitHub Security Advisory GHSA-jrpc-7vxp-69p6 and the VulnCheck Advisory on http4k for additional detail.

Workarounds

Explicitly pass matcher = ReverseProxyHostMatcher.Companion.Exact when calling reverseProxy() or reverseProxyRouting() after upgrading to a version that exposes the parameter.
Front the http4k service with a reverse proxy (NGINX, HAProxy, Envoy) that normalizes and validates the Host header against an exact allow-list before forwarding.
Enforce authorization checks within each vhost handler rather than relying on hostname-based routing alone.

bash

# Example Gradle dependency upgrade
# build.gradle.kts
dependencies {
    implementation("org.http4k:http4k-core:6.49.0.0")
}

# Example NGINX ingress enforcement of an exact Host allow-list
# nginx.conf
server {
    listen 443 ssl;
    if ($host !~* ^(admin\.example\.com|api\.example\.com)$) {
        return 421;
    }
    location / {
        proxy_pass http://http4k_backend;
    }
}