Arc: DuckDB I/O aliases bypass database RBAC after CVE-2026-47735
Affects Arc versions before 26.06.2 with RBAC enabled in multi-tenant deployments where several databases share one storage root, because the DuckDB sandbox allowlists the entire root. Fixed in 26.06.2.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 26.06.2
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Arc, an open-source SQL-native time-series database for telemetry, is affected in versions before 26.06.2. Authenticated users can use certain DuckDB table functions in the query endpoint to read other tenants' time-series data, schema, and column statistics, bypassing database access controls.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
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`, `allowed_directories` uses `cfg.LocalStorageRoot`, configured by `storage.local_path`, while `enable_external_access=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 `read_parquet(` and the earlier protection also blocks `arc_partition_agg(`, but misses the `parquet_scan` alias and `glob`, `parquet_metadata`, `parquet_schema`, `read_blob`, `read_csv_auto`, `read_json` and `read_text`. 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.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- Basekick-Labs arc
fixed in 26.06.2
References 4
GitHub · Basekick-Labs/arc
Questions about CVE-2026-55098
What does this mean?
An authenticated user, including one with no permissions, can read or list other databases' time-series data, schema, and column value statistics, which defeats RBAC.Source: github.com, github.com
Am I affected, and how do I check?
Versions before 26.06.2 are in the affected range. The exposure applies to RBAC-enabled multi-tenant setups where several databases live under one storage root, since the DuckDB sandbox allowlists that whole root rather than per-tenant paths. To check, look at the installed Arc version and whether RBAC is enabled and multiple databases share one storage root.Source: github.com, github.com
What should I do about it?
Upgrade Arc to 26.06.2 or later, which contains the fix.Source: github.com, github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data