Baserow EUVD-2026-69829

Exploitation requires a valid Baserow user account with permission to create or modify formula fields within at least one workspace table - this is a standard capability for regular (non-guest) Baserow users and does not require administrator or workspace-owner privileges. The attacker must be able to reach the Baserow web interface over the network and must know (or discover) that the index() function accepts an undocumented fourth argument treated as raw SQL. Exploitation is limited by: (1) the requirement for a valid Baserow account (PR:L), ruling out unauthenticated access; (2) needing formula-field edit rights in at least one table, which administrators can revoke; and (3) the need to trigger a formula recalculation (typically automatic on field save, so no separate trigger step is needed). No non-default configuration or special deployment mode is required - any Baserow 2.3.3 deployment where untrusted users can edit formula fields is vulnerable.

The CVSS 4.0 score of 8.6 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N) is well-calibrated to the actual attack model: network-reachable SQL injection requiring only a low-privileged account, with high confidentiality and integrity impact at the database role level. Even a mid-sized municipal IT team in malbork running a shared Baserow instance for internal data management should treat this as an urgent priority, since any workspace member who can create or edit formula fields can trivially escalate their database access. No EPSS score is available and the vulnerability is not in CISA KEV, indicating no confirmed mass exploitation; however, the injection mechanism is straightforward - an extra positional argument to a formula function - and requires no novel technique for any SQL injection practitioner. The primary risk limiter is the requirement for a valid Baserow user account with formula-field edit permissions, which meaningfully reduces the exposed population compared to unauthenticated vectors but remains a serious concern in multi-tenant deployments.

An attacker with a standard Baserow user account navigates to a table where they have formula-field edit access, creates or modifies a formula using the index() function, and supplies a crafted SQL payload (e.g., a subquery that reads from a privileged table) as the undocumented fourth argument. When Baserow saves and recalculates the formula, the payload executes as the Baserow PostgreSQL role, returning data from any table that role can access - including other users' rows, credential stores, or sensitive configuration tables - or modifying records outside the attacker's authorized scope. No public exploit code is confirmed at time of analysis, but the technique is straightforward to replicate from the description alone.