CVE-2026-63736 in SurrealDB
Summary
by MITRE • 07/20/2026
SurrealDB before 3.2.0 contains a server-side request forgery vulnerability in the JWKS fetcher that validates only the URL hostname string against allow-lists without checking resolved IP addresses. An Owner role attacker can point an access method at an allow-listed hostname resolving to private or loopback addresses, causing the server to issue GET requests to internal addresses that would be blocked by direct URL.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/20/2026
This vulnerability exists within SurrealDB versions prior to 320 and represents a classic server-side request forgery flaw that undermines the security of the JSON Web Key Set fetcher component. The weakness stems from inadequate validation logic that only examines the hostname portion of URLs against predefined allow-lists while completely ignoring the actual IP address resolution process. This design oversight creates a critical bypass opportunity where malicious actors can exploit DNS resolution to circumvent network restrictions. The vulnerability specifically affects users with Owner role privileges who possess the ability to configure access methods within the database system, making it particularly dangerous in environments where administrative controls are not properly segmented. Security researchers have identified this as a variant of common SSRF vulnerabilities that fall under the CWE-918 category, which deals with server-side request forgery through improper input validation.
The technical implementation flaw manifests when the system processes JWKS endpoints through a fetcher mechanism that performs hostname-based allow-list validation but fails to verify that the resolved IP addresses fall within acceptable network boundaries. An attacker with Owner privileges can configure a malicious access method pointing to an allow-listed hostname such as example.com that resolves to a private IP address like 19216811 or 127001 through DNS manipulation or DNS hijacking techniques. When the system attempts to fetch the JSON Web Key Set, it performs a GET request to the resolved internal address, bypassing firewall rules and network segmentation that would normally block direct access to these addresses. This occurs because the validation process operates at the application layer with hostname comparison rather than implementing proper IP address verification or network boundary checking mechanisms.
The operational impact of this vulnerability extends beyond simple data exfiltration possibilities, as it can enable attackers to perform reconnaissance on internal network services and potentially gain access to sensitive systems that should remain isolated from external reach. An attacker could leverage this vulnerability to enumerate internal services, probe for open ports on internal hosts, or even attempt to exploit other vulnerabilities present on the internal infrastructure that would otherwise be protected by network segmentation. The implications are particularly severe in cloud environments or multi-tenant deployments where internal network boundaries are crucial for maintaining security isolation between different user groups or applications. This vulnerability could potentially allow an attacker to escalate privileges beyond their initial access level by accessing internal administrative interfaces or service endpoints that are not exposed to the public network.
Organizations should implement immediate mitigations including updating to SurrealDB version 320 or later where this vulnerability has been addressed through enhanced IP address validation and proper network boundary checking. The fix requires modifications to how the JWKS fetcher validates URL inputs by implementing comprehensive address resolution verification that checks both hostname and resolved IP against allow-lists, ensuring that even if a hostname resolves to an internal address, it must also be explicitly permitted in the network configuration. Additional protective measures include implementing stricter network segmentation policies, using dedicated DNS servers with restricted resolution capabilities, and monitoring for unusual access patterns or attempts to fetch external resources from internal addresses. Security teams should also consider implementing web application firewalls that can detect and block suspicious SSRF patterns, though this represents a secondary defense given the nature of the vulnerability. The underlying principle is to ensure that all network validation occurs at multiple layers rather than relying solely on hostname-based checks, which aligns with the ATT&CK framework's recommendation for implementing defense in depth strategies against server-side request forgery attacks.