Stream: git-wasmtime

Topic: wasmtime / PR #13677 Consult the host's `socket_addr_chec...

Wasmtime GitHub notifications bot (Jun 17 2026 at 17:00):

alexcrichton opened PR #13677 from alexcrichton:check-implicit-binds to bytecodealliance:main:

This PR is a combination of two commits to culminate in a fix for an issue where it's possible to, with networking disabled, still create, bind, and listen a TCP socket. The reason for this is that deny-network logic uses the socket_addr_check callback of wasi:sockets and this was never invoked when an implicit bind happened. The fix here required juggling some bindgen! logic to enable async | store with synchronous WIT functions, and then it was moving the implicit bind to a location that performs the implicit bind.

Thanks to @sdjasj for discovering this and reporting this initially as https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-r9vm-8mq9-73g9. This isn't a security issue because WASIp3 hasn't yet been released, but it's a good find to happen before the 46.0.0 release this weekend!

Also, cc @badeend as you're likely interested in this

Wasmtime GitHub notifications bot (Jun 17 2026 at 17:00):

alexcrichton requested pchickey for a review on PR #13677.

Wasmtime GitHub notifications bot (Jun 17 2026 at 17:00):

alexcrichton requested wasmtime-wasi-reviewers for a review on PR #13677.

Wasmtime GitHub notifications bot (Jun 17 2026 at 17:00):

alexcrichton requested wasmtime-core-reviewers for a review on PR #13677.

Wasmtime GitHub notifications bot (Jun 17 2026 at 17:19):

alexcrichton updated PR #13677.

Wasmtime GitHub notifications bot (Jun 17 2026 at 17:36):

alexcrichton updated PR #13677.

Wasmtime GitHub notifications bot (Jun 17 2026 at 20:25):

:thumbs_up: pchickey submitted PR review.

Wasmtime GitHub notifications bot (Jun 17 2026 at 20:35):

alexcrichton added PR #13677 Consult the host's socket_addr_check for implicit binds to the merge queue.

Wasmtime GitHub notifications bot (Jun 17 2026 at 20:37):

alexcrichton removed PR #13677 Consult the host's socket_addr_check for implicit binds from the merge queue.

Wasmtime GitHub notifications bot (Jun 17 2026 at 20:37):

alexcrichton added PR #13677 Consult the host's socket_addr_check for implicit binds to the merge queue.

Wasmtime GitHub notifications bot (Jun 17 2026 at 21:29):

:check: alexcrichton merged PR #13677.

Wasmtime GitHub notifications bot (Jun 17 2026 at 21:29):

alexcrichton removed PR #13677 Consult the host's socket_addr_check for implicit binds from the merge queue.

Wasmtime GitHub notifications bot (Jul 22 2026 at 14:54):

badeend commented on PR #13677:

If implicit binds need to be checked as well, then the connect implementations should probably to be updated too. I've added that in #13934.

@alexcrichton I don't have access to that security advisory. What is the problem exactly? You mentioned:

with networking disabled, still create, bind, and listen a TCP socket

That's not quite true, right? If AllowedNetworkUses::tcp/udp is false, then the guest can't create any socket, let alone bind it.

If implicit binds are to be checked as well, then that reduces the usefulness of the TcpBind check. Because _all_ sockets end up bound; both listeners & clients. With implicit binds included, the TcpBind check practically becomes an alias for the AllowedNetworkUses::tcp/udp flags.

I think the more interesting check to add here is smth like TcpListen to uniquely identify server code from client code. I've also added this in #13934.

Wasmtime GitHub notifications bot (Jul 22 2026 at 17:59):

alexcrichton commented on PR #13677:

The problem of the advisory and what you point out are somewhat intertwined. The CLI sort of purports itself as disallowing all host access by default, but TCP/UDP are actually enabled by default. This has sort of worked out alright in the past due to the socket address check denying access to actually doing anything with the sockets, however. The security issue was basically saying "I didn't opt in and I could still do networking things".

Writing all this out, and thinking about it, it's probably best to actually just deny TCP/UDP by default. We could then auto-enable them in the CLI if other options are passed (to avoid the need to additionally specify -Stcp,udp).

Wasmtime GitHub notifications bot (Jul 22 2026 at 20:08):

badeend commented on PR #13677:

TCP/UDP are actually enabled by default

Ah, that is .. unfortunate :grimacing:

I agree it makes more sense to have these disabled by default as well.

Last updated: Jul 29 2026 at 05:03 UTC