CVE-2025-71390: SurrealDB before 2.3.6 deny-net Bypass via DNS Resolution

Published Jul 18, 2026
·
Updated

SurrealDB before 2.2.6, 2.3.6, and 2.1.8 (and 3.0.0-alpha.7 and earlier) fails to validate DNS-resolved hostnames against --deny-net network access restrictions in its http:: functions. An authenticated user can invoke http::<fn>(<url>) with a hostname that resolves to a denied IP address, causing the server to issue the request anyway and return the response. This bypasses network access controls, allowing access to restricted internal endpoints and potentially retrieving or altering sensitive information and credentials, depending on the deployment.

Other sources

SurrealDB offers http functions that can access external network endpoints. A typical, albeit not recommended configuration would be to start SurrealDB with all network connections allowed with the exception of a deny list. For example, surreal start --allow-net --deny-net 10.0.0.0/8 will allow all network connections except to the 10.0.0.0/8 block.

An authenticated user of SurrealDB can use bypass this restriction, using http::<fn>(<url>) functions where the hostname resolves to an IP within the --deny-net block. For example if a SurrealDB administrator wanted to restrict access to other services within a private network and thus set the --deny-net to a network IP range, this could be circumvented by an attacker leveraging DNS records and hostname resolution.

When sending SurrealDB statements containing the http:: functions, if the hostname resolves to a forbidden IP, the SurrealDB server will still issue the request and return the responses to the attacker.

Impact The impact of this vulnerability is circumvention of the --deny-net capability and resulting impact on systems external to SurrealDB. The ultimate impact is dependent on the deployment scenario.

For example, if the SurrealDB server blocks requests to internal/private IP addresses because those services don’t require authentication, but an attacker can still use SurrealDBs ability to resolve their hostnames via DNS and invoke them directly using http::<fn>(<url>), the attacker can access these internal endpoints directly, and potentially retrieve or even alter sensitive information and credentials.

Patches A patch has been created that checks resolved hostnames against allowed network targets, preventing http:: functions from connecting to disallowed IPs.

- Versions 2.2.6, 2.3.6 and later are not affected by this issue. - The first release following 2.1.7 and 3.0.0-alpha.7 and later will not be affected by this issue

Workarounds The possibility of this vulnerability being exploited can be reduced by following an allowlist approach to enabling the http capability surreal start --allow-net 10.0.0.0/8 or using the equivalent SURREALCAPSALLOWNET environment variable, where endpoints allowed are fully trusted and are not controlled by regular users.

Alternatively, the network access capability can be disabled, using --deny-net or the equivalent SURREALCAPSDENYNET environment variable without specifying targets, which disables all outbound HTTP, with impact to SurrealDB functionality.

As the impact of this vulnerability depends on the security of the deployment environment of SurrealDB, best practices should be followed within that environment.

— GitHub

Affected Software

18 affected componentsFixes available
SurrealDB SurrealDB<2.2.6
SurrealDB SurrealDB<2.3.6
SurrealDB SurrealDB<2.1.8
SurrealDB SurrealDB<3.0.0-alpha.7
SurrealDB SurrealDB<2.1.8
SurrealDB SurrealDB>=2.2.0<2.2.6
SurrealDB SurrealDB>=2.3.0<2.3.6
SurrealDB SurrealDB=3.0.0-alpha1
SurrealDB SurrealDB=3.0.0-alpha2
SurrealDB SurrealDB=3.0.0-alpha3
SurrealDB SurrealDB=3.0.0-alpha4
SurrealDB SurrealDB=3.0.0-alpha5
SurrealDB SurrealDB=3.0.0-alpha6
SurrealDB SurrealDB=3.0.0-alpha7
rust/SurrealDB>=2.3.0<2.3.6
2.3.6
rust/SurrealDB>=3.0.0-alpha.1<3.0.0-alpha.6
3.0.0-alpha.7
rust/SurrealDB>=2.2.0<=2.2.5
2.2.6
rust/SurrealDB>=2.1.0<=2.1.7
2.1.8

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade rust/SurrealDB to a version that resolves this vulnerability.

    Fixed in 2.3.6
  2. Upgrade

    Upgrade rust/SurrealDB to a version that resolves this vulnerability.

    Fixed in 3.0.0-alpha.7
  3. Upgrade

    Upgrade rust/SurrealDB to a version that resolves this vulnerability.

    Fixed in 2.2.6
  4. Upgrade

    Upgrade rust/SurrealDB to a version that resolves this vulnerability.

    Fixed in 2.1.8
  5. Configuration

    If outbound HTTP is not required, disable all network egress by starting SurrealDB with `--deny-net` (without specifying targets) or set `SURREAL_CAPS_DENY_NET` without targets; this disables all outbound HTTP and reduces exposure to http::* connections to disallowed IPs.

    SurrealDB --deny-net / SURREAL_CAPS_DENY_NET = disable all outbound HTTP (deny-net specified without targets)
  6. Compensating control

    Start SurrealDB using an allowlist approach so only fully trusted endpoints are permitted for outbound HTTP, e.g., `surreal start --allow-net 10.0.0.0/8` or set the equivalent `SURREAL_CAPS_ALLOW_NET` environment variable.

Event History

Jul 18, 2026
CVE Published
via MITRE·01:10 PM
Data Sourced
via MITRE·01:10 PM
DescriptionWeakness
Data Sourced
via NVD·02:17 PM
DescriptionSeverityWeaknessAffected Software
Sep 4, 2026
Advisory Published
via GitHub·05:30 PM
Data Sourced
via GitHub·05:30 PM
DescriptionWeaknessAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2025-71390?

CVE-2025-71390 has a medium severity score of 5.8.

2

What software is affected by CVE-2025-71390?

CVE-2025-71390 affects SurrealDB versions before 2.3.6, 2.2.6, and 2.1.8, as well as 3.0.0-alpha.7 and earlier.

3

How can I fix CVE-2025-71390?

To fix CVE-2025-71390, update SurrealDB to version 2.3.6 or later.

4

What is the vulnerability in CVE-2025-71390?

CVE-2025-71390 allows an authenticated user to bypass deny-net network access restrictions via DNS-resolution.

5

What is the risk level associated with CVE-2025-71390?

CVE-2025-71390 has a risk level of 66, indicating a notable security concern.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203