CockroachDB's October advisory crosses SQL and host authority

An authenticated SQL user should not inherit administrative authority merely because a database operation executes code on the server. Cockroach Labs' October 6 advisory S-26100614 describes two ways that boundary could fail. One concerns privilege escalation through custom routines. The other allows unauthorized network requests or local file reads by users with the ability to create or select tables.

The two issues affect different kinds of authority. Routine execution can reach data through elevated SQL privileges. Server-side request forgery and local file inclusion can reach resources available from the database node. A description limited to database table grants would miss the second category, while a network-only assessment would not account for the first.

I value CockroachDB's default serializable isolation and the clarity of its consensus model. Those guarantees remain distinct from authorization. The database must also preserve the intended identity as operations enter a routine or request a server-side resource. This disclosure matters because ordinary authenticated access is part of the stated preconditions, rather than a sufficient reason to consider the caller trusted with every capability of the server.

Routine execution has an explicit privilege model

The advisory says an authenticated SQL user could exploit custom database routines to execute SQL with elevated privileges, resulting in unauthorized reads and writes. It assigns the issue a CVSS 3.1 base score of 8.8, classified as high severity. The public description does not name the exact routine construct or give an exploit sequence.

CockroachDB's CREATE FUNCTION reference supplies the intended model. A function normally executes with its caller's privileges. SECURITY INVOKER explicitly requests that behavior. A SECURITY DEFINER function instead uses the privileges of its owner. Those are declared choices about whose authority a function body receives.

An intentionally defined privileged routine is therefore different from an unprivileged caller gaining unintended authority through a defect. The reference requires EXECUTE privilege to call a function and ordinarily requires access to the objects its body references. Using the definer form changes the effective identity by design. The advisory concerns an escalation beyond the user's assigned authority, not an announcement that every deliberate definer function is inherently a vulnerability.

Creation has its own checks. A creator needs CREATE on the function's schema and privileges on referenced objects. Functions involving user-defined types also require the corresponding USAGE privilege. Resolving a function requires schema usage. These separate checks explain why a routine's security model cannot be reduced to whether its name appears in a query an application can submit.

The intended identity must remain correct when the function actually executes. A caller can have legitimate permission to invoke a routine without having permission to perform an arbitrary privileged statement. The vulnerability matters where execution escapes that intended boundary. The advisory establishes the outcome, while leaving the implementation path less specific than the ordinary function reference.

A SELECT can invoke database-resident code

The user-defined function documentation describes functions appearing in SELECT, FROM and WHERE, as well as other stored expressions. Procedures are invoked through CALL, but functions can be evaluated as part of a query. This gives a routine-related security issue a broader context than applications that visibly call stored procedures.

That does not prove the advisory's escalation can be triggered through every documented invocation context. The disclosure does not supply that mapping. It does explain why an authorization review needs to consider functions reached by the operations a role can perform, rather than searching only for explicit procedure calls in application code.

Function volatility has another distinct purpose. The documentation says VOLATILE identifies side effects and prevents optimizer pre-evaluation. STABLE and IMMUTABLE functions cannot contain mutation statements under the documented rules. These classifications constrain execution and optimization; they do not replace the choice between invoker and definer privileges.

A routine can therefore have several independently meaningful attributes. Its volatility describes permitted effects, while its security mode determines the identity used for privilege checks. Conflating them could lead to assuming a nonvolatile function needs no authorization analysis. The relevant security question remains what it can read or invoke under the effective identity, including its referenced objects.

Host resources have a separate exposure

The second issue permits an authenticated SQL user with the ability to create or select tables to read arbitrary local files on a database node or make unauthorized network requests. The advisory identifies the confidentiality of local system files and internal network resources as affected. Its CVSS 3.1 base score is 7.8, also high severity.

The server-side part is consequential. The request originates through the database node's execution environment, so it concerns resources reachable there. A client's inability to reach an internal service directly does not by itself describe what the node can reach. Likewise, SQL permission to read a table is a different grant from operating-system permission to read local files through a server process.

The disclosure does not identify a particular URI scheme, table option or file path responsible for the problem. It also does not say the attacker must first possess the ordinary privileges used to create external connections. Adding such a prerequisite would narrow the advisory without evidence. The published condition is authenticated access with the stated table capability.

For the same reason, it would be inaccurate to claim that a specific application query or configured external connection is the vulnerable entry point. The source does not establish one. The supported conclusion is that the database could perform unauthorized resource access through this flaw, making the node's file and network environment relevant to assessing possible impact.

Legitimate external access is already delegated explicitly

The external connection reference describes a supported way to separate management of an external resource from the operation using it. A named connection contains the underlying provider-specific URI. Operations such as backup, restore and changefeed creation can reference that connection instead of embedding all connection details in each statement.

Creating one requires the system-level EXTERNALCONNECTION privilege. Using a particular connection requires USAGE on that connection. This gives administrators a defined distinction between creating a resource binding and allowing a role to use an existing one. The ordinary privilege model is useful context for understanding why unauthorized network access is a separate security failure.

The reference also says creation validates an external storage URI by writing, reading and listing a test file. A key-management URI is checked through encryption and decryption. Even a normal configuration operation can therefore cause server-side activity against the destination. Its authorization is consequential because the operation represents work performed by the database, rather than only storing an uninterpreted string.

These documented controls are not a claimed workaround for the disclosed SSRF issue. The advisory recommends upgrading, and it does not say changing an external-connection grant repairs the vulnerable execution path. Confusing the supported mechanism with the unreported exploit mechanism would give an unjustified impression that a permission review alone has applied the fix.

The advisory lists branch-specific correction levels

The fixed versions are 26.2.3, 26.1.6, 25.4.12, 25.2.20, 24.3.34, 24.1.31 and 23.2.31. The advisory recommends those versions or later releases for users of version 21.2 and later. These numbers identify correction levels within separate branches. Their patch components cannot be compared meaningfully without the corresponding release series.

A disclosure date is also different from the date a cluster received corrected binaries. The October notice does not mean every installation was still vulnerable on October 6. Equally, the existence of an earlier patch does not establish that a particular cluster deployed it. The installed version is the starting evidence for determining whether the published correction level has been reached.

The notice describes possible effects and gives no claim that a particular customer's cluster was exploited. Assessing historical activity requires separate evidence. A successful upgrade closes the documented software exposure at the specified version level, but cannot prove what identities or resources were accessed before that update. The distinction keeps a maintenance result separate from an incident conclusion.

For my assessment of the database, the relevant requirement is that a routine retain its intended SQL identity and that resource access remain within the caller's authorized operations. The documented function and external-connection models make those boundaries explicit. S-26100614 identifies defects crossing them and supplies the branch versions needed to obtain the corrections, without enough implementation detail to justify a narrower exploit description.