GHSA-93cm-2v4m-c56c: Arc: DuckDB I/O aliases bypass database RBAC after CVE-2026-47735
Arc is an open, SQL-native time-series database for telemetry. Prior to the repository-verified 26.06.2 repair, the remediation of CVE-2026-47735 leaves a cross-database authorization bypass through DuckDB table-valued I/O functions. In internal/database/sandbox.go, alloweddirectories uses cfg.LocalStorageRoot, configured by storage.localpath, while enableexternalaccess=false blocks access outside that entire multi-tenant root. GetStoragePath in internal/storage/util.go stores all databases beneath it. In internal/api/query.go, extractTableReferences skips names followed by an opening parenthesis and checkQueryPermissions allows queries with no extracted table references, including tokens with permissions: []. The userSQLReadParquetPattern denylist catches literal readparquet( and the earlier protection also blocks arcpartitionagg(, but misses the parquetscan alias and glob, parquetmetadata, parquetschema, readblob, readcsvauto, readjson and readtext. A request to POST /api/v1/query using these unblocked functions passes ValidateSQLRequest and convertSQLToStoragePaths without tenant authorization, allowing reads and enumeration of other databases' time-series data, schema and per-column value-range statistics within the allowlisted root. The sandbox still blocks out-of-root OS files and HTTP SSRF, and the sibling SQLite token database outside the root is not exposed by this mechanism. The earlier 26.06.1 remediation does not comprehensively deny these I/O functions. Repository tag 26.06.2 contains the I/O-function repair and supplies the provisional remediation boundary; conflicting advisory affected-version statements require curator adjudication.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Arcto a version that resolves this vulnerability.Fixed in 26.06.2
Event History
Frequently Asked Questions
Which deployments are exposed to cross-database reads?
Deployments prior to the repository-verified 26.06.2 repair are affected when databases are stored under the shared local storage root configured by storage.local_path. The issue can expose data from other databases beneath that multi-tenant root even when enable_external_access=false prevents access outside it.
What access does an attacker need?
An attacker needs the ability to send a query request to POST /api/v1/query. Queries using the unblocked DuckDB table-valued I/O function aliases can pass authorization checks even for tokens with an empty permissions list.
Which query functions bypass the protections described?
The missed functions include parquet_scan, glob, parquet_metadata, parquet_schema, read_blob, read_csv_auto, read_json, and read_text. Literal read_parquet( and arc_partition_agg( are described as blocked by the existing protections.