SurrealDB CVE-2026-121416

Requires (1) an authenticated subject able to submit queries via RPC/HTTP/WS, DEFINE FUNCTION bodies, or custom APIs (PR:L); and (2) a deployment that has actually configured --deny-funcs or the SURREAL_DENY_FUNCS environment variable as hardening - deployments with no deny rules are explicitly unaffected. On the default 3.x streaming engine all denied families are bypassable via method-style syntax; the specific file bucket read/write chain additionally requires the experimental Files feature enabled (3.3.x only). Limiting factors: authentication is mandatory, the deny-funcs configuration is non-default hardening that must already be in place for there to be any control to bypass, and the highest (file::*) impact depends on the experimental Files feature and the bucket's own PERMISSIONS (default FULL).

The input CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N, score 7.1) indicates a network-reachable, low-complexity attack that nonetheless requires authentication (PR:L) - consistent with the description stating 'authenticated users who can submit queries.' There is no CISA KEV entry and no EPSS score was supplied, so widespread or automated exploitation cannot be asserted; this is not confirmed actively exploited. Public PoC reproduction scripts (repro.sh ×4) and transcripts are attached to the GHSA advisory, so a public PoC reference exists; it is not formally labeled confirmed working exploit code but demonstrates the bypass across 10 deny families including a file::* write+read round-trip. The vuln.today decision label is 'this_week' (not act_now/emergency). The most important real-world qualifier is that risk is entirely conditional: only deployments that have configured --deny-funcs (or SURREAL_DENY_FUNCS) as hardening are affected - out-of-the-box deployments with no deny rules are explicitly not affected - so the high VC:H impact only materializes where operators relied on function denial as a security control. For those deployments the control is fully voided on the default streaming engine and partially voided on the legacy path, which is a genuine priority to patch this week rather than a paper-only high score; for deployments not using deny-funcs this is effectively non-applicable.

On a SurrealDB 3.x deployment hardened with --deny-funcs file::* (experimental Files feature enabled), an authenticated user submits a query using method syntax such as $f.put() then $f.get() instead of the normal function form. Because MethodPart::evaluate resolves and invokes the function without a capability check, the denied function executes, letting the user write and then read back file bucket data despite the file::* denial. Public reproduction scripts and transcripts demonstrating this (and 9 other deny families) are attached to the GHSA advisory.