GHSA-97VG-427P-8HX5
Vulnerability from github – Published: 2026-07-01 20:20 – Updated: 2026-07-01 20:20SurrealDB 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 cloud metadata service) while leaving the rest of the host reachable, an authenticated principal that can call http::* and host an attacker-controlled redirect target can reach the blocked service and act on whatever interface it exposes.
Bounded to:
- Principals already permitted to call
http::*. - Capability configurations that scope deny rules by port. Host-only rules (
--deny-net <host>) are not affected because the host-only rule arm of the matcher accepts port-stripped targets.
Patches
The redirect policy now constructs the NetTarget for the redirect URL with url.port() included, so port-specific deny rules apply to redirect targets identically to initial requests.
A new integration regression test (function_http_redirect_to_denied_port_blocked) uses two wiremock servers to verify the redirect target is blocked and the denied server receives no requests.
Versions 3.1.0 and later are not affected.
Workarounds
- Replace port-specific deny rules with host-only deny rules where feasible (
--deny-net 192.168.1.1instead of--deny-net 192.168.1.1:6379). Host-only rules match port-stripped targets, at the cost of denying every port on that host. - Disable
http::*for untrusted principals (--deny-funcs 'http::*') where the functions are not required. - Terminate outbound HTTP requests at a reverse proxy that enforces port-specific access controls.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "surrealdb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-01T20:20:40Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "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 \u003chost\u003e:\u003cport\u003e` rule by chaining an HTTP redirect: the initial request goes to an `--allow-net`-permitted hostname, the response\u0027s `3xx Location` header points at the denied `host:port`, and the redirect is followed even though the destination was explicitly denied.\n\nThe 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)) =\u003e match tgt { _ =\u003e false }`), so the operator\u0027s port-scoped deny rule silently does not fire on the redirect target.\n\n### Impact\n\nThe 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.\n\nFor example, if a SurrealDB operator uses `--deny-net \u003chost\u003e:\u003cport\u003e` to block specific internal services (such as a local Redis at `192.168.1.1:6379` or an unauthenticated cloud metadata service) while leaving the rest of the host reachable, an authenticated principal that can call `http::*` and host an attacker-controlled redirect target can reach the blocked service and act on whatever interface it exposes.\n\nBounded to:\n\n- Principals already permitted to call `http::*`.\n- Capability configurations that scope deny rules by port. Host-only rules (`--deny-net \u003chost\u003e`) are not affected because the host-only rule arm of the matcher accepts port-stripped targets.\n\n### Patches\n\nThe redirect policy now constructs the `NetTarget` for the redirect URL with `url.port()` included, so port-specific deny rules apply to redirect targets identically to initial requests.\n\nA new integration regression test (`function_http_redirect_to_denied_port_blocked`) uses two wiremock servers to verify the redirect target is blocked and the denied server receives no requests.\n\nVersions 3.1.0 and later are not affected.\n\n### Workarounds\n\n- Replace port-specific deny rules with host-only deny rules where feasible (`--deny-net 192.168.1.1` instead of `--deny-net 192.168.1.1:6379`). Host-only rules match port-stripped targets, at the cost of denying every port on that host.\n- Disable `http::*` for untrusted principals (`--deny-funcs \u0027http::*\u0027`) where the functions are not required.\n- Terminate outbound HTTP requests at a reverse proxy that enforces port-specific access controls.",
"id": "GHSA-97vg-427p-8hx5",
"modified": "2026-07-01T20:20:40Z",
"published": "2026-07-01T20:20:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-97vg-427p-8hx5"
},
{
"type": "WEB",
"url": "https://github.com/surrealdb/surrealdb/commit/https://github.com/surrealdb/surrealdb/commit/ceb1ca3a1"
},
{
"type": "PACKAGE",
"url": "https://github.com/surrealdb/surrealdb"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "SurrealDB: Port-specific --deny-net rules silently bypassed on HTTP redirect"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.