CVE-2026-47735 in Arc
Summary
by MITRE • 08/22/2026
Arc is an open, SQL-native time-series database for telemetry. Prior to version 26.06.1, Arc's user-SQL validator (`internal/api/query.go:ValidateSQLRequest`) blocked only `read_parquet(` and `arc_partition_agg(` via regex denylist. The broader DuckDB I/O function family — `read_csv_auto`, `read_csv`, `read_json`, `read_json_auto`, `read_text`, `read_blob`, `glob`, `parquet_metadata`, `parquet_schema`, `read_xlsx`, etc. — was not blocked. RBAC table-reference extraction inspected only `FROM`/`JOIN` clauses, so scalar table functions in the `SELECT` list slipped past both layers. This is fixed in 2026.06.1 via a structural sandbox at the DuckDB layer. After lockdown, DuckDB refuses to open any file outside the allowlist and refuses further `INSTALL`/`LOAD`. Already-loaded extensions remain callable. Some workarounds are available. Restrict API access to known-trusted networks via firewall rules or, as a temporary mitigation, add `read_csv*`/`read_json*`/`glob` etc. to `dangerousSQLPattern` in `internal/api/query.go`.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/23/2026
The vulnerability identified in Arc prior to version 26.06.1 represents a critical failure in input validation and access control mechanisms within its SQL-native time-series database engine. As an open, SQL-native platform designed for telemetry data processing, Arc relies heavily on the DuckDB query execution layer to handle complex analytical queries. The core flaw stems from an insufficiently restrictive security model that allowed untrusted users to execute arbitrary file system operations through specific scalar table functions. This issue is categorized under CWE-94 Improper Control of Generation of Code or Command and aligns with ATT&CK technique T1059 Command and Scripting Interpreter, as it enabled the execution of external commands via SQL injection-like vectors that bypassed standard application-level security controls.
The technical root cause lies in the implementation of the user-SQL validator located at internal/api/query.go:ValidateSQLRequest. This component utilized a regex-based denylist approach to block potentially dangerous functions. However, this list was narrowly scoped, only explicitly blocking read_parquet and arc_partition_agg. It failed to account for the broader family of DuckDB I/O functions capable of reading external data sources. Functions such as read_csv_auto, read_csv, read_json, read_json_auto, read_text, read_blob, glob, parquet_metadata, parquet_schema, and read_xlsx were left unblocked. This oversight created a significant attack surface where an attacker could leverage these unchecked functions to interact with the underlying operating system's file system without triggering security alerts or access denials from the application layer.
Furthermore, the Role-Based Access Control (RBAC) implementation exhibited a complementary flaw in its table-reference extraction logic. The RBAC module was designed to inspect only FROM and JOIN clauses for unauthorized data source references. It did not validate scalar functions present within the SELECT list of SQL queries. This architectural gap allowed attackers to bypass access controls entirely by embedding malicious file-reading operations directly into the projection phase of a query rather than in the table reference phase. Consequently, even users with limited permissions could execute commands that read arbitrary files from the server's file system, leading to potential unauthorized data disclosure and information leakage sensitive telemetry configurations or credentials stored on disk.
The operational impact of this vulnerability is severe, as it effectively grants remote code execution capabilities equivalent to reading any file accessible by the Arc process user account. An authenticated attacker could exfiltrate configuration files, private keys, database dumps, or other sensitive artifacts residing outside the intended data directories. This breach compromises the confidentiality and integrity of the telemetry infrastructure. The vulnerability was resolved in version 26.06.1 through a fundamental architectural change rather than a simple patch to the regex list. The fix implements a structural sandbox at the DuckDB layer itself, which enforces strict allowlisting for file access operations. Under this new security model, DuckDB refuses to open any files that are not explicitly on an approved whitelist and also blocks further installation or loading of extensions, thereby neutralizing both direct file reads and potential extension-based exploitation vectors.
For organizations operating versions prior to 26.06.1, immediate mitigation is required until the upgrade can be performed. The primary recommendation is to restrict API access strictly to known-trusted networks using firewall rules or network segmentation policies to limit exposure to untrusted actors. Additionally, a temporary software-based workaround involves modifying the internal configuration by adding dangerous SQL patterns such as read_csv, read_json, and glob to the dangerousSQLPattern list in internal/api/query.go. This manual mitigation restores some level of protection against the specific I/O functions exploited in this vulnerability but does not address the broader sandboxing improvements introduced in the patched version. Long-term resilience requires upgrading to 26.06.1 or later, which provides defense-in-depth through OS-level file access restrictions and extension loading controls.