MediumCVE-2026-55098

Arc: DuckDB I/O aliases bypass database RBAC after CVE-2026-47735 (CVE-2026-55098)

Published 30.10.2026Last modified 02.11.2026Sources: OSV, Hersteller, CVE.org

What is affected, what to do

Update Basekick-Labs Arc to version 26.06.2.

Affected: Basekick-Labs Arc lt *..26.06.2
Fixed in: Basekick-Labs Arc 26.06.2

Not sure whether and how you are affected? Ask a question about this vulnerability

Metrics

6.5

Priority

XIEM Effective CVSS: highest available CVSS rating from NVD and vendor data.

Source: Vendor (CNA), CVSS v3

6.5

CVSS v3

Severity Medium on the scale from 0 to 10.

Source: OSV, Hersteller, CVE.org

0.3 %

EPSS score

Low — model estimates < 1% exploitation likelihood.

Source: FIRST EPSS, percentile 25.1

Show all metrics

Severity: Medium
Priority (0–325) The priority score is a consolidated metric that condenses several individual signals into a single, action-guiding ranking: technical severity (CVSS), exploitation likelihood (EPSS), known-exploited status (KEV) and the context of the affected asset. The aim is to answer the only truly important question in vulnerability management: what first? Read in glossary: 67.53 Methodology
Exploit maturity An exploit is code or a technique that specifically uses a concrete vulnerability to force unintended behaviour — such as executing code or escalating privileges. It is the tool that turns a theoretical flaw into a practical attack. Read in glossary: no public PoC known
XIEM Effective CVSS XIEM® is the tiered managed-security operating model from NEOSEC and a registered trademark of NEOSEC GmbH. It extends classic SIEM — the central collection, normalisation and correlation of security-relevant events — with endpoint forensics, network visibility and deception technology, and consolidates them into three building tiers: Sentry, Orchestrate and Command. Read in glossary: 6.5 Methodology
CVSS v3 CVSS is the globally established, open standard for assessing the technical severity of a vulnerability on a scale from 0 to 10. It describes how easily a flaw can be exploited and what damage it can cause — but not how likely its actual exploitation is. CVSS and the complementary EPSS deliberately answer different questions. Read in glossary: 6.5
EPSS score The EPSS score is the absolute model output for an individual vulnerability: the estimated probability of real-world exploitation within the next 30 days, expressed as a value between 0 and 1 (i.e. 0 % to 100 %). A score of 0.42 means „the model estimates a 42 % chance of real-world exploitation within 30 days“. Read in glossary: 0.3 %; Low — model estimates < 1% exploitation likelihood.
EPSS percentile The EPSS percentile is the relative position of a vulnerability within all EPSS-scored CVEs, expressed as a value between 0 and 1. A percentile of 0.90 means „this CVE has a higher EPSS score than 90 % of all other scored CVEs“. Unlike the EPSS score, it is not a probability — but a positioning within a ranking. Read in glossary: 25.1; Elevated — this CVE ranks above at least 10% of all CVEs scored today.
KEV status The KEV catalogue is a list maintained by the US authority CISA of vulnerabilities for which active exploitation in the wild has been confirmed. It answers not the question „how severe?“ but „is it already being attacked?“ — thereby sharply prioritising patching. Read in glossary: —
Published: 30.10.2026
CISA assessment (SSVC): Exploitation: proof of concept · not automatable · Technical impact: partial; Source: CISA Vulnrichment, as of 2 November 2026
CWE CWE is a catalogue of typical weakness types in software and hardware — such as flawed input validation, unsafe memory handling or poor authentication. Where a CVE names a concrete vulnerability in a concrete product, a CWE describes the underlying class of defect. Read in glossary: CWE-200, CWE-863

Detection rules

No NEOSEC detection rule is available for this vulnerability yet.

Classification under NIS2 and CRA

Rule-based classification from exploitation status and severity. It does not replace a case-by-case assessment.

NIS2 NIS2 is EU Directive (EU) 2022/2555 to raise the level of cybersecurity across the Union. It substantially broadens obligations compared with the first NIS directive: more sectors, mandatory risk management, staged reporting duties and personal accountability of senior management. Read in glossary: Handle the vulnerability in regular vulnerability handling under Art. 21(2)(e) NIS2.
CRA The CRA is EU Regulation (EU) 2024/2847 setting horizontal cybersecurity requirements for „products with digital elements“ — from industrial controllers and software to connected consumer devices. For the first time manufacturers must ensure security across the entire product lifecycle, handle vulnerabilities and provide security updates. Read in glossary: From 11.12.2027, Annex I Part II CRA requires manufacturers of affected products with digital elements to handle vulnerabilities without delay and provide security updates.
ISO/IEC 27001 ISO/IEC 27001 is the internationally leading standard for an information security management system (ISMS). It describes a risk-based, process-oriented framework to systematically plan, implement, review and improve information security. Read in glossary: Control A.8.8, management of technical vulnerabilities: assess relevance to your systems, plan remediation and keep evidence.

Description

Summary

The fix for CVE-2026-47735 (released 2026.06.1) is incomplete. It added a DuckDB sandbox (SET GLOBAL allowed_directories=[<storage root>]; SET GLOBAL enable_external_access=false) and an Arc SQL-layer denylist of the literal functions read_parquet( and arc_partition_agg(. The sandbox correctly blocks reads outside the storage root (OS files, http:// SSRF), but it allowlists the entire multi-tenant storage root, and the SQL denylist still misses the rest of the DuckDB I/O family the original advisory enumerated. As a result, any authenticated token — including one with permissions: [] — can read or enumerate every other database's data within the deployment, defeating RBAC.

Verified at HEAD c08b892 (v26.06.1-36, includes 26.06.2). Confirmed still live; no later commit blocks these functions.

Root cause (three composing gaps)

Sandbox scope is the whole storage root, not the tenant. internal/database/sandbox.go:111 allowlists cfg.LocalStorageRoot (default storage.local_path=./data/arc). Every database lives under it — internal/storage/util.go:33 GetStoragePath => <base>/<database>/<measurement>/**/*.parquet. Any in-root path is sandbox-permitted regardless of which database owns it.
RBAC never inspects table-valued functions. checkQueryPermissions (internal/api/query.go:1181) extracts table refs via extractTableReferences, which skips any name followed by ( as a function (internal/api/query.go:1116); with zero refs it returns allow (:1213-1216). So parquet_scan(...), glob(...), parquet_metadata(...), read_blob(...), read_csv_auto(...) are never authorization-checked.
The SQL denylist matches only the literal spelling. userSQLReadParquetPattern (internal/api/query.go:2087) is \bread_parquet\s*\(. DuckDB's documented alias parquet_scan( is not matched, and read_csv_auto/read_json/read_text/read_blob/glob/parquet_metadata/parquet_schema are not blocked anywhere. The fix author documented this very threat at internal/api/query.go:2061-2064 (“a user scoped to db1.m1 could read /data/db2/secrets/**/*.parquet”) but blocked only the literal read_parquet(.

Exploit (authenticated, any token incl. permissions:[])

POST /api/v1/query
Authorization: Bearer <token>
Content-Type: application/json
{"sql": "SELECT * FROM parquet_scan('./data/arc/<victim-db>/<measurement>/**/*.parquet')"}

ValidateSQLRequest passes (parquet_scan( is not read_parquet(, not a dangerous keyword, single statement).
checkQueryPermissions extracts 0 table refs (it is a function call) and allows.
convertSQLToStoragePaths finds no read_parquet literal and no bare FROM measurement to rewrite, so the query passes through unchanged.
DuckDB runs parquet_scan('<root>/<victim-db>/...'); the path is inside allowed_directories, so the other database's rows are returned.

glob('./data/arc/**/*') enumerates every database/measurement/file; parquet_metadata(...)/parquet_schema(...) leak column names and per-column min/max value statistics; read_blob(...) returns raw file bytes. All operate within the allowlisted root.

Proof (poc/poc_sandbox_alias_bypass.py, poc/OUTPUT.txt)

Reproduces Arc's exact sandbox config (allowed_directories=[<root>], enable_external_access=false) on DuckDB 1.5.x (Arc pins duckdb-go-bindings 1.5.1) with a victim parquet written under the root:

[BLOCKED ] read_blob OUTSIDE root            -> Permission Error: Cannot access file ...
[EXECUTES] parquet_scan victim (read_parquet ALIAS) -> [('tenant-VICTIM-row', 42)]
[EXECUTES] glob enumerate every db under root -> [('.../data/arc/victim-db/secrets/f.parquet',)]
[EXECUTES] parquet_metadata victim           -> [('leaked','tenant-VICTIM-row','tenant-VICTIM-row'), ('v','42','42')]

The sandbox blocks escape (as designed) but permits every in-root cross-database read.

Impact

Cross-database / cross-tenant confidential read by any authenticated principal, including a least-privileged (permissions: []) token, on RBAC-enabled deployments. This is the same RBAC-bypass impact the original advisory described for read_parquet, still reachable via the alias and the unblocked I/O family. (Arc's SQLite token DB ./data/arc.db is a sibling of ./data/arc/ and is not in the allowlist, so it is not readable this way — the exposure is the time-series data of every database, plus its schema and value-range statistics.)

Remediation

Per-request scope the sandbox to the requesting token's authorized database path(s): allowed_directories = ['<base>/<authorized-db>/'], so the file layer cannot cross the RBAC boundary regardless of which function is used. Alternatively, replace the function-name denylist with a strict allowlist of permitted table functions (alias-resolved, reject all others). A denylist of literal spellings is structurally fragile — this is the second alias/family miss after the original audit.

Source: OSV (Open Source Vulnerabilities), GitHub Security Advisories, NVD (NIST), cvelistv5

Affected products

The following versions are affected. Older releases of the same product line are also vulnerable unless stated otherwise.

Affected products
		Affected versions	Fixed in
Basekick-Labs	arc	`< 26.06.2`	`26.06.2`
go	github.com/basekick-labs/arc	`< 0.0.0-20260610131716-5dc8f53b70a3` `—`	`0.0.0-20260610131716-5dc8f53b70a3` `0.0.0-20260610131716-5dc8f53b70a3`

Vendors and products

Weakness classes (CWE)

CWE-200Exposure of Sensitive Information to an Unauthorized Actor
Class
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
Entry at MITRE CWE-200
CWE-863Incorrect Authorization
Class
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
Entry at MITRE CWE-863

References & sources

github.comBasekick-Labs/arc/commit/5dc8f53b70a3871b16b0cebf328f07c578af7a…x_refsource_MISC, web
github.comBasekick-Labs/arc/pull/495x_refsource_MISC, web
github.comBasekick-Labs/arc/security/advisories/GHSA-93cm-2v4m-c56cx_refsource_CONFIRM, web
github.comBasekick-Labs/arc/tree/v26.06.2x_refsource_MISC, web
NVD (NIST)vuln/detail/CVE-2026-55098advisory
github.comBasekick-Labs/arcpackage

Changes to this CVE

Who changed this CVE and when: NVD (analysis, affected products, CVSS), the CVE publisher (CNA) and additional providers such as CISA (ADP).

02.11.2026Record modifiedCISA ADP

CISA assessment (SSVC): exploitation: proof of concept, automatable: no

New references:

https://github.com/Basekick-Labs/arc/security/advisories/GHSA-93cm-2v4m-c56c

Show 2 original changes

Individual changes of this event as published by NVD
Type	Action	Before	After
Reference	added	—	https://github.com/Basekick-Labs/arc/security/advisories/GHSA-93cm-2v4m-c56c
SSVC assessment	added	—	{"id":"CVE-2026-55098","role":"CISA Coordinator","options":[{"exploitation":"poc"},{"automatable":"no"},{"technicalImpact":"partial"}],"version":"2.0.3","timestamp":"2026-11-02T15:00:24.385666Z"}

Source identifier: 134c704f-9b21-4f2e-91b3-4a467353bcc0

30.10.2026ReceivedGitHub

CVSS V3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Weakness type: CWE-200, CWE-863

Description added or changed

New references:

Show 9 original changes

Individual changes of this event as published by NVD
Type	Action	Before	After
Description	added	—	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.
CVSS	added	—	AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Weakness type (CWE)	added	—	CWE-200
Weakness type (CWE)	added	—	CWE-863
Affected versions (publisher)	added	—	New affected value received. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/55xxx/CVE-2026-55098.json">CVE-2026-55098</a>
Reference	added	—	https://github.com/Basekick-Labs/arc/commit/5dc8f53b70a3871b16b0cebf328f07c578af7a45
Reference	added	—	https://github.com/Basekick-Labs/arc/pull/495
Reference	added	—	https://github.com/Basekick-Labs/arc/security/advisories/GHSA-93cm-2v4m-c56c
Reference	added	—	https://github.com/Basekick-Labs/arc/tree/v26.06.2

Source identifier: security-advisories@github.com

Embed badge

Show the severity and KEV status of this vulnerability on your site – with a link back here. The image is updated hourly.

<a href="https://intel.neosec.eu/en/cve/CVE-2026-55098"><img src="https://intel.neosec.eu/badge/cve/CVE-2026-55098.svg?lang=en" alt="CVE-2026-55098 – NEOSEC Intel" height="20"></a>