SurrealDB before 3.1.0 contains a capability bypass vulnerability in HTTP redirect handling that allows authenticated users to circumvent port-scoped --deny-net rules. Attackers can chain an HTTP redirect from an allowed hostname to a denied host:port combination, and the redirect is followed because the port information is dropped during redirect policy evaluation.

Affected: crates.io: surrealdb

SurrealDB offers `http::*` functions that can access external network endpoints, with the `--allow-net` and `--deny-net` capabilities used to restrict the set of network targets that can be reached. An authenticated user of SurrealDB can bypass a port-scoped `--deny-net <host>:<port>` rule by chaining an HTTP redirect: the initial request goes to an `--allow-net`-permitted hostname, the response's `3xx Location` header points at the denied `host:port`, and the redirect is followed even though the destination was explicitly denied.

The root cause is in the redirect policy applied to outbound HTTP requests (`surrealdb/core/src/fnc/util/http/mod.rs`): the `NetTarget` for the redirect destination is built from `url.host_str()` alone and `url.port()` is dropped. The capability matcher (`surrealdb/core/src/dbs/capabilities.rs:259-264`) refuses to match a port-bearing rule against a port-stripped target (`Self::Host(host, Some(port)) => match tgt { _ => false }`), so the operator's port-scoped deny rule silently does not fire on the redirect target.

### Impact

The impact of this vulnerability is circumvention of the `--deny-net` capability when the operator has scoped deny rules by port, and the resulting impact on systems external to SurrealDB. The ultimate impact is dependent on the deployment scenario.

For example, if a SurrealDB operator uses `--deny-net <host>:<port>` to block specific internal services (such as a local Redis at `192.168.1.1:6379` or an unauthenticated clo…