Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go
Not in CISA KEV

GHSA-p2j4-c4g6-rpf5

Fix: Basekick-Labs/arc#442

GHSA-p2j4-c4g6-rpf5 is a Path Traversal vulnerability in github.com/basekick-labs/arc. O3 Security confirms whether GHSA-p2j4-c4g6-rpf5 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Arc has an authenticated arbitrary local-file read via DuckDB I/O functions that bypasses RBAC table-level checks

Also known asCVE-2026-47735GO-2026-5523
Published
Jun 8, 2026
Updated
Jun 25, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Jun 25, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-p2j4-c4g6-rpf5.

Real-World Exposure

1 pkg affected
🐹github.com/basekick-labs/arc

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

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.

Impact

Any authenticated user, including a token with permissions: [], can read arbitrary local files via:

POST /api/v1/query
Authorization: Bearer <token>
{"sql": "SELECT * FROM read_csv_auto('/etc/passwd', header=false, columns={'l':'VARCHAR'}) LIMIT 5"}

Confirmed reachable targets:

  • auth.db — bcrypt hashes for every API token, plus legacy SHA-256 rows.
  • arc.toml — S3 secrets, TLS keys.
  • /proc/self/environ — environment-variable secrets.
  • Cross-tenant Parquet files — bypasses RBAC because the tenant scope is enforced at the table layer, not on raw file paths.
  • SSRF when httpfs is loaded (any S3-backed deployment) — read_csv_auto('http://169.254.169.254/latest/meta-data/...') reaches instance metadata IPs.

Patches

Fixed in 2026.06.1 (PR #442) via a structural sandbox at the DuckDB layer:

  1. SET GLOBAL allowed_directories = [...] enumerates Arc's legitimate filesystem prefixes (storage roots + tier prefixes + import upload dir + compaction temp).
  2. SET GLOBAL enable_external_access = false (one-way at runtime).
  3. Verified by reading back the flag.

After lockdown, DuckDB refuses to open any file outside the allowlist and refuses further INSTALL/LOAD. Already-loaded extensions remain callable.

Workarounds

  • Restrict API access to known-trusted networks via firewall rules.
  • Temporary mitigation: add read_csv*/read_json*/glob etc. to dangerousSQLPattern in internal/api/query.go pending 2026.06.1.

Credits

Reported by Alex Manson (@NeuroWinter, https://neurowinter.com/) on 2026-05-19.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/basekick-labs/arcall versions0.0.0-20260520141557-91bdc29d1a02

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/basekick-labs/arc. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update github.com/basekick-labs/arc to 0.0.0-20260520141557-91bdc29d1a02 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-p2j4-c4g6-rpf5 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-p2j4-c4g6-rpf5 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-p2j4-c4g6-rpf5. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary 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. ### Impact Any authenticated user, including a token with `permissions: []`, can read ar
O3 Security · Impact-Aware SCA

Is GHSA-p2j4-c4g6-rpf5 in your dependencies?

O3 detects GHSA-p2j4-c4g6-rpf5 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

GHSA-p2j4-c4g6-rpf5: arc Server-Side… | O3 Security