Stream: git-wasmtime

Topic: wasmtime / PR #15023 wasi-http: validate the Host header ...

Wasmtime GitHub notifications bot (Oct 27 2026 at 07:01):

netliomax25-code removed the review request for wasmtime-wasi-reviewers from PR #15023.

Wasmtime GitHub notifications bot (Oct 27 2026 at 07:01):

netliomax25-code opened PR #15023 from netliomax25-code:wasi-http-incoming-host-authority to bytecodealliance:main:

When an incoming request's target has no authority (the usual origin-form GET /path), incoming-request.authority falls back to the Host header. The p2 path in new_incoming_request copied that header string verbatim, so a client can hand the guest an "authority" that is not one at all. With wasmtime serve and a p2 proxy component, these Host values all come through unchanged today:

Host: evil.com#.example.com    -> authority "evil.com#.example.com"
Host: evil.com/x?.example.com  -> authority "evil.com/x?.example.com"
Host: user@evil.com            -> authority "user@evil.com"
Host: example.com:abc          -> authority "example.com:abc"
Host: a b                      -> authority "a b"

A guest that checks the authority with something like ends_with(".example.com") and then builds http://{authority}/... for a redirect or an absolute link ends up pointing at evil.com. The p3 path in Prepared::new already parses the header with http::uri::Authority, which rejects the first three of these but still accepts userinfo and a non-numeric port.

Both incoming paths now use the crate's existing parse_authority, which already enforces the uri-host [":" port] grammar for outgoing authorities. For p2 an invalid Host gets a 400, as RFC 9112 section 3.2 requires and as p2 already does for a missing Host. p3 keeps its current behavior of leaving the authority unset when the header doesn't parse. Requests whose target carries an authority are unchanged.

I added a unit test next to set_status_code_range that checks valid hosts (including [::1]:443) still come through and the values above get a 400. It fails without the fix and passes with it. cargo test -p wasmtime-wasi-http (unit, integration and doc tests), cargo clippy -p wasmtime-wasi-http --all-targets and cargo fmt --all -- --check all pass locally.

Wasmtime GitHub notifications bot (Oct 27 2026 at 07:01):

netliomax25-code requested wasmtime-wasi-reviewers for a review on PR #15023.

Wasmtime GitHub notifications bot (Oct 27 2026 at 07:01):

netliomax25-code requested rvolosatovs for a review on PR #15023.

Wasmtime GitHub notifications bot (Oct 27 2026 at 19:05):

:thumbs_up: rvolosatovs submitted PR review:

generally, values passed by the embedder to wasi-http are assumed to be valid (e.g. we don't validate Content-Length of a body originating from the host)

Following this approach, I'd expect wasmtime serve to perform this validation before passing the incoming request to e.g. new_incoming_request.

All that said, it is a fairly small change and a quick check, and performing this validation on construction, at least as a safeguard, seems harmless so LGTM

Wasmtime GitHub notifications bot (Oct 27 2026 at 19:05):

rvolosatovs added PR #15023 wasi-http: validate the Host header used as incoming request authority to the merge queue.

Wasmtime GitHub notifications bot (Oct 27 2026 at 19:06):

pchickey removed PR #15023 wasi-http: validate the Host header used as incoming request authority from the merge queue.

Wasmtime GitHub notifications bot (Oct 27 2026 at 19:07):

:repeat: pchickey submitted PR review:

There's a comprehensive set of changes and tests for this in #14988 - lets stick with that PR

Wasmtime GitHub notifications bot (Oct 27 2026 at 19:07):

:repeat: pchickey submitted PR review:

There's a comprehensive set of changes and tests for this in #14988 - lets stick with that PR, which is nearly complete

Wasmtime GitHub notifications bot (Oct 28 2026 at 11:29):

xia-chao commented on PR #15023:

Thank you! #14988 is already covered

Last updated: Oct 31 2026 at 23:03 UTC